I have enabled that from the

Nashaatmusa · ‎06-22-2015

Hello Experts,

I have the following problem in my system that is kind of new to me, when i call a closed mobile phone from an IP phone that is registered to CUCM

i hear Ring back tone instead of Announcement that informs me that the mobile is closed, this is causing a lot of problems to the users as they don't know that the status of the phone is closed.

- the issue happens to all Cisco ip phone models.

the following call flow is implemented :

IP Phone ---- SCCP ---- CUCM ----- SIP ------ CUBE ------------ SIP ------------- Provider.

Collected CCSIP messages debugs from the gateway, please see the following

Invite Received from Call Manager,

102406: *Jun 22 12:46:31.463: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:5555962788883597@172.31.21.3:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.170.31:5060;branch=z9hG4bK607d9458500dcc
From: "t" <sip:0785505500@192.168.170.31>;tag=aeccc64a-4d9a-49ae-a58f-d89f9e1e529a-57073288
To: <sip:5555962788883597@172.31.21.3>
Date: Mon, 22 Jun 2015 07:18:41 GMT
Call-ID: e75b2400-5871b6d1-29fd2c-1faaa8c0@192.168.170.31
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Contact: <sip:0785505500@192.168.170.31:5060;transport=tcp>
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:192.168.170.31:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 3881509888-0000065536-0001639187-0531278016
Session-Expires: 1800
P-Asserted-Identity: "t" <sip:0785505500@192.168.170.31>
Remote-Party-ID: "t" <sip:0785505500@192.168.170.31>;party=calling;screen=yes;privacy=off
Max-Forwards: 70
Content-Length: 0

Gateway Sent Invite message to provider.

102407: *Jun 22 12:46:31.491: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:5555962788883597@212.118.26.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.230.2:5060;branch=z9hG4bKFA00C1089
Remote-Party-ID: "Nedal Atiyyat" <sip:0785505500@192.168.230.2>;party=calling;screen=yes;privacy=off
From: "Nedal Atiyyat" <sip:0785505500@192.168.230.2>;tag=B0A55570-490
To: <sip:5555962788883597@212.118.26.3>
Date: Mon, 22 Jun 2015 09:46:31 GMT
Call-ID: 65626123-17FA11E5-AAF59701-121457CB@192.168.230.2
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3881509888-65536-1639187-531278016
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1434966391
Contact: <sip:0785505500@192.168.230.2:5060>
Call-Info: <sip:192.168.230.2:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 60
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Length: 0

102408: *Jun 22 12:46:31.495: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.170.31:5060;branch=z9hG4bK607d9458500dcc
From: "Nedal Atiyyat" <sip:0785505500@192.168.170.31>;tag=aeccc64a-4d9a-49ae-a58f-d89f9e1e529a-57073288
To: <sip:5555962788883597@172.31.21.3>
Date: Mon, 22 Jun 2015 09:46:31 GMT
Call-ID: e75b2400-5871b6d1-29fd2c-1faaa8c0@192.168.170.31
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

102410: *Jun 22 12:46:31.535: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.230.2:5060;branch=z9hG4bKFA00C1089
Call-ID: 65626123-17FA11E5-AAF59701-121457CB@192.168.230.2
From: "Nedal Atiyyat"<sip:0785505500@192.168.230.2>;tag=B0A55570-490
To: <sip:5555962788883597@212.118.26.3>
CSeq: 101 INVITE
Content-Length: 0

102424: *Jun 22 12:46:45.059: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.230.2:5060;branch=z9hG4bKFA00C1089
Call-ID: 65626123-17FA11E5-AAF59701-121457CB@192.168.230.2
From: "Nedal Atiyyat"<sip:0785505500@192.168.230.2>;tag=B0A55570-490
To: <sip:5555962788883597@212.118.26.3>;tag=zvkxxz90-CC-23
CSeq: 101 INVITE
Contact: <sip:5555962788883597@212.118.26.3:5060;user=phone>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Content-Length: 327
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 153432369 153432369 IN IP4 212.118.26.3
s=Sip Call
c=IN IP4 212.118.26.7
t=0 0
m=audio 4044 RTP/AVP 8 0 18 4 2 97
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=fmtp:18 annexb=no

102425: *Jun 22 12:46:45.075: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 192.168.170.31:5060;branch=z9hG4bK607d9458500dcc
From: "Nedal Atiyyat" <sip:0785505500@192.168.170.31>;tag=aeccc64a-4d9a-49ae-a58f-d89f9e1e529a-57073288
To: <sip:5555962788883597@172.31.21.3>;tag=B0A58A80-7C9
Date: Mon, 22 Jun 2015 09:46:31 GMT
Call-ID: e75b2400-5871b6d1-29fd2c-1faaa8c0@192.168.170.31
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:5555962788883597@172.31.21.3:5060;transport=tcp>
Call-Info: <sip:172.31.21.3:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 303

v=0
o=CiscoSystemsSIP-GW-UserAgent 7960 5475 IN IP4 172.31.21.3
s=SIP Call
c=IN IP4 172.31.21.3
t=0 0
m=audio 16434 RTP/AVP 0 18 101 19
c=IN IP4 172.31.21.3
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000

