cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4597
Views
0
Helpful
36
Replies

ITSP-SIP-CUBE-SIP-CUCM

ashraf1891
Level 1
Level 1

Inbound call not connecting:

calling number 559903358

called number +966114817200 (translated to 7200)

________________________________________

below is my dial peers:

dial-peer voice 3 voip
description LOCAL-CALLS-1
translation-profile outgoing OUT
destination-pattern .T
session protocol sipv2
session target dns:fmc.stc.com.sa
session transport udp
voice-class codec 1
voice-class sip early-offer forced
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte sip-notify
no vad
!
dial-peer voice 1 voip
description TO-CUCM-PUB
destination-pattern ^[1-9]...
session protocol sipv2
session target ipv4:172.30.2.10
session transport udp
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte sip-notify
!
dial-peer voice 2 voip
description TO-CUCM-SUB
preference 1
destination-pattern ^[1-9]...
session protocol sipv2
session target ipv4:172.30.2.11
session transport udp
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte sip-notify
!
dial-peer voice 4 voip
translation-profile incoming IN
session protocol sipv2
session transport udp
incoming called-number +966.T
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte sip-notify
no vad

_______________________________________
attached is  the Debug CCSIP Messages

 

36 Replies 36

Please find the attached debug file

I see the CUBE is receiving 503 Service Unavailable from CUCM server. This CUCM server is unable to process the call. If you want to find which CUCM is this, then check session target IP in  Dial-peer 12.

Jul 26 10:08:32.323: //3022/33C860448DC2/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 10.228.56.90:5060;branch=z9hG4bKB813F2
From: <sip:+966557514861@fmc.stc.com.sa>;tag=A8785E3-D88
To: <sip:8348@10.228.56.96>;tag=180~fbe964ed-730f-4251-b1fb-bdb3cac95554-44731732
Date: Wed, 26 Jul 2023 10:08:29 GMT
Call-ID: 33C9E6A8-2AD311EE-8DC890AF-3E64217C@10.228.56.90
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=47
Server: Cisco-CUCM11.5
Session-ID: bd8360ec6dbf7dc9429226ba44731733;remote=5a6291272b8e54ee8d46c403516c35ae
Content-Length: 0

dial-peer 12 is pointing to Call Manager publisher and  IP phone is ringing and when you try to answer the call it become unresponsive and we are not able to hear ring on mobile.

It could be related to media resource not available as call is disconnecting with CV 47. I see in the logs that the endpoint is ringing. The issue could be due to codec mismatch.

Outgoing calls

Just to be clear I’m not saying that content of the Req-URI is the issue that you have. The shared information in the debug does not indicate that.

Based on an error seen in the debug, “SIP: Trying to parse unsupported attribute at media level”, this post seems to be similar to what you’re seeing. https://community.cisco.com/t5/ip-telephony-and-phones/sip-trying-to-parse-unsupported-attribute-at-media-level/td-p/2861872
One thing suggested there is to check that the SIP security profile is set to the protocol that you have set in the gateway, ie UDP from the look of shared information.



Response Signature


TechLvr
Spotlight
Spotlight

@ashraf1891 
From the SIP logs you shared, it is evident that the CUCM cluster does not respond to the incoming SIP invites from the CUBE.

On the SIP Trunk configuration page, can you verify that the "Run On All Active Unified CM Nodes" box is checked? You did not capture that field in the screenshots you shared. Make sure you reset the SIP trunk after making any changes. 

If SIP trunk runs on all active nodes and incoming calls issue still persists, then make sure that the CallManager service is running on both 172.30.2.10 and 172.30.2.11. There may be a third CUCM node in your cluster that handles internal and outbound calls but when it comes to inbound calls, you are only pointing them to two nodes which may not have the CallManager service running.