cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1481
Views
0
Helpful
6
Replies

Third Party SIP transfer

fwalstrom
Level 1
Level 1

Looking for some insight. I have a couple of wireless third party SIP phones configured in my Call Manager. Whenever I got to make a transfer from the SIP phones, both blind and consult transfer. I get a busy tone on the SIP phone after completing the transfer. I've also looked through the trace files, nothing really stands out and looks like a normal call to me.

1 Accepted Solution

Accepted Solutions

Hi ,

I found the issue:

>>> Bye sent here to the first leg of the SIP phone.

03558120.001 |09:37:10.079 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 100.64.0.53:[5063]:
[199480,NET]
BYE sip:+19073348167@100.64.0.53:5063 SIP/2.0
Via: SIP/2.0/UDP 100.64.0.51:5060;branch=z9hG4bK64ae6a90cf
From: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
To: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
Date: Fri, 18 Nov 2016 18:37:09 GMT
Call-ID: 1309260530@100.64.0.53
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 104 BYE
Content-Length: 0

>>> 200 Ok for the BYE

03558372.001 |09:37:10.228 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 341 from 100.64.0.53:[5063]:
[199489,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.64.0.51:5060;branch=z9hG4bK64ae6a90cf
From: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
To: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
Call-ID: 1309260530@100.64.0.53
CSeq: 104 BYE
User-Agent: Yealink SIP-W52P 25.73.0.40
Content-Length: 0


Ideally, the signalling should have ended here and CUCM has deleted all the instance from its DB.

However, the third party phone sends back another BYE to CUCM which is undesired.

03558399.001 |09:37:10.352 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 632 from 100.64.0.53:[5063]:
[199490,NET]
BYE sip:8686570@100.64.0.51:5060 SIP/2.0
Via: SIP/2.0/UDP 100.64.0.53:5063;branch=z9hG4bK4217983017
From: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
To: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
Call-ID: 1309260530@100.64.0.53
CSeq: 5 BYE
Contact: <sip:+19073348167@100.64.0.53:5063>
Authorization: Digest username="9073348167", realm="ccmsipline", nonce="XJoH9iJRoDshDC4kmNQtVsKiWnBh+hjP", uri="sip:8686570@100.64.0.51:5060", response="945764bfd194cb9d2a60dabc29df9aa4", algorithm=MD5
Max-Forwards: 70
User-Agent: Yealink SIP-W52P 25.73.0.40
Content-Length: 0


To this, CCM responds as follows as the call is already deleted from CCM end.

03558401.001 |09:37:10.353 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 100.64.0.53:[5063]:
[199491,NET]
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 100.64.0.53:5063;branch=z9hG4bK4217983017
From: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
To: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
Call-ID: 1309260530@100.64.0.53
CSeq: 5 BYE
Content-Length: 0


This would have then caused the third party phone to generate the busy signal.

Seems a buggy behavior at Third party SIP phone end that needs to be fixed.


Please rate and mark correct if helpful.

Regards,

Hitesh

View solution in original post

6 Replies 6

hsood
Cisco Employee
Cisco Employee

Hi,

Does the transfer complete fine but it is just that the the SIP phone hears busy?

If that is so, the only thing I can think of is that when the CUCM sent the CANCEL message, the SIP phone is unable to understand it correctly.

Possibly a set of CCM traces would help in identifying the exact issue. Can you attach those?

Regards,

Hitesh

Yes the transfer completes fine. I looked through the traces, the call/call legs look like a normal call. You maybe be right about the the CUCM sending the cancel message. Is there a way I can correct that issue?

If you post a set of CCM traces, I can have a quick look but if the phone is unable to handle the SIP message correctly, then there would be no such setting on CCM end for sure.

You will need to contact the third party vendor.

Please rate if useful.

Regards,

Hitesh

Here's the trace, it's in a zip file

Hi ,

I found the issue:

>>> Bye sent here to the first leg of the SIP phone.

03558120.001 |09:37:10.079 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 100.64.0.53:[5063]:
[199480,NET]
BYE sip:+19073348167@100.64.0.53:5063 SIP/2.0
Via: SIP/2.0/UDP 100.64.0.51:5060;branch=z9hG4bK64ae6a90cf
From: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
To: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
Date: Fri, 18 Nov 2016 18:37:09 GMT
Call-ID: 1309260530@100.64.0.53
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 104 BYE
Content-Length: 0

>>> 200 Ok for the BYE

03558372.001 |09:37:10.228 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 341 from 100.64.0.53:[5063]:
[199489,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.64.0.51:5060;branch=z9hG4bK64ae6a90cf
From: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
To: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
Call-ID: 1309260530@100.64.0.53
CSeq: 104 BYE
User-Agent: Yealink SIP-W52P 25.73.0.40
Content-Length: 0


Ideally, the signalling should have ended here and CUCM has deleted all the instance from its DB.

However, the third party phone sends back another BYE to CUCM which is undesired.

03558399.001 |09:37:10.352 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 632 from 100.64.0.53:[5063]:
[199490,NET]
BYE sip:8686570@100.64.0.51:5060 SIP/2.0
Via: SIP/2.0/UDP 100.64.0.53:5063;branch=z9hG4bK4217983017
From: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
To: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
Call-ID: 1309260530@100.64.0.53
CSeq: 5 BYE
Contact: <sip:+19073348167@100.64.0.53:5063>
Authorization: Digest username="9073348167", realm="ccmsipline", nonce="XJoH9iJRoDshDC4kmNQtVsKiWnBh+hjP", uri="sip:8686570@100.64.0.51:5060", response="945764bfd194cb9d2a60dabc29df9aa4", algorithm=MD5
Max-Forwards: 70
User-Agent: Yealink SIP-W52P 25.73.0.40
Content-Length: 0


To this, CCM responds as follows as the call is already deleted from CCM end.

03558401.001 |09:37:10.353 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 100.64.0.53:[5063]:
[199491,NET]
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 100.64.0.53:5063;branch=z9hG4bK4217983017
From: "Switchboard" <sip:+19073348167@100.64.0.51>;tag=2178068900
To: <sip:98686570@100.64.0.51>;tag=38171~f71e065f-8e58-484e-9f2b-d2d3e2ab6c79-23115605
Call-ID: 1309260530@100.64.0.53
CSeq: 5 BYE
Content-Length: 0


This would have then caused the third party phone to generate the busy signal.

Seems a buggy behavior at Third party SIP phone end that needs to be fixed.


Please rate and mark correct if helpful.

Regards,

Hitesh

Thank you, I'll try a firmware upgrade. If that doesn't help I'll contact support.