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

Cisco IP Phone 8851 with Multiplatform Firmware version 11.2.1 not RFC compliant when sending in-dialog SUBSCRIBE

Hello,

 

I've noticed that firmware 11.2.1 (I haven't tested for older versions) violates SIP specifications in an embarrassing way when sending a re-SUBSCRIBE within an existing dialog. More specifically, the phone (a 8851 in this case) doesn't use the previously received URI from the Contact header. Instead, it re-uses the R-URI from the initial SUBSCRIBE.

 

Please find below the cadence of SIP messages demonstrating the problem:

 

SUBSCRIBE sip:402@my-sip-proxy.net SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5064;branch=z9hG4bK-e33ba6a1
From: "johntest-405" <sip:johntest-405@my-sip-proxy.net>;tag=c7976ef9660b6c8c
To: <sip:402@my-sip-proxy.net>
Call-ID: 14d1519-a9d4fd4d@172.17.173.14
CSeq: 60735 SUBSCRIBE
Max-Forwards: 70
Proxy-Authorization: Digest username="johntest-405",realm="my-sip-proxy.net",nonce="W+21WFvttCwi3gqyVA9svGyun5Faqj6X",uri="sip:402@modcom-
c",algorithm=MD5,response="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
Contact: "johntest-405" <sip:johntest-405@2.2.2.2:5064>
Accept: application/dialog-info+xml
Expires: 120
Event: dialog
User-Agent: Cisco-CP-8851-3PCC/11.2.1
Content-Length: 0

SIP/2.0 200 OK
From:  <sip:johntest-405@my-sip-proxy.net>;tag=c7976ef9660b6c8c
To: <sip:402@my-sip-proxy.net>;tag=as74e10ebb
Call-ID: 14d1519-a9d4fd4d@172.17.173.14
CSeq: 60735 SUBSCRIBE
Server: modCOM v2 SIP Server
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 120
Content-Length: 0
Via: SIP/2.0/UDP 2.2.2.2:5064;rport=5064;branch=z9hG4bK-e33ba6a1
Contact: <sip:atpsh-5bed8859-3719-2@3.3.3.3>

The URI from the response's Contact: header should be used for all subsequent

in-dialog requests from the phone. Instead: SUBSCRIBE sip:402@my-sip-proxy.net SIP/2.0 Via: SIP/2.0/UDP 2.2.2.2:5064;branch=z9hG4bK-81b84571 From: "johntest-405" <sip:johntest-405@my-sip-proxy.net>;tag=c7976ef9660b6c8c To: <sip:402@my-sip-proxy.net>;tag=as74e10ebb Call-ID: 14d1519-a9d4fd4d@172.17.173.14 CSeq: 60736 SUBSCRIBE Max-Forwards: 70 Proxy-Authorization: Digest username="johntest-405",realm="my-sip-proxy.net",nonce="W+21WFvttCwi3gqyVA9svGyun5Faqj6X",uri="sip:402@modcom- c",algorithm=MD5,response="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" Contact: "johntest-405" <sip:johntest-405@2.2.2.2:5064> Accept: application/dialog-info+xml Expires: 120 Event: dialog User-Agent: Cisco-CP-8851-3PCC/11.2.1 Content-Length: 0

 


Public IPs, hostnames and challenge responses have been edited for privacy/seccurity reasons.

 

BR,

George

Everyone's tags (6)
4 REPLIES 4
Highlighted
Beginner

Re: Cisco IP Phone 8851 with Multiplatform Firmware version 11.2.1 not RFC compliant when sending in-dialog SUBSCRIBE

Can someone from Cisco confirm if/when this will be registered as a bug report for 3PCC firmware on the 8800-Series of IP Phones?

 

Thanks.

Re: Cisco IP Phone 8851 with Multiplatform Firmware version 11.2.1 not RFC compliant when sending in-dialog SUBSCRIBE

Just to manage expectations: Cisco employees are not obligated to contribute to the forums. Those who do are volunteering their time/energy. Feel free to hold out a few more days but if you want a formal response within SLAs, or any hope of getting a defect created, you need to open a TAC case.
Beginner

Re: Cisco IP Phone 8851 with Multiplatform Firmware version 11.2.1 not RFC compliant when sending in-dialog SUBSCRIBE

I have no expectations for a fix. However, it's a little frustrating that there's no formal procedure to report serious bugs, such as this one involving RFC violations, when one does not have an active TAC subscription. Personally, I would be satisfied if a bug report were created which I then would be able to watch for updates.

Cisco Employee

Re: Cisco IP Phone 8851 with Multiplatform Firmware version 11.2.1 not RFC compliant when sending in-dialog SUBSCRIBE

Hello.
Where were these packets captured?

Please attach a PRT or a Packet capture taken from the phone web page (http://[Phone IP]/admin/advanced).

 

Info->Debug Info->Start Packet Capture (Start after phone bootup and stop after the issue is seen)

Info->Debug Info->Generate PRT (Generate after issue is seen. Set Debug level to DEBUG[Voice->System->Debug Level])

 

Thanks.

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards