incoming SIP call outbound leg/dial peer doesn't forward call to CUCM

[Xian Li]

Hi,

Incoming SIP call hits our gateway from ITSP via SIP trunk on the inbound VOIP call leg/dial peer 12 OK, but it can't hit outbound VOIP call leg/dial peer 103. instead it hits a POTS dial peer 10 for our ISDN calls. And the call drops of course.

below are the config of three dial peers:

dial-peer voice 12 voip
translation-profile incoming fr-ITSP
session target ipv4:1.1.1.1
incoming called-number 93378147
voice-class codec 1
dtmf-relay h245-alphanumeric
no vad

dial-peer voice 1003 voip
preference 3
destination-pattern 8147
session protocol sipv2
session target ipv4:1.1.1.1
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad

dial-peer voice 10 pots
tone ringback alert-no-PI
translation-profile outgoing CFD
destination-pattern .T
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8
port 0/0/0:15

Here is the debug output showing the incoming call first hit VOIP dial peer 12 OK on inbound call leg, but hit POTS dial peer 10 instead of VOIP dial peer 101 on outbound call leg.

hits inbound dial peer:

Jun 18 04:54:24.620: //-1/9D9C562EAB9D/CCAPI/cc_api_call_setup_ind_common:
Interface=0x142CA4FC, Call Info(
Calling Number=0276001579,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=93378147(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=12, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=501635
Jun 18 04:54:24.620: //-1/9D9C562EAB9D/CCAPI/cc_api_call_setup_ind_common:
Interface Type=0, Protocol=3
Jun 18 04:54:24.620: //-1/9D9C562EAB9D/CCAPI/ccCheckClipClir:
In: Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 18 04:54:24.620: //-1/9D9C562EAB9D/CCAPI/ccCheckClipClir:
Calling Party Number Is User Provided
Jun 18 04:54:24.620: //-1/9D9C562EAB9D/CCAPI/ccCheckClipClir:
Out: Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 18 04:54:24.620: //-1/9D9C562EAB9D/CCAPI/cc_api_call_setup_ind_common:
After Number Translation Checking:
Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=93378147(TON=Unknown, NPI=Unknown)
Jun 18 04:54:24.620: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

hits incorrect outbound dial peer:

Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=10, Params=0x199A8A0, Progress Indication=NULL(0)
Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/ccCheckClipClir:
In: Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/ccCheckClipClir:
Calling Party Number Is User Provided
Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/ccCheckClipClir:
Out: Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/ccCallSetupRequest:
Destination Pattern=.T, Called Number=8147, Digit Strip=TRUE
Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/ccCallSetupRequest:
Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=8147(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=0276001579, Final Destination Flag=TRUE,
Guid=9D9C562E-B056-11EA-AB9D-AD8848067C66, Outgoing Dial-peer=10
Jun 18 04:54:24.624: //501635/9D9C562EAB9D/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=0276001579
----- ccCallInfo IE subfields -----
cisco-ani=0276001579
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=0
dest=8147
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

Any idea how can I make the second call leg hits the correct VOIP dial peer 103 instead of POTS dial peer 10?

Thank you

[Ritesh Desai]

Hi @Xian Li 

dial-peer voice 1003 voip
preference 3
destination-pattern 8147

remove the preference 3 command. Modify the destination-pattern as ^8147

Try making call and see if it works. In case doesn't then enable below debugs and attach here.

#deb voice dial-peer inout

#debug voice ccapi inout

Hope it works and helps.

regards,

Ritesh Desai

Please rate helpful post.

[Xian Li]

Hi Ritesh,

Thank you for your reply. 

I have removed the preference 3 command and modified the destination-pattern as ^8147, but still no luck.

Here is the debug and show output. Let me know what you think.

Regards

[TONY SMITH]

Can you share your voice translation-profile and voice translation-rule configuration?

A called number of 8147 should match a dial peer with destination pattern 8147 in preference to one with .T, irrespective of dial peer preference.   

You can run the show command "show dialplan number 8147" to confirm.

Also could you share a quick "sh dial-peer voice sum" just to see what else is there?

Has the gateway been reworked from a previous configuration, just asking because you have h323 specific settings applied to a SIP dial peer.

[Xian Li]

Hi Tony,

Thank you for your email. Please attached.

You are correct, we tried to use a ISDN voice gateway in conjunction with the SIP trunk with our ITSP. The ISDN voice gateway registered with CUCM using H323. Is this causing the problem?

Regards

[Roger Kallberg]

The call is hitting dial peer 1003 and sent to CUCM, however it’s not found so the CM sends back a disconnect. It's seen on the debug as a disconnect cause=1.

Jun 19 03:24:33.641: //505823/3AB5A4E0B78E/CCAPI/ccCallDisconnect:
   Cause Value=1, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=1)

Then the call is sent out via dial peer 10.

You need to check in CUCM that the inbound CSS on the gateway/trunk sees the called number.

This is one of the problem with using a .T match as it would make calls go out via that dial peer even if it's not actually intended.

How are you sending called number from CUCM to the voice gateway for a call to PSTN, does it have any break out number like 9 or 0 at the beginning of the called number? If so I guess that you remove it on the way out to PSTN in the gateway, or do you strip it already in CUCM? If you do the later I would encourage you to stop doing that and do it in the gateway instead so that you can use that breakout code as part of the route string on your PSTN dial peer. For example let's say that you do use a 9 as the prefix for calls to PSTN. Then you can set 9T as the match on dial peer 10 and have a discard digit instruction set on either the dial peer itself or use a voice translation to drop the 9 from the called number, where the last option would be my personal preference because I think it's cleaner and clearer to do all digit manipulations with one type of function instead of mixing and matching multiple ways to do the same thing.

[Roger Kallberg]

In your inbound call leg you have this.

Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=93378147(TON=Unknown, NPI=Unknown)

And in your outbound call leg you have this.

Calling Number=0276001579(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=8147(TON=Unknown, NPI=Unknown),

Are you somewhere in-between these modifying the called number so that it would match what you have as the destination on your wanted outbound dial peer 1003 towards CUCM as that matches called number 8147? If not it's not at all surprising that you don't get a match on the dial peer that you intend and instead get a match on your dial peer towards PSTN as that matches any digits with the .T. Using this is a pretty lacy and risky thing that should be avoided if possible.

[Xian Li]

Hi Roger,

Thank you for your reply.

There is a voice translation-profile "fr-ITSP" which removes 9337 from 93378174 and only keeps 8174. See below config:

voice translation-rule 10
rule 1 /^9337/ //
!
voice translation-profile fr-ITSP
translate called 10

Please see all attachments from my previous relies for more info.

[TONY SMITH]

This may not be relevant but your incoming dial peer 12 is not set as SIP so I'm surprised it's matching.  Personally I'd set that to SIP and match incoming explicitly by SIP URI.   

Thinking about this as being converted from an h323/ISDN gateway to add the SIP ITSP, have you got all the settings right under voice service and sip?  For example do you allow SIP to SIP calls?   Can you post up the output from "sh run | s voice service"?

Edit - I don't think you need the leading "^" in your destination pattern, dial peer patterns match from the beginning by default and a pattern of "8147" won't match anything longer or shorter.

[Xian Li]

Hi Tony,

You are right, I managed to get the incoming call working by placing allow SIP to SIP calls under voice service config.

However, I tried to make a test call from my mobile to a desk phone in the office, I can hear the desk phone rings, but after I picked up the call from desk phone, there is no voice, I can still hear my mobile on ringtone. After about 30 seconds, it shows my mobile place another call from the desk phone screen.

I have attached the output of  DEBUG CCSIP ALL in the attachment.

[Ayodeji Okanlawon]

Hi,

First question to ask is how is your cube configured to reach your ITSP? Do you have two interfaces? Ie one facing the ITSP and the second one facing CUCM?

If you do then you need to configure the correct bind statements on each dial peer.

Please refer to this document explaining how sip bind statements work.

https://community.cisco.com/t5/collaboration-voice-and-video/cube-sip-media-and-signalling-binding-to-an-interface/ba-p/3107153

Secondly, don't use debug ccsip all unless you are asked to. Always start with

debug ccsip messages..

So please configure your sip bind statements on your dial-peers and if it still does not work enable debug ccsip message and attach both debug and your sh run here

Thanks

[Xian Li]

Hi Ayodeji,

We are using the same physical interface for both SIP trunk to our CUCM and SIP trunk to our ITSP, will this be the issue?

CUCM --- (SIP trunk) --- CUBE --- (SIP trunk) --- ITSP
So here the two SIP trunks shared the same physical interface. Does it has to use different physical interface?

Thank you

[Roger Kallberg]

Not having two interfaces sort of negates the purpose of a SBC, in the sense that one of its primary use case is to be a border between your internal infrastructure and the service provider, hiding the internal systems from the outside service provider as the traffic from CUCM and devices travels through the SBC. Possibly it would be possible to achieve the same function with one interface, but it would be a bodged setup if you ask me.

Would you mind to share the entire sh run from your router so that we can verify your whole setup?

[TONY SMITH]

Your debug only shows one actual SIP message, the incoming Invite.  Please show "debug ccsip mess" from the first Invite until the call clears down.

[Xian Li]

Hi Tony,

We are using the same physical interface for both SIP trunk to our CUCM and SIP trunk to our ITSP, will this be the issue?

CUCM --- (SIP trunk) --- CUBE --- (SIP trunk) --- ITSP
So here the two SIP trunks shared the same physical interface. Does it has to use different physical interface?

Thank you