cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4008
Views
15
Helpful
16
Replies

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

Xian Li
Level 1
Level 1

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

 

 

 

16 Replies 16

Oruc Akpinar
Level 1
Level 1

Hello,

 

try this configuration;

 

 

dial-peer voice 12 voip
translation-profile incoming fr-ITSP

destination-pattern 8147
session target ipv4:CUCMIP
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:CUCMIP
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad

 

num-exp 93378147 8147

 

 

Shouldn't all the dial peers be SIP rather than H.323.  And obviously with SIP settings for DTMF.

Personally I always match incoming calls to dial peers by SIP URI, and use COR to stop incoming calls bouncing back out if there's an unallocated number.  But there are lots of way to do this.