[SFtrack] Commented: (XECS-1589) SipXecs does not gracefully handle broken TCP streams
[
http://track.sipfoundry.org/browse/XECS-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_30243
]
Brad Marusiak commented on XECS-1589:
-------------------------------------
I see what your talking about and it may be possible that, as you mentioned,
the phone may be intentionally disregarding the NOTIFY.
If you could get me some logs from the phone with the sip log level set to 1 I
could verify that.
log.level.change.sip="1"
> SipXecs does not gracefully handle broken TCP streams
> -----------------------------------------------------
>
> Key: XECS-1589
> URL: http://track.sipfoundry.org/browse/XECS-1589
> Project: sipXecs
> Issue Type: Improvement
> Environment: sipXecs 3.10
> Reporter: Brad Marusiak
> Assignee: Dale R. Worley
> Attachments: polycomRepro.pcap, reboot1.pcap, reboot2.pcap,
> sipx-snapshot.zip
>
>
> Restating Brad's analysis to clarify where sipX needs improvement:
> First, the Polycom phone on rebooting is not properly tearing down its TCP
> connection. On a restart we attempt to unSUBSCRIBE from the BLF dialog
> (packet 93) but the TCP stream is never concluded with a FIN tagged packet.
> Ideally the phone should terminate the TCP stream to ensure that the other
> SIP element does not attempt to use the stream afterward, but that cannot be
> enforced, as the phone may restart due to a power failure.
> Second, on restart after the phone re-registers and resubscribes, the sipX
> server (RLS) is sending the CSEQ 0 NOTIFY (packet 718) in answer to the new
> SUBSCRIBE (#716). sipX does not initiate a new TCP stream because it believes
> that the old TCP stream is still working.
> The TCP packet's contents will not be successfully received, since the phone
> does not know of the TCP stream. The phone returns an RST packet to sipX.
> The sipX SIP stack returns a transmission failure to the RLS "Subscribe
> Server" which terminates the subscription but the SIP stack does not attempt
> to re-send the NOTIFY in any way.
> After 30 minutes have elapsed, the phone will initiate its resubscribe. As
> the RLS has destroyed the subscription, the phone will receive a 481
> response, in which case it should attempt a new subscription. Alternatively,
> the phone may attempt a new subscription outright. In either case, the phone
> establishes a new subscription.
> Note that in SIP the NOTIFYs of a SUBSCRIBE are NOT required to be returned
> by any particular transport or stream, other than as specified by the Contact
> URL of the SUBSCRIBE.
> Technically, that sipX does not gracefully handle broken TCP connections is
> probably not out-of-specification, but as seen above, it can cause
> operational problems. We should have a better strategy to handle broken TCP
> connections.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://track.sipfoundry.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