Here the User is hearing ringing instead of the announcement, the 183 session progress is never Ack'd, or 200 Ok by neither way

MTP is checked on the Trunk , Could you please let me know what could cause this issue

Much appreciated.

Regards,

Vivek Batra · ‎06-22-2015

By the way at SIP level, this seems invalid SIP message flow. In case of delay offer (INVITE without SDP), SDP offer must be included in first reliable response which could be either 200 OK (for INVITE) or 180/183. If it's 180/183, it's mandatory to use 100rel/PRACK to justify the usage of reliable 183 Session Progress and PRACK must be sent with SDP answer.

Moreover there is no complete offer-answer done in this call flow hence I see very rare chance of media being relayed from service provider.

So either media (RBT) is being relayed from service provider or phone is playing locally. You can check show voip rtp connection to actually see if gateway is getting RTP packets from service provider by that time.

Thanks

Vivek

Nashaatmusa · ‎06-29-2015

Hello Vivek,

Thanks for your reply :) .

I have created a new SIP profile from CUCM 8.0.3 i have with the option to send a PRACK on 1xx Rel SIP messages, still no progress on this at all, from the deubg ccsip messsages on the gateway i can see the following:

1) CUCM sends Gateway Invite as we are trying to make the call

2) GW sends CUCM trying and Sends provider an Invite.

3) Provider Sends Trying

4) Provider checkes that the phone is closed and sends GW 183 session progress with SDP to play the announciation.

5) Gateway Sends the same 183 to CUCM.

6) CUCM Sends PRACK to GW

7) GW Sends 200 OK to CUCM

Call now hangs, no announcement is heard, the ringing stopped and now facing the silence issue with the phone is closed after the change on the profile.

the Trunk have an announciatior in its MRGL, where should i continue troubleshooting on this one.

Gw level , or CUCM level ?

please check attached :

CUCM --- GW

Call-ID: 16353680-58f1f0aa-2adeed-1faaa8c0@192.168.170.31

GW --- PROVIDER

Call-ID: 90D7BDEA-1CE111E5-99E59701-121457CB@192.168.230.2

Regards.

Nash

Suresh Subramanian · ‎06-29-2015

Hi Nash,

Try checking the option " Early Offer support for voice and video calls (insert MTP if needed)" in the SIP Profile applied to the CUBE SIP Trunk and check please?

EDIT: you would need to enable 'early offer' on the dial-peers facing the ITSP as well.

//Suresh Please rate all the useful posts.

Nashaatmusa · ‎06-29-2015

Hey Suresh,

I have already done that as well, but in CUCM 8.0.3 the options is as follows

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmcfg/bccm-712-cm/b06siprf.pdf

I have put the option to be CLEARMODE

Suresh Subramanian · ‎06-29-2015

do you have the command "voice-class sip early-offer forced" in dial-peer facing ITSP?

could you please attach the CUBE config?

//Suresh Please rate all the useful posts.

Nashaatmusa · ‎07-02-2015

Thanks for your answer,

I have tried the command on the dial-peer facing the provider and now have the problem when answer the call is dropped.

I can see that its a provider issue that they don't send SDP in the 200 ok of the response when using this command.

Debugs for the call and gateway configuration attached.

Vivek Batra · ‎07-02-2015

Seems again issue with SDP negotiation. As now gateway is sending INVITE with SDP with 100rel enabled, 180 Ringing response has 100rel required so gateway is responding with PRACK. At this point of time there is no issue and SDP negotiation has been completed.

Now 200 OK (of INVITE) received from service provider is without SDP. With PRACK used, there is no need to include SDP answer in 200 OK but somehow seems gateway is expecting to see SDP in 200 OK.

To prevent this, disable 100 rel on dial-peer pointing to service provider. Doing so, gateway will send INVITE with SDP offer and gateway will get SDP answer in 200 OK (and may be in 180/183).

Please check if this resolves your issue.

Sample configuration;

dial-peer voice 4013 voip
translation-profile outgoing outgoing-Uminah-sip
destination-pattern 555599627........
voice-class codec 1
session protocol sipv2
session target ipv4:212.118.26.3

voice-class sip rel1xx disable

voice-class sip early-offer forced
dtmf-relay sip-notify rtp-nte h245-signal h245-alphanumeric
no vad

PS: You don't have any SIP bind commands in your configuration.

Thanks

Vivek

Vivek Batra · ‎06-29-2015

As gateway is sending INVITE w/o SDP and received SDP offer in 1xx without PRACK being used on service provider side. This is not correct as per SDP offer-answer model. To avoid this and as mentioned by Suresh, use early offer on dial-peer facing service provider using command voice-class sip early-offer forced.

Thanks

Vivek

ansonantoo · ‎06-29-2015

Try to enable PRACK on CUCM under service parameters.

Set ‘SIP Rel1XX Options’ to ‘Send PRACK if 1xx Contains SDP’

Nashaatmusa · ‎06-29-2015

I have enabled that from the SIP profile but with no luck , the traces shows that the CUCM is sending the PRACK but gateway don't

Ringing instead of Announcment for Mobile calls