Pops,
Part of my problem is that I am not always as clear as I think I am when communicating to others and I am trying to work on that, but with slow progress. When I am answering your questions I am making a few assumptions, based on previous posts, that I will outline below.
1. Both Nodes have control of their Outbound Caller ID (Calling Party Number).
2. Neither Node can send out Caller ID that does not belong to their site.
3. You route outbound calls between sites based on number dialed to reduce costs for your customer.
4. You want a member of one node to be able to show 2 different sets of caller ID based on whether the call is local to its node or has to route through another node.
Now I will provide simple scenarios and ask questions to pin point the problem. So let's say I have this number as a DDI coming in to Node 1: 08-9120-0851
08-9120-0851 -> Node 1 -> Off-Node HG Node 2 and this works as expected.
Node 2 HG Members want to make a call through Node 1 and use this number 08-9120-0851 which is local to Node 1 so its carrier shouldn't have a problem with it. When you change the Calling Party Number of Node 2 to this number 08-9120-0851 does it work for your scenario? <- Is the problem you have that this is not working as expected?
If it does work then the problem you will have at this point is that 08-9120-0851 does not exist on the trunking for Node 2 so when they make local calls it is reject; yes? <- That is a Non-Native Caller ID problem that I was referring to.
Of course It could also be an issue with the Carrier's switch not accepting the digits provided for the CPN since they are in two different countries. For instance in the US we use this number plan XXX-XXX-XXXX the first set is the 3-digit Area Code followed by the 3-digit Office Code and finished with a 4-digit address within that office. From what I remember when I was station is Europe and stayed in London for a few months "training" they had a XXXX-XXXX phone number and I am not exactly sure how that is broken down, but I am sure there is more to it. You may want to get into Online Monitor under the digital trunking card you are using and see what the Calling Party Number Type and Calling Party Number Plan are set to as I have run into this situation before where calls across nodes using CPN showed up as Unknown when calling off-node. Of course since they are in different countries they may need to be different to work properly for the country they are in; that would be a Mitel tech support question as I have no experience with that.
But what you want is when they make local calls off their own node (node 2) it shows a local number 314-456-1234 (assuming that node 2 is in the US). So I assume that if you make their number 314-456-1234 it goes out locally as expected with that number; correct?
Now, when you have the station at Node 2 using a local number, 314-456-1234, as its Calling Party Number and they go out through Node 1 it is either being rejected or it shows the Billed Telephone Number of Node 1 if it is allowed to go through; correct? <- This would also be a Non-Native Caller ID issue and possibly a carrier issue with the setup message as theorized above. You may need to look at D-Channel Diagnostics and depending on your software version there are 3 ways to do this which I will provide at the end of this post.
The last thing you wanted though was when a member of the HG in Node 2 makes a local call it shows this number 314-456-1234 and when it goes out the trunks in Node 1 you want it to show this number 08-9120-0851. At this point we have no way to do that within the controller without using the solution Dwayneg provided in another post or you use an OAI server to monitor your stream and change the CPN based on which station called and from which node it was in.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
There are three methods to access the D-channel diagnostics on a T1M, T1M-2, and BRM-s.
Note: Accessing the D-channel diagnostics through the DMU on the T1M-2 may cause the dt1_app to reset due to a watchdog error. Therefore, its recommended that you access the D-channel diagnostics data for the T1M-2 by "tailing" the log file as noted in the second method or the third method which is to change the ISDN output format to 2 and view via Message Print.
The first method for viewing diagnostics is:
Open Putty up and log into the DMU,
Select Digital Trunk Diagnostics,
Select a bay,
Select a port,
Select ISDN Diagnostics,
Select D-Channel Diagnostics,
Enable the desired level if not already enabled, Note: Level 2 is needed for what you want to look at Pops.
Select the Display D-Channel Diagnostics.
Software revision 2.4 MR12 and higher now includes a warning on the DMU screen:
WARNING: Using this screen to monitor D-channel messages on a busy T1M-2 may
cause the application to reset. Use this screen only when there is limited
traffic on the D-channels with D-Channel Diagnostics enabled. Alternatively,
monitor the D-channel data by accessing the diagnostics application log.
The second method to viewing diagnostics:
Is to access this information is through the corresponding /var/log/intl/XXX_app_diag_Y.log file (where XXX is "t1", "dt1", or "bri" and Y is the bay number).
The third method to viewing diagnostics and most likely the easiest:
Go into database programming and then online monitor. Go into the span and change the ISDN Output Format type from 0 to 2 and then enable message print via SA&D if using v4.0 and higher software or Diagnostics Monitor if using v3.2 and lower software.
Thanks,
TE