cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1963
Views
80
Helpful
20
Replies

Incoming Call Target Session Problem

Hary_CsC
Level 1
Level 1

Hi, guys

 

I've a problem with the session target.
why is the result of the incoming call session target going to CUCM sub1 even though I have directed the dial-peer to go to CUCM pub.
details as follows:

-------------------------------
CUCM pub : 10.74.118.4
CUCM sub1 : 10.74.118.68
-------------------------------

dial-peer voice 1 voip
description *** Outbound LAN Side Dial-Peer (INCOMING CUCM Publisher) ***
preference 1
destination-pattern 4....
session protocol sipv2
session target ipv4:10.74.118.4
voice-class codec 1
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte sip-kpml h245-alphanumeric h245-signal
!
dial-peer voice 2 voip
description *** Outbound LAN Side Dial-Peer (INCOMING CUCM Subcriber) ***
preference 2
destination-pattern 4....
session protocol sipv2
session target ipv4:10.74.118.68
voice-class codec 1
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
dtmf-relay rtp-nte sip-kpml h245-alphanumeric h245-signal
!

 

* Attached results  #show call active voice compact (session target points to CUCM sub1).

* CUCMG has also made cucm pub the primary.

 

20 Replies 20

With Preference 1, it should use dial-peer 1.

 

Everything okay with CUCM PUB ?

 

 



Response Signature


The CMG in CM does have little to any correlation with inbound calls between your voice gateway and CM. That is used to control what nodes is used when making calls from a device or trunk in CM. In this specific case it would be used to control calls sent from CM to your gateway. Only in older versions of CM this would have an influence on inbound calls. If memory serves me it’s before CM 8 and the ability to set trunks or gateways to run on all nodes.

Can you please share with us the entire configuration of your gateway, or at least the parts pertaining to call routing and also share the status of your dial peers? It would also be of help if you could share the output of debug voip ccapi inout for an inbound call.

Stupid control question, do you have the Call Manager service activated and running on both of your nodes?



Response Signature


Hi @Roger Kallberg 

 

do you have the Call Manager service activated and running on both of your nodes?
sure, even i have tried to restart the service

 

Here I send the data you need:
debug voip ccapi inout and Config VG

Based on the provided debug information your call use dial peer 11 as the inbound and dial peer 1 as the outbound. From what I can tell dial peer 1 is the one that points towards your publisher.



Response Signature


Hi @Roger Kallberg 

 

yes, call use dial peer 11 as the inbound and session target ipv4 is IP Provider.

How can incoming calls go to cucm pub ?

 

Thanks

Roger is saying that the call is going out to the pub, according to the debug.

If you look at line 53 it says: "Incoming Dial-peer=11"

And if you look at line 86 it says: "Outgoing Dial-peer=1"

Maren

Dial peer 1 is AFAIKT the dial peer that points to your publisher. As previously written this is the dial peer that from you debug outputs is used for call towards your CM.



Response Signature


A debug ccsip messages will show if the router is attempting to use the pub dial-peer and then fail over to the sub dial-peer, or if it is not attempting the pub dial-peer in the first place.

If you are reluctant to run that debug on the router, you can also pull the Cisco CallManager service trace file from the Pub and Sub and looking to see if the router is reaching out to the Pub at all.

In addition to checking that the CallManager service is running on the Pub, another thing to check is that the Pub's IP address is in the routing table. I doubt either of these is the problem, but it's worth checking in case there is some weirdness happening.

And, as was suggested, the full config of your router may offer additional clues.

Maren

Hi @Maren Mahoney 

 

Here I send the data you need:
debug voip ccsip messages inout and Config VG

 

My number 02155777xxx

IVR 44000

 

Thanks

Unless I'm missing something... The call *is* being sent to your Pub. The IP address 10.74.118.68 appears as neither a source or destination of signaling in either the debug ccsip messages you posted for me or the debug voip ccapi inout that you posted for @Roger Kallberg

In both of the debugs the signaling is going to 10.74.118.4, which you have indicated is your Publisher. Here is a ladder diagram of the debug ccsip messages and shows the call flowing from the ISP (internal IP of the ISP) to the ISP-facing interface of the CUBE, and then from the CUBE to the IP address of the Publisher (as indicated in the INVITE).

So... What makes you believe that the call is flowing through the subscriber?

Maren

Ladder - HaryCsC.jpg

Hi @Maren Mahoney 

 

Thank you for your reply.

Yesterday I did the relocation of the UCS sub rack (data center). I think it should be fine because there is a cucm pub but apparently the call can't come in and after I saw "show call active voice compact" a call came to the cucm sub, even though the sub's ucs was down because it was relocating of rack.

 

Thank

Hi there,

 

To add to Roger's suggestion about applying SIP profiles to your dial-peers, it is generally a good idea to do that anyway because if you have any reachability issues to your CM Nodes, the dial-peer will be shown as "Busy Out" when you issue the command "show dial-peer voice sum" on your CUBE. Obviously doesn't identify the root cause, but it tells you there is a problem. Based on the debugs however, it suggests that the call is reaching your PUB. 

 

Is your Subscriber also an MTP? From the 200 OK message in your CCSIP, the IP address of your Subscriber is being used in the RTP stream so that might explain your findings.

 

394868: Aug 30 07:28:16.384: //2311070/AD137CF39AEB/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.74.118.130:5060;branch=z9hG4bKAF9881E94
From: <sip:02155777508@10.18.19.57>;tag=4E2C4B60-1752
To: <sip:44000@10.74.118.4>;tag=24322~79881ea1-d020-4a27-900b-2008ddc67446-28052121
Date: Mon, 30 Aug 2021 07:28:16 GMT
Call-ID: AD14B543-89A11EC-9AF1BEB9-1158DB6E@10.74.118.130
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM11.0
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Require: timer
Session-ID: ce4b0bda2e42fc1ef2d63eba28052123;remote=e8fd42cfe82c3dc7d0fad75deab24322
P-Asserted-Identity: <sip:44005@10.74.118.4>
Remote-Party-ID: <sip:44005@10.74.118.4>;party=called;screen=yes;privacy=off
Contact: <sip:44000@10.74.118.4:5060>
Content-Type: application/sdp
Content-Length: 244
v=0
o=CiscoSystemsCCM-SIP 24322 1 IN IP4 10.74.118.4
s=SIP Call
c=IN IP4 10.74.118.68
b=TIAS:64000
b=CT:64
b=AS:64
t=0 0
m=audio 28498 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 

 

Excellent catch! -- Maren

Hary_CsC
Level 1
Level 1

Hai @Maren Mahoney @Roger Kallberg 

 

What I want to ask is whether my vg configuration is correct? especially dial-peer.

 

Thank

BR Haryadi

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: