cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
924
Views
5
Helpful
3
Replies

Unexpected dial-peer used with CUCM to CUBE

CourtneyKPrin
Level 1
Level 1

Hi,

I'm migrating from PRI to SIP trunk with new ITSP. I created new dial-peers and a test call from an inside phone to mobile number isn't using the expected dial peer 300 between CUCM and CUBE. Instead it's using an existing dial-peer 2. I'm not sure why 2 already exists. The phone call is using the correct outbound dial-peer 400 and working, but I would prefer to use incoming 300 over 2. Does dial-peer 300 look correct? Why doesn't the uri take precedence over incoming called-number .? 

 

dial-peer voice 2 voip
incoming called-number .
voice-class codec 1
voice-class h323 1

 

dial-peer voice 300 voip
description CM to CUBE
session protocol sipv2
incoming uri via FromCUCM
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte sip-notify
no vad

 

voice class uri FromCUCM sip
host ipv4:10.130.3.73
host ipv4:10.130.3.105

 

debug output but hiding actual phone numbers

34209507: Dec  8 16:45:13.139 CST: //-1/8010E8000001/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x3EBF6C80, Call Info(
   Calling Number=618208XXXX,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=1626417XXXX(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=2, Progress Indication=NULL(0), Calling IE Present=TRUE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=370214

 

3 Replies 3

Without output from debug ccsip message it would be hard to give you an actual answer on your question.

I would recommend you to add “voice-class codec 1” on dial peer 300.



Response Signature


Steven L
Spotlight
Spotlight

In general, it is bad practice to have a inbound dial peer that does not specify session protocol or is just so broad that anything can literally match it.

 

that being said, there are a lot of reasons why this might be happening . the debugs Roger specified is a good start.

 

i would also provide a full config here as well.

Are you sure the incoming call is being sent using SIP? I would think that would exclude DP 2 if it was. That said, you could remove and re-add DP 2 so it is later in the config. I know URI matching is supposed to have precedence over incoming called number. I agree with @Roger Kallberg  on seeing the debug output. I would add "debug voip ccapi inout" too in case it isn't coming via SIP so you would see that as well. One last thing. What does your "voice service voip" section look like? It sounds like you don't want to allow connections between H.323 and SIP. If you have those "allow-connection" statement in that section, you should remove them if you don't want to allow that.