Subject: RE: [SIP] Killing hung media streams

From: Igor Slepchin <[email-masked]>
Date: Fri, 8 Jun 2001 12:03:03 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>
> 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)? 

Send back ICMP errors for what it considers to be stray RTP/RTCP packets?
The sending MG can interpret that as a sign that nobody is prepared to
receive the media and terminate the stream.

Thank you,
Igor Slepchin

_______________________________________________
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: "Richard Watson" <[email-masked]>
Date: Sat, 09 Jun 2001 09:13:23 -0700

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?

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 18 Jun 2001 03:50:12 -0700

Hi Jonathan,

Do we really need to negotiate another signaling parameter ?

Would not sending a re-INVITE eventually have the same effect as sending a
BYE (ie, causes no harm in any case and hopefully better in some)? If the
third party call controller receives a re-invite, it may or may not bother
to send its own re-INVITE to the other endpoint, right? However the third
party controller and remaining endpoint's call state will remain in-sync. If
media transport is not reestablished then the caller will eventually hangup
and the session will be BYE'd properly; otherwise the proxy/3pc/remote-UA
will take some action to restore media transport and the session can
continue. Am I missing something in your 3pc example ?
In any case, I would have thought that you should never just tear down an
established SIP session without attempting to send a BYE simply because
there are problems in a media stream. Is this not a violation of SIP ?

Rather than signaling what is the preferred action perhaps it would be
better that the re-INVITE indicated the actual error condition (ie, ICMP
errors were encountered on the media streams)? A re-INVITE with a Warning
header seems the most appropriate and transparent approach to me. Now the
3pc or proxy really knows what is going on and can make an proper, informed
decision rather than trying to "control" the UA into taking the action on
its behalf.

Regards.

Robert.

-----Original Message-----
From:	Jonathan Rosenberg [mailto:[email-masked]]
Sent:	Saturday, June 16, 2001 7:46 AM
To:	'Michael Thomas'; Jonathan Rosenberg
Cc:	[email-masked]; [email-masked]'
Subject:	RE: [SIP] Killing hung media streams

Here is a third thing one might do upon an ICMP error - send a BYE. I can
construct cases where you really, REALLY want this. Specifically, third
party call control. Consider the case of a controller in a call with A and
B. A dies. A stops sending media. B detects this. B considers its call
terminated, but sends no messages. Now, A and B have destroyed call state,
but the controller is left hanging. The controller would prefer to get a BYE
in these cases. 

So, we have three things one might do upon detecting a failed media stream:

1. re-INVITE
2. send BYE
3. do nothing and consider the call down

My argument is that the right thing depends on the entity at the other end
of the call. To me, this means some kind of signaling is desirable to
communicate which mode is preferred. Of course, it can be refused or not
obeyed, but in the cooperating or non-conflicting cases, I'd like to be able
to do the right thing.

-Jonathan R.