PRI showing main number - Telco issue?

[Sean McQuade]

Hi guys,

We are having a problem at two different sites, so definitely seems to be a Telco issue but they are denying it is a problem on their end and are saying that everything is checking out okay.

Basically we are sending a DDI to the carrier, but the main number is being presented on outgoing calls. I have tried this using an external phone number mask, a CUCM translation, and a gateway translation and all have the same result - the gateway sees the correct CLID, but the PRI doesn't seem to be passing it through to the destination. Incoming calls to the DDIs work as expected.

I have done a debug on the ISDN and can see the DDI being presented - is  this definite proof that it's not a CUCM / gateway issue and that the  issue is definitely with the telco / PRI config? I'd guess if the Q931  debug is showing it, that's definitely the number being sent out.

Aug 27 22:56:07.406: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Calling num XXXXXXXXX79
Aug 27 22:56:07.406: ISDN Se0/0/0:15 Q931: Sending SETUP  callref = 0x0086 callID = 0x8007 switch = primary-net5 interface = User 
Aug 27 22:56:07.406: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x0086 
        Sending Complete 
        Bearer Capability i = 0x8090A3 
                Standard = CCITT 
                Transfer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xA98387 
                Exclusive, Channel 7 
        Progress Ind i = 0x8183 - Origination address is non-ISDN  
        Calling Party Number i = 0x0081, '0XXXXXXXX79' <--- This is the showing the correct DDI number, but 0XXXXXXXX50 (main number) is always presented on the destination.
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '0XXXXXXXXX2' 
                Plan:Unknown, Type:Unknown
Aug 27 22:56:07.570: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x8086 
        Channel ID i = 0xA98387 
                Exclusive, Channel 7
Aug 27 22:56:12.086: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8  callref = 0x8086 
        Progress Ind i = 0x8488 - In-band info or appropriate now available 
Aug 27 22:56:21.650: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0x8086 
        Progress Ind i = 0x8A81 - Call not end-to-end ISDN, may have in-band info 
Aug 27 22:56:21.794: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8  callref = 0x8086
Aug 27 22:56:21.794: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x008694425479
Aug 27 23:03:54.506: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x8086 
        Cause i = 0x8290 - Normal call clearing
Aug 27 23:03:54.506: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x0086
Aug 27 23:03:54.538: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x8086            

Thanks

Sean

[Jaime Valencia · Accepted solution]

Yes, it is.

That's the last part of the connection over which YOU have control, if you're sending the right info on the SETUP message but the other end sees something else, then it's telco's fault as they're over-writing it. Somewhere along the line between what you send and what the other end receives, that's changed, and all that, is not under your control.

Show them the debugs and they cannot tell you it's your system who is not sending the right info.

EDIT: I do assume you own the DID you're sending, otherwise, most telcos will do that by default, if you send something you don't own, they'll send usually the main DID for your range.

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Sean McQuade]

Thanks Jaime - going round in circles at the minute but just wanted to confirm I wasn't going mad. I guess I'll have to go back to them and fight the fight!

[paolo bevilacqua]

You may need to set calling number type/plan, typically national/ISDN, for the DID to be accepted by telco.

[James Hawkins · Accepted solution]

Hi,

I am based in the UK and can tell you what generally works for me - your mileage may vary.

I check how many digits the provider is sending me for the called number using debug isdn q931 on an incoming call. This is typically six digits but can sometimes be as few as four.

I then use either CUCM Calling Party Transformations or gateway translation rules to modify the Calling Party Number for outbound calls to send the same number of digits to the provider.

As long as the sent number is in the DDI range assigned to the circuit this normally works.

If it does not I would look at setting the calling number type and plan as per Paolo's post above.

[Sean McQuade]

Hi James - telco were insisting they needed the full DDI number, but have just changed this to only send out 6 digits (as per incoming calls) and it seems to be sending out the correct DDI now. Thanks

[abidnazeer]

I agrees with what James Hawkins  said .If its not working you can match the type and plan using translation rule and try

I think if telco didnt get the correct no of digits or sometimes plan it will show pilot number.

Your origination address is showing

Progress Ind i = 0x8183 - Origination address is non-ISDN 

[paolo bevilacqua]

abidnazeer wrote:
I agrees with what James Hawkins  said .If its not working you can match the type and plan using translation rule and try
I think if telco didnt get the correct no of digits or sometimes plan it will show pilot number.
Your origination address is showing 
Progress Ind i = 0x8183 - Origination address is non-ISDN  

Please note per OP above the issue has been resolved already and marked as such.