Subject: RE: [SIP] Killing hung media streams

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 00:40:54 -0400

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Saturday, June 09, 2001 9:49 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [SIP] Killing hung media streams
> 
> 
> 
> 
> 
> [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.

I agree with the others that have suggested ICMP port unreachables. A few
additional comments to that.

First, for those of you for whom 5 second RTCP intervals is too long (since
that would require perhaps 15 seconds to detect a failure through timeout),
there is a draft on an SDP extension for indicating the RTCP bandwidth
allocation:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-bw-03.txt

which can allow you to up the frequency.

A more interesting question is this: what is the right behavior for a UA
that starts to get ICMP port unreachable errors on the RTP stream? I have
encountered two very different scenarios for this. In one case, the right
behavior is to consider the call terminated. Another, more interesting case,
is to immediately send a re-INVITE in order to re-establish the call at a
backup of the remote peer. This turns out to be very useful for high
availability conferencing and media systems. Thus, there may be a need for
some kind of flag somewhere to indicate which behavior a UA desires when its
peer starts to receive ICMP errors from it. I'm working on an I-D on this
topic. Stay tuned...

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jun 2001 09:05:58 -0400

Jonathan Rosenberg wrote:
> peer starts to receive ICMP errors from it.

The relevant cases certainly extend beyond this specific error.
For one, this particular error is only relevant for media over RTP.

There is need for a way to do a reinvite that says in effect:
I'm ok but you are not - please offer me some alternate resources to
use.

The errors that would lead to this are probably all media specific.
In the case of calls involving multiple media, expressing the problem
clearly gets into the area of overlap between SIP and SDP - which media
stream is having difficulty.

> I'm working on an I-D on this topic. Stay tuned...

ok.

	Paul Kyzivat
	Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Mon, 11 Jun 2001 07:36:09 -0700 (PDT)

> peer starts to receive ICMP errors from it. I'm working on an I-D on this

   This sounds quite sensible, but I don't understand why there
   needs to be signaling involved. Isn't this just a local decision?
   Why would those preferences need to be signaled?

	     Mike