Subject: Re: [SIP] Killing hung media streams

From: Michael Thomas <[email-masked]>
Date: Sat, 9 Jun 2001 12:08:57 -0700 (PDT)

Richard Watson writes:
 > This problem (disappearing media streams), is an real issue with implementation of a wireless SIP deployment.  There needs to be some intrinsic protocol mechanism for bi-directional determination of active states of the call participants.
 > 
 > Suggestions on addressing this issue?

   Just like TCP, there can be no algorithmic way to determine the
   difference between a transient network partition, the other
   side croaking, congestion, or VAD. That isn't to say that you
   can't do an adequate job of determining that you're hosed with
   RTCP, it's just that every once in a while an innocent stream
   is going to be sentenced to death. C'est la guerre.

	    Mike

 > 
 > 
 > Richard Watson
 > Director of Telephony Product Marketing
 > Wireless LAN Division
 > Symbol Technologies, Inc.
 > 6480 Via Del Oro
 > San Jose, CA 95119-1208
 > (408) 528-2820
 > 
 > >>> Michael Thomas <[email-masked]> 06/09/01 06:49AM >>>
 > 
 > 
 > 
 > [email-masked] writes:
 > > 
 > >  I have looked through the archives and could not find anything on this
 > > topic, please excuse me if it has been discussed.  We have encountered a
 > > couple of different UAs that are a MGC controlling MGs, and if the UA
 > > crashes and comes back up, a media stream from the MG continues.  By the
 > > time it comes back up, the UA on the other end has done all it's retransmits
 > > trying to tear down the session, and has flushed the call.
 > > 
 > >  This hung media stream causes problems and consumes resources.  Obviously
 > > some work needs to be done on the MGC - MG implementation to avoid this
 > > problem and clean up after a crash.  However, has there been any discussion
 > > regarding what the receiver of this media might do to inform the UA on the
 > > other end to shut it down (once that UA has come back up)?  I suppose the
 > > receiving UA would need to maintain a history of previous sessions to tie a
 > > media stream back to a UA.  Thoughts?
 > 
 >    It ought to send an ICMP port unavailable. Also: it would
 >    probably be a good overall thing to use RTCP for liveliness
 >    heuristics since it's possible that the partition affected
 >    the MGC as well, in which case you might not be able to
 >    get the tear down command even with a well implemented MGC.
 > 
 >        Mike
 > 
 > 
 > 
 > _______________________________________________
 > This list is for continuing development of the SIP protocol.
 > The sip-implementor's list is the place to discuss implementation,
 > and to receive advice on understanding existing sip.
 > To subscribe to it, send mail to 
 > [email-masked] with "subscribe" in the body.
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 > <HTML><HEAD>
 > <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
 > <META content="MSHTML 5.00.2614.3500" name=GENERATOR></HEAD>
 > <BODY style="FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
 > <DIV><FONT size=1>This problem (disappearing media streams), is an real issue 
 > with implementation of a wireless SIP deployment.&nbsp; There needs to be some 
 > intrinsic protocol mechanism for bi-directional determination of 
 > active&nbsp;states of the call participants.</FONT></DIV>
 > <DIV>&nbsp;</DIV>
 > <DIV><FONT size=1>Suggestions on addressing this issue?</FONT></DIV>
 > <DIV>&nbsp;</DIV>
 > <DIV>&nbsp;</DIV>
 > <DIV>&nbsp;</DIV>
 > <DIV>Richard Watson<BR>Director of Telephony Product Marketing<BR>Wireless LAN 
 > Division<BR>Symbol Technologies, Inc.<BR>6480 Via Del Oro<BR>San Jose, CA 
 > 95119-1208<BR>(408) 528-2820<BR><BR>&gt;&gt;&gt; Michael Thomas 
 > &lt;[email-masked]&gt; 06/09/01 06:49AM 
 > &gt;&gt;&gt;<BR><BR><BR><BR>[email-masked] writes:<BR>&gt; 
 > <BR>&gt;&nbsp; I have looked through the archives and could not find anything on 
 > this<BR>&gt; topic, please excuse me if it has been discussed.&nbsp; We have 
 > encountered a<BR>&gt; couple of different UAs that are a MGC controlling MGs, 
 > and if the UA<BR>&gt; crashes and comes back up, a media stream from the MG 
 > continues.&nbsp; By the<BR>&gt; time it comes back up, the UA on the other end 
 > has done all it's retransmits<BR>&gt; trying to tear down the session, and has 
 > flushed the call.<BR>&gt; <BR>&gt;&nbsp; This hung media stream causes problems 
 > and consumes resources.&nbsp; Obviously<BR>&gt; some work needs to be done on 
 > the MGC - MG implementation to avoid this<BR>&gt; problem and clean up after a 
 > crash.&nbsp; However, has there been any discussion<BR>&gt; regarding what the 
 > receiver of this media might do to inform the UA on the<BR>&gt; other end to 
 > shut it down (once that UA has come back up)?&nbsp; I suppose the<BR>&gt; 
 > receiving UA would need to maintain a history of previous sessions to tie 
 > a<BR>&gt; media stream back to a UA.&nbsp; Thoughts?<BR><BR>&nbsp;&nbsp; It 
 > ought to send an ICMP port unavailable. Also: it would<BR>&nbsp;&nbsp; probably 
 > be a good overall thing to use RTCP for liveliness<BR>&nbsp;&nbsp; heuristics 
 > since it's possible that the partition affected<BR>&nbsp;&nbsp; the MGC as well, 
 > in which case you might not be able to<BR>&nbsp;&nbsp; get the tear down command 
 > even with a well implemented MGC.<BR><BR>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; 
 > Mike<BR><BR><BR><BR>_______________________________________________<BR>This list 
 > is for continuing development of the SIP protocol.<BR>The sip-implementor's list 
 > is the place to discuss implementation,<BR>and to receive advice on 
 > understanding existing sip.<BR>To subscribe to it, send mail to 
 > <BR>[email-masked] with "subscribe" in the 
 > body.<BR></DIV></BODY></HTML>

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 9 Jun 2001 14:25:47 -0500

I believe that if one were to use RTCP at 5-second granularity for media
liveness determination of a voice session, one might safely assume at 3
misses that either the far end has dropped or that the network in between
has gone byby and hang up the call.  Do you really want call a with
15-seconf hoels in it to stay "up"? We're not talking
voice-activiity-detection here, either . . .

As Michael  points out, media streaming to a UA that has rebooted is likely
to result in an ICMP port unreachable message UNLESS that UA has recycled
the port. If the port has been recycled, we hopefully get an SSRC mismatch
(what happens then? This seems like a likely case.) In the very unlikely
case of a birthday paradox on SSRC at the same port, one could have an
interesting condition develop (maybe very likely with bad implementations of
SSRC and weak port randomization) with two senders and no way to identify or
tear down the "ghost" leg.
.
I also suspect that John's original post begs the question of "something
like session timer" for MGCP. That is, he's asking the legitmate MGCP
question of "what happens if the MGC loses synch with the MG". Great
question. Wrong working group.

--
Dean

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Richard Watson" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, June 09, 2001 2:08 PM
Subject: Re: [SIP] Killing hung media streams

> Richard Watson writes:
>  > This problem (disappearing media streams), is an real issue with
implementation of a wireless SIP deployment.  There needs to be some
intrinsic protocol mechanism for bi-directional determination of active
states of the call participants.
>  > Symbol Technologies, Inc.
Mike<BR><BR><BR><BR>_______________________________________________<BR>This
list