Off-Node Routing call to display CLI

[popolou]

Hey guys

I currently have inbound calls to a UK DDI number routed to an off-node hunt group overseas. That second node can also make calls that routes back into the UK via the first node but how where do I change the programming so that the outbound CLI on such calls is presented as that same DDI?

Individual phones can be changed via 'calling party number' and the same on the individual CO lines but I cannot seem to do this for off-node routed calls.

Cheers
Pops

[Tech Electronics]

Pops,

It sounds like the trunking does not allow for non native caller I'd from the carrier if I understand the problem correctly.

Are you trying to get a phone on node 2 to send out CLI of a number in node 1.

Thanks,

TE

[popolou]

Yes, I am trying to present outbound calls from node 2 (that are routed via node 1) as the same allocated DDI number that is used to call the HG on node 2.

Cheers
Pops

[Crowtalks]

Do you have Propagate Original CID checked in the PRI/DDI node, I'm thinking that this may be for that scenario you have outlined.

Jim

[Tech Electronics]

Pops,

Most likely as I stated before the Carriers are not allowing for Non-Native Caller ID to be sent out from those stations. You will need to get them to change that then you will be able to use any number you want as the Calling Party Number and it will solve your problem.

Crowtalks,

Propagate Original CID has nothing to do with trying to send Caller ID Out from a particular station. This is similar to the other problem you and I talked about where the customer has to have the ability to control Outbound Caller ID (which Pops does) and the Carrier also needs to allow for Non-Native Caller ID (the sending of Caller ID that is not within the white list of the trunks).

Thanks,

TE

[Crowtalks]

Tech Electronics thanks for the info...

so thinking about this, could Pops assign his Caller ID field on one of the phone that belongs to a remote node with a DID that exist on the main node and do think the PRI would accept the call then?

[Tech Electronics]

Crowtalks,

Think about what he is asking about. He has control of outbound Caller ID and I assume that it works if he changes the Calling Party Number of the station to a DDI that exists on that Node.

Now, what he wants to do is for those stations that are answering the call to present the DDI that is routed to them as their Outbound Caller ID (Calling Party Number) and that number belongs to a different System and maybe even a different carrier and that can only be done if the carrier allows it. This is what is commonly referred to as Non-Native Caller ID.

Thanks,

TE

[Crowtalks]

Got, it...now I understand...thanks!

Jim

[popolou]

Think about what he is asking about. He has control of outbound Caller ID and I assume that it works if he changes the Calling Party Number of the station to a DDI that exists on that Node.

Correct. I can assign any of the DDI's allocated to us to any phone on the local node and it will be presented on outgoing calls.

Pops,

Most likely as I stated before the Carriers are not allowing for Non-Native Caller ID to be sent out from those stations. You will need to get them to change that then you will be able to use any number you want as the Calling Party Number and it will solve your problem.

Assuming i can get this changed with the carrier, how does one distinguish and allocate the DDI to outbound ARS calls routed to Node 1 without changing the phone's Calling Party Number so that it won't affect their regional CLI within Node 2?

Now, what he wants to do is for those stations that are answering the call to present the DDI that is routed to them as their Outbound Caller ID (Calling Party Number) and that number belongs to a different System and maybe even a different carrier and that can only be done if the carrier allows it. This is what is commonly referred to as Non-Native Caller ID.

Bingo, you've hit the nail on the head but this still leaves me unsure of something. If the Node 2 call is routed via ARS to Node 1, how does the carrier detect the call is initiated by a "non-native" node if the outgoing trunks are being used from the local node? I thought the internal routing would be transparent and the carrier wouldn't detect that a non-native node initiates the call.

Thanks chaps. Learn something every day here.....
Pops

[Tech Electronics]

Pops,

Assuming i can get this changed with the carrier, how does one distinguish and allocate the DDI to outbound ARS calls routed to Node 1 without changing the phone's Calling Party Number so that it won't affect their regional CLI within Node 2?

Unfortunately with a base system you have no way to dynamically change your Calling Party Number whether staying within the same controller or going to another node.

Bingo, you've hit the nail on the head but this still leaves me unsure of something. If the Node 2 call is routed via ARS to Node 1, how does the carrier detect the call is initiated by a "non-native" node if the outgoing trunks are being used from the local node? I thought the internal routing would be transparent and the carrier wouldn't detect that a non-native node initiates the call.

The Carrier doesn't know anything about the station that initiated the call or where it is physically located, the only thing it knows is that you are trying to change your Calling Party Number to a number that is not on the white list for your trunking. Since the phone your are initiating the call with is on another node and you set its Calling Party Number to a DDI that is local to its own controller and sending that information over when dialing out that is where your problem occurs.

So at this point now that I think I have a full understanding of what you are trying to accomplish I will have to say there is no way to do it without a server at each Node looking at the OAI Stream and changing the Calling Party Number Prior to the call being placed by ARS after it determines where the call is coming from. Unfortunately there is nothing within the Controller that can provide this kind of Intelligence and Dynamic changing of Calling Party Numbers. Although I do have an idea of how to write the program to do that I do not know of one that already has that function built in as I don't think it is part of Intelligent Router's functions to change the Calling Party Number.

Now another user within the forums, Dwayneg, a good technician in his own right if I do say so myself, has an interesting way to try and do this, but it may not be a valid solution for you.

Actually possible, but may not be practical depending on volume.  I've done this for a company that was running two competing companies and needed to send different CPN based on who they were representing.  For the larger company do things the normal way.  For each remote office you'd need a loop start trunk port and single line (analog station) port.  Loop these ports together, LS to SL.  For each remote you'd need enough ports for the maximum traffic you expect.  Program the SL ports as house phones to dial "92001" (or whatever SIP group is) and program them to send the CPN for the location they represent.
Now when you dial a specific LS port (or probably a trunk group containing multiple LS trunks) it will take its cross-connected SL port off hook, which will cause the house phone function to dial SIP TG...SIP will wait for DTMF of number to dial, then complete the call.  To the SIP carrier it will look like call is coming from SL port, will see that port's CPN.
For my customer the person placing the call decides whether to call normally or use the special trunk group.  But in your case the 5000 could do this automatically using ARS:  user dials Houston number.  ARS sees it's Houston, and instead of sending to SIP trunks sends to Houston loop start trunk group.  SL goes off hook, dials SIP TG, then echoes dialed number into trunk.
I did this with SL/LS because I didn't need a lot, but I'm sure you could do with two ports on a T1 card, one port programmed as 24 OPX (analog station), one as LS trunks.

Thanks,

TE

[popolou]

TE

I thought i followed you up to your last post. 

I've added my comments to your sentences below for clarity only: -

Now, what he wants to do is for those stations that are answering the call [on Node 2] to present the DDI that is routed to them as their Outbound Caller ID (Calling Party Number) and that number belongs to a different System [on Node 1] and maybe even a different carrier and that can only be done if the carrier allows it. This is what is commonly referred to as Non-Native Caller ID.

Since the phone your are initiating the call with is on another node [yes] and you set its Calling Party Number to a DDI that is local to its own controller [no, not yet] and sending that information over when dialling out that is where your problem occurs.

Correct in that the phone initiating the call is on Node 2 but i want to set the CPN to a DDI that is local to Node 1 not Node 2. At the same time, those phones should only display that DDI when calls are routed via Node 1 and not display it within calling its own native market.

Perhaps a bit of the background. Both nodes route ARS calls to each other via a facility/routing group that is configured with IP routing. Node 1 has a local DDI that routes incoming CO trunk calls to Node 2 that rings in to stations within Node 2's HG. When ringing, the display on Node 2's phones shows the same username configured for the DDI under the call routing tables in Node 1. All expected behaviour.

When the reverse is happening, Node 2 (via IP routing again) calls a number within the Node 1 market and routes out over its CO trunks. The CLI that is now observed is the billable number for that line. I want to change it so that when the HG within Node 2 calls the Node 1 market via Node 1, it also shows the incoming DDI set for it.

Currently, Node 2 does not have any DDI configured that would conflict with the Node 1 whitelist. The DDI i want allocated is on the Node 1 whitelist.

Is this the same thing as you've said or am i confusing myself here? 

Cheers!
Pops

[Tech Electronics]

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

[Tech Electronics]

Pops,

I was looking through some of my notes on CPN and I found something I haven't thought about in a long time; I knew these notes would come in handy one day.

Back in the Axxess Days 9.X+ if you wanted a station to send out its CPN when forwarded or it couldn't be read properly then you could set the Local Attendant's CPN up to what you wanted it to be and it would go out as that.

Now, in your case you would need to create a fake Local Attendant and set its CPN to the number you want to use, but give that a try and see if it works. You also need to go into OLM and then the System Information and change the value for the following area Spare Byte Data 1 field to = 1. I think Voicemail also used the Local Attendant's CPN when calling out so this may not work for you so remember to change this back to 0 if it doesn't work the way you want it to.

You can test this by forwarding a phone to your cell and then call it to see if it provides the CPN of the Attendant or the CPN of the station or the CPN of the CO Trunk Group then make the change and try again. Again I have only done this a couple of times a long time ago and I am not sure what all it affects and it may not work at all in the 5000.

Local Attendant can be found under Station (Phone, Endpoint) Related Information -> Primary Attendants -> Local Attendant

Remember that the fake Attendant needs to be set as an Attendant for it be a viable option for Local Attendant unless you want your true local Attendant to call out using that CPN.

Thanks,

TE