cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1433
Views
0
Helpful
4
Replies

SIP caller, SIP Trunk and SNR

hanlykent
Level 1
Level 1

Hi All,

Found an unusual issue which I am hoping someone can point me in the right direction

We are running CUCM 10.5(2) ---> SIP Trunk --> CUBE ---> ITSP

Internal SCCP phone A calls  Internal SCCP phone B (which has SNR. The SNR mobile destination has been incorrectly entered on purpose)

Internal SCCP phone A hears ring back, Internal SCCP phone B rings, and the call the SNR fails ( unknown to SCCP phone A)

Internal Jabber phone C calls Internal SCCP Phone B (which has SNR. The SNR mobile destination has been incorrectly entered on purpose)

Internal Jabber phone C hears ring back and then hears "We advise that the number you have dialed is currently switched off or is unavailable, please try again later", Internal SCCP Phone B continues to ring.

I disable SNR on SCCP phone B and try calling from Inter Jabber phone C again, call just rings as normal.

So it would seem the message being instigated by the failed call via SNR

Why do I hear the message on the failed SNR call, when calling from a SIP phone?

I debug ccsip messages on the CUBE call for failed SNR call:

INVITE comes in from CUCM

SIP/2.0 100 Trying sent back to CUCM

INVITE goes out to ITSP

Receive SIP/2.0 100 Trying from ITSP

Receive SIP/2.0 183 Session Description from ITSP

SIP/2.0 183 Session Description send to CUCM

### At this point I hear the message on the Internal Jabber phone C ###

CANCEL received from CUCM (I end the call from Jabber phone C)

Last 2 messages from the debug below:

Sep 15 13:13:59.039: //19953829/6FE864800001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.20.20.20:5060;branch=z9hG4bK15360e623ca3ea
From: "Test 1" <sip:02XXXXXXXX@10.20.20.20>;tag=4893343~511c1f8c-03d8-4f7b-8410-0f199e8a9429-39046522
To: <sip:0412345678@10.10.10.10>;tag=432A154C-5E0
Date: Thu, 15 Sep 2016 03:13:58 GMT
Call-ID: 6fe86480-7da111f6-a79fc-b09180a@10.20.20.20
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: kpml, telephone-event
Contact: <sip:0412345678@10.10.10.10:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 364

v=0
o=CiscoSystemsSIP-GW-UserAgent 1634 8073 IN IP4 10.10.10.10
s=SIP Call
c=IN IP4 10.10.10.10
t=0 0
m=audio 18976 RTP/AVP 8 101
c=IN IP4 10.10.10.10
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
m=video 0 RTP/AVP 126
c=IN IP4 10.10.10.10
m=application 0 RTP/AVP 125
c=IN IP4 10.10.10.10
a=rtpmap:125 H224/4800


Sep 15 13:14:09.983: //19953829/6FE864800001/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:0412345678@10.10.10.10.10:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.20.20:5060;branch=z9hG4bK15360e623ca3ea
From: "Test 1" <sip:02XXXXXXXX@10.20.20.20>;tag=4893343~511c1f8c-03d8-4f7b-8410-0f199e8a9429-39046522
To: <sip:0412345678@10.10.10.10>
Date: Thu, 15 Sep 2016 03:13:58 GMT
Call-ID: 6fe86480-7da111f6-a79fc-b09180a@10.20.20.20
User-Agent: Cisco-CUCM10.5
CSeq: 101 CANCEL
Max-Forwards: 70
Content-Length: 0

Anyway assistance in understanding and resolving the issue would be appreciated.

Thanks

Kent

4 Replies 4

Jonathan Unger
Level 7
Level 7

Hi Kent,

When phone C calls phone B the PSTN invokes early media on the SNR leg. Phone C should ignore the early media because CUCM should send "ignore-early-media=true" in the Call-Info SIP header. This is a defect with some phone firmware loads (early media should not be permitted for SNR calls).

This issue only applies to SIP early media which is why you don't see the problem with SCCP phones (phone A).


This is an example of a bug that has the same issue on a 9971 (there are quite a few other early media bugs as well with other models):
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuj07520

What phone model and firmware load does phone C have?

Hi Jonathan,

Thanks for the reply.

Jabber Phone C is Cisco Jabber for Windows (version 11.7 build 42920) on my PC.

I ran wireshark on my PC while attempting the call  (Ext 2685 call Ext 2040 which as SNR enabled). This seems to be the last SIP messages before I hang up because I hear the message:

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.30.30.10:49440;branch=z9hG4bK000068ff
From: "User Name" <sip:2685@cucm2.company.com.au>;tag=a088b41aecdc000700001b80-00007a2d
To: <sip:2040@cucm2.company.com.au>;tag=5123451~511c1f8c-03d8-4f7b-8410-0f199e8a9429-39094509
Date: Tue, 20 Sep 2016 22:33:41 GMT
Call-ID: a088b41a-ecdc0004-000025cd-00004018@10.30.30.10
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Server: Cisco-CUCM10.5
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= Unknown; orientation= to; ui-state= ringout; gci= 2-868654; isVoip; ignore-early-media=true; call-instance= 1
Send-Info: conference, x-cisco-conference
Remote-Party-ID: "Company Test 1" <sip:KTest.1@company.com.au;x-cisco-number=2040>;party=called;screen=yes;privacy=off
Contact: <sip:2040@10.20.20.20:5060;transport=tcp>
Content-Length: 0

Perhaps something missing on my SIP Profile?

I am going to downgrade Jabber for Windows to see earlier versions have the same issue. 

I downgraded from Jabber 11.7.0 to 11.6.1 .

Unfortunately, I still have the issue.

An update on further troubleshooting.

I upgraded from Jabber 11.7.0 to 11.8 Drop 2 (EAP).

Early media issue is still heard

All our internal Cisco 79XX phone are registered via SCCP, so I changed the firmware on one phone to SIP and registered to CUCM.

Using the same call scenario, I used the SIP phone to call the SCCP phone (with SNR enabled)

No early media is heard on the SIP phone from the SNR call.

I configured Jabber with the same SIP profile and early media IS heard.

I would be interested to know whether anyone else out there is having this same issue.

I have logged a ticket with our Cisco third party support to investigate.

Hello hanlykent,

 

Have you solve this issue? We have the same issue in exec scenario.