IP Phone Fails to Re-Register with CUCM Subscriber - Wireshark Trace Included

[conor.maton]

Hello all,

I have the following CUCM setup:

• CUCM Publisher - 10.192.33.68
• CUCM Primary Subscriber: 10.192.33.60
• CUCM Secondary Subscriber: 10.192.41.60
• CUCM Tertiary Subscriber: 10.192.33.61
• Third-Party SIP Phone (IP Trade T4): 10.192.33.20

I can confirm the network is ok as this has been tested thoroughly.

In normal operating circumstances, the SIP Phone registers with 10.192.33.60. When this fails the SIP Phone registers with 10.192.41.60. However, when 10.192.33.60 comes back online, the SIP phones fails to re-register with CUCM.

See attached Wireshark trace monitoring the above.From my understanding:
• You can see that 10.192.33.20 subscribes to 10.192.33.60 (No. 20 - Status: 200 OK (1 binding).
• When I disconnect 10.192.33.60, you can see the three way TCP handshake fails to 10.192.33.60 (IDs 75-80). 10.192.33.20 then subscribes to 10.192.41.60 (No. 91 - Status: 200 OK (1 binding).
• When I reconnect 10.192.33.60 you can see 10.192.33.20 makes multiple attempts to subscribe to 10.192.33.60, re-register to the 10.192.41.60 and also 10.192.33.61 but it isn't successful (IDs 141, 151, 160, 164, 168, 172, 176, 180 - Status 200 OK (0 bindings).
• On one occasion it seems the SIP request to 10.192.33.60 was '406 Not Acceptable' (No. 148).
• Also there is a 'REFER' SIP message to 10.192.33.60 (No. 144)

Could the Wireshark trace be analysed and advise why the re-registration is failing please?

Thanks in advance!

[tgaur]

Hi,

for Reg :

11 2019-12-06 16:57:58.129357 10.192.33.20 10.192.33.60 SIP 418 Request: REGISTER sip:10.192.33.60;transport=TCP (1 binding) | (application/x-cisco-remotecc-request+xml) (application/x-cisco-remotecc-request+xml)


Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.192.33.60;transport=TCP SIP/2.0
Message Header
From: "MSCS Primary"<sip:2500100100@10.192.33.60>;tag=7a89d7c9-3bc95de7-6b62-8a346d8-1421c00a-13c4-759
To: "MSCS Primary"<sip:2500100100@10.192.33.60>
Call-ID: 4898a37a-16ef2d7b-6b62-67b4a00-1421c00a-13c4-759
[Generated Call-ID: 4898a37a-16ef2d7b-6b62-67b4a00-1421c00a-13c4-759]
CSeq: 1 REGISTER
Via: SIP/2.0/TCP 10.192.33.20:5060;branch=z9hG4bK-58c9c3e4-6b62-1a37a5e-888e758
User-Agent: IPT-1011-R9.4_0.50675
Max-Forwards: 70
Supported: extended-refer, X-cisco-escapecodes, X-cisco-callinfo, X-cisco-service-control, X-cisco-serviceuri,replaces
Content-Disposition: session;handling=optional
Expires: 120


CUCM returns 401 unauthorised, because on req there is no digest user which is requirement for third party registration.

14 2019-12-06 16:57:58.250237 10.192.33.60 10.192.33.20 SIP 565 Status: 401 Unauthorized |

WWW-Authenticate: Digest realm="ccmsipline", nonce="ZGAB16SdpOqUsQBLL6LRT4bil6nOphnE", algorithm=MD5


and next register req has digest user for which we got 200 ok from CUCM :


17 2019-12-06 16:57:58.251863 10.192.33.20 10.192.33.60 SIP 610 Request: REGISTER sip:10.192.33.60;transport=TCP (1 binding) | (application/x-cisco-remotecc-request+xml) (application/x-cisco-remotecc-request+xml)

Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.192.33.60;transport=TCP SIP/2.0
Message Header
From: "MSCS Primary"<sip:2500100100@10.192.33.60>;tag=7a89d7c9-3bc95de7-6b62-8a346d8-1421c00a-13c4-759
To: "MSCS Primary"<sip:2500100100@10.192.33.60>
Call-ID: 4898a37a-16ef2d7b-6b62-67b4a00-1421c00a-13c4-759
[Generated Call-ID: 4898a37a-16ef2d7b-6b62-67b4a00-1421c00a-13c4-759]
CSeq: 2 REGISTER
Via: SIP/2.0/TCP 10.192.33.20:5060;branch=z9hG4bK-6235bcec-6b63-1a37ad9-888ea00
User-Agent: IPT-1011-R9.4_0.50675
Max-Forwards: 70
Supported: extended-refer, X-cisco-escapecodes, X-cisco-callinfo, X-cisco-service-control, X-cisco-serviceuri,replaces
Content-Disposition: session;handling=optional
Expires: 120
Authorization: Digest username="MSCS_PRIM_Turret",realm="ccmsipline",nonce="ZGAB16SdpOqUsQBLL6LRT4bil6nOphnE",uri="sip:10.192.33.60",response="51af35e9375dc40c0bb0e2e90c876327",algorithm=MD5



20 2019-12-06 16:57:58.262757 10.192.33.60 10.192.33.20 SIP 1111 Status: 200 OK (1 binding) |


issue start at keepalive request for whch there is no response :

66 2019-12-06 16:59:53.266456 10.192.33.20 10.192.33.60 SIP 849 Request: REGISTER sip:10.192.33.60;transport=TCP (1 binding) |

CSeq: 3 REGISTER
Expires: 120

and phone reset :

80 2019-12-06 17:00:12.168552 10.192.33.20 10.192.33.60 TCP 60 49181 → 5060 [RST, ACK] Seq=7765 Ack=4192 Win=0 Len=0



++ We need to check if Reg req reaching 10.192.33.60 or not, if yes what CUCM is doing with the request.

let me know if you still have the doubts from pcaps i can try to answer them.

Regards
Tarun

[conor.maton]

Hi,

Thanks for your reply.

I should've provided a bit more context of the testing I performed and therefore the start and end of the Wireshark trace. The process is as follows:

• Log into the SIP Phone
• Phone logs in successfully and registers to 10.192.33.60

This I think is represented between 1-20 in the Wireshark trace

• I disconnect 10.192.33.60

This I think is represented between 66-80 in the Wireshark trace

• Phone re-registers to 10.192.41.60

This I think is represented between 81-91 in the Wireshark trace

• I bring 10.192.33.60 back online

This I think happens at about the time of 120 in the Wireshark trace

• Phone attepts to re-register to 10.192.33.60 and fails. Phone also cannot register to any other CUCM subscriber in the cluster

This I think is represented between 121-185 in the Wireshark trace

The SIP digest credentials is correct as the SIP phone wouldn't successfully register in the first place. Is there anything from 121-185 that is suggesting there is something not correct as per the original registration?

[tgaur]

Hi,

144 2019-12-06 17:02:07.178482 10.192.33.20 10.192.33.60 SIP 761 Request: REFER sip:2500100100@10.192.33.60 |

the refer above has token=registration, so it is telling Primary call manager that he is going to failover but in response phone gets:

148 2019-12-06 17:02:07.179912 10.192.33.60 10.192.33.20 SIP 551 Status: 406 Not Acceptable |

Warning: 399 mscs-serv-01-cucm-sub "Device name missing"


Session Initiation Protocol (REFER)
Request-Line: REFER sip:2500100100@10.192.33.60 SIP/2.0
Message Header
From: <sip:2500100100@10.192.33.60>;tag=39e31468-273a9f9a-6c5b-8a3a6d8-1421c00a-13c4-759
SIP from address: sip:2500100100@10.192.33.60
SIP from tag: 39e31468-273a9f9a-6c5b-8a3a6d8-1421c00a-13c4-759
To: <sip:2500100100@10.192.33.60>
SIP to address: sip:2500100100@10.192.33.60
Call-ID: 22606d85-40118e2a-6c5b-8b4f6d0-1421c00a-13c4-759
[Generated Call-ID: 22606d85-40118e2a-6c5b-8b4f6d0-1421c00a-13c4-759]
CSeq: 1 REFER
Via: SIP/2.0/TCP 10.192.33.20:5060;branch=z9hG4bK-5d79471b-6c5b-1a74734-8893c58
Expires: 30
User-Agent: IPT-1011-R9.4_0.50675
Max-Forwards: 70
Supported: extended-refer, X-cisco-escapecodes, X-cisco-callinfo, X-cisco-service-control, X-cisco-serviceuri,replaces
Refer-To: <urn:X-cisco-remotecc:token-registration>
Referred-By: <sip:2500100100@10.192.33.60>
Contact: <sip:ff0070a7-09e0-6d7b-752c-37585ba4f051@10.192.33.20;transport=TCP>
Contact URI: sip:ff0070a7-09e0-6d7b-752c-37585ba4f051@10.192.33.20;transport=TCP
Contact URI User Part: ff0070a7-09e0-6d7b-752c-37585ba4f051
Contact URI Host Part: 10.192.33.20
Contact URI parameter: transport=TCP
Content-Length: 0


there is no "+u.sip!devicename.ccm.cisco.com" or "+sip.instance" that tell the device mac in the request.

PS : The REFER must have a Contact header and a device name. If not, we will not be able to release the token when the device registers.


Regards
Tarun

[conor.maton]

Hi,

Thanks for your reply. 

OK so something isn't quite right. What do I need to check on CUCM to try and rectify this? 

[tgaur]

Hi,

CUCM working as design, so you need to isolate this is the issue for the failover only reported by third party phones, any Cisco phone having this issue etc. i will strongly recommend to get in touch with third party phone support also open a Cisco TAC case.

Regards
Tarun