Subject: Re: [SIP] Killing hung media streams

From: "Richard Watson" <[email-masked]>
Date: Sat, 09 Jun 2001 15:27:31 -0700

Thanks for the input.  One of the behaviors that Symbol has found that is broadly accepted by our wireless H.323 implementations is the ability to be in a call; step out-of-coverage; be notified by audio "beep"; and back into coverage within 15 seconds to sustain the call.  This "robustness" of call management has been a real plus with our NetVision H.323 implementation.  Any longer than a 15 second window, the call needs to be torn down on both sides in an automated fashion.

let's keep the discussion goin....

richWatson/Symbol

>>> "Dean Willis" <[email-masked]> 06/09/01 12:25PM >>>

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.
>  >
>  > 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.
>

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Sat, 09 Jun 2001 21:16:11 -0500

>let's keep the discussion goin....
wrong group, not here.
Henry
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Richard Watson
  Sent: Saturday, June 09, 2001 5:28 PM
  To: [email-masked]
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: Re: [SIP] Killing hung media streams

  Thanks for the input.  One of the behaviors that Symbol has found that is
broadly accepted by our wireless H.323 implementations is the ability to be
in a call; step out-of-coverage; be notified by audio "beep"; and back into
coverage within 15 seconds to sustain the call.  This "robustness" of call
management has been a real plus with our NetVision H.323 implementation.
Any longer than a 15 second window, the call needs to be torn down on both
sides in an automated fashion.

  richWatson/Symbol

  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

  this
  encountered a
  the
  retransmits
  Obviously
  this
  discussion
  on the
  the
  tie a
  2px">
  issue
  be some
  CA
  anything on
  have
  controlling MGs,
  the MG
  other end
  and has
  problems
  done on
  after a
  what the
  end to
  the<BR>&gt;
  tie
  probably
  heuristics
  as well,
  down command
  &nbsp;&nbsp;

  sip-implementor's list

---

From: Michael Thomas <[email-masked]>
Date: Sun, 10 Jun 2001 07:25:21 -0700 (PDT)

> let's keep the discussion goin....

  In this case, the RTCP check (assuming that the other side
  isn't a broken implementation and doesn't send RTCP) is
  probably adequate for reaping long term failures. Note 
  that people are generally a lot less patient, so this is
  usually only a problem when a person isn't attending to
  the call. 

  As for Dean's port-reuse scenario, sounds like a good
  reason to use keyed hashes on the media ala SRTP :-)

	    Mike

 > <BODY style="FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
 > <DIV><FONT size=1>Thanks for the input.&nbsp; One of the behaviors that Symbol 
 > has found that is broadly accepted by our wireless H.323 implementations is the 
 > ability to be in a call; step out-of-coverage; be notified by audio "beep"; and 
 > back into coverage within 15 seconds to sustain the call.&nbsp; This 
 > "robustness" of call management has been a real plus with our NetVision H.323 
 > implementation.&nbsp; Any longer than a 15 second window, the call needs to be 
 > torn down on both sides in an automated fashion.</FONT></DIV>
 > <DIV>&nbsp;</DIV>
 > <DIV><FONT size=1>let's keep the discussion goin....</FONT></DIV>
 > <DIV>&nbsp;</DIV>
 > <DIV><FONT size=1>richWatson/Symbol</FONT><BR><BR>&gt;&gt;&gt; "Dean Willis" 
 > &lt;[email-masked]&gt; 06/09/01 12:25PM &gt;&gt;&gt;<BR><BR>I believe 
 > that if one were to use RTCP at 5-second granularity for media<BR>liveness 
 > determination of a voice session, one might safely assume at 3<BR>misses that 
 > either the far end has dropped or that the network in between<BR>has gone byby 
 > and hang up the call.&nbsp; Do you really want call a with<BR>15-seconf hoels in 
 > it to stay "up"? We're not talking<BR>voice-activiity-detection here, either . . 
 > .<BR><BR>As Michael&nbsp; points out, media streaming to a UA that has rebooted 
 > is likely<BR>to result in an ICMP port unreachable message UNLESS that UA has 
 > recycled<BR>the port. If the port has been recycled, we hopefully get an SSRC 
 > mismatch<BR>(what happens then? This seems like a likely case.) In the very 
 > unlikely<BR>case of a birthday paradox on SSRC at the same port, one could have 
 > an<BR>interesting condition develop (maybe very likely with bad implementations 
 > of<BR>SSRC and weak port randomization) with two senders and no way to identify 
 > or<BR>tear down the "ghost" leg.<BR>.<BR>I also suspect that John's original 
 > post begs the question of "something<BR>like session timer" for MGCP. That is, 
 > he's asking the legitmate MGCP<BR>question of "what happens if the MGC loses 
 > synch with the MG". Great<BR>question. Wrong working 
 > group.<BR><BR>--<BR>Dean<BR><BR><BR><BR>----- Original Message -----<BR>From: 
 > "Michael Thomas" &lt;[email-masked]&gt;<BR>To: "Richard Watson" 
 > &lt;[email-masked]&gt;<BR>Cc: &lt;[email-masked]&gt;; 
 > &lt;[email-masked]&gt;; &lt;[email-masked]&gt;<BR>Sent: 
 > Saturday, June 09, 2001 2:08 PM<BR>Subject: Re: [SIP] Killing hung media 
 > streams<BR><BR><BR>&gt; Richard Watson writes:<BR>&gt;&nbsp; &gt; This problem 
 > (disappearing media streams), is an real issue with<BR>implementation of a 
 > wireless SIP deployment.&nbsp; There needs to be some<BR>intrinsic protocol 
 > mechanism for bi-directional determination of active<BR>states of the call 
 > participants.<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt; Suggestions on addressing 
 > this issue?<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; Just like TCP, there can be no 
 > algorithmic way to determine the<BR>&gt;&nbsp;&nbsp;&nbsp; difference between a 
 > transient network partition, the other<BR>&gt;&nbsp;&nbsp;&nbsp; side croaking, 
 > congestion, or VAD. That isn't to say that you<BR>&gt;&nbsp;&nbsp;&nbsp; can't 
 > do an adequate job of determining that you're hosed 
 > with<BR>&gt;&nbsp;&nbsp;&nbsp; RTCP, it's just that every once in a while an 
 > innocent stream<BR>&gt;&nbsp;&nbsp;&nbsp; is going to be sentenced to death. 
 > C'est la guerre.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
 > Mike<BR>&gt;<BR>&gt;<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt; 
 > Richard Watson<BR>&gt;&nbsp; &gt; Director of Telephony Product 
 > Marketing<BR>&gt;&nbsp; &gt; Wireless LAN Division<BR>&gt;&nbsp; &gt; Symbol 
 > Technologies, Inc.<BR>&gt;&nbsp; &gt; 6480 Via Del Oro<BR>&gt;&nbsp; &gt; San 
 > Jose, CA 95119-1208<BR>&gt;&nbsp; &gt; (408) 528-2820<BR>&gt;&nbsp; 
 > &gt;<BR>&gt;&nbsp; &gt; &gt;&gt;&gt; Michael Thomas &lt;[email-masked]&gt; 
 > 06/09/01 06:49AM &gt;&gt;&gt;<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; 
 > &gt;<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt; [email-masked] 
 > writes:<BR>&gt;&nbsp; &gt; &gt;<BR>&gt;&nbsp; &gt; &gt;&nbsp; I have looked 
 > through the archives and could not find anything on<BR>this<BR>&gt;&nbsp; &gt; 
 > &gt; topic, please excuse me if it has been discussed.&nbsp; We 
 > have<BR>encountered a<BR>&gt;&nbsp; &gt; &gt; couple of different UAs that are a 
 > MGC controlling MGs, and if the UA<BR>&gt;&nbsp; &gt; &gt; crashes and comes 
 > back up, a media stream from the MG continues.&nbsp; By<BR>the<BR>&gt;&nbsp; 
 > &gt; &gt; time it comes back up, the UA on the other end has done all 
 > it's<BR>retransmits<BR>&gt;&nbsp; &gt; &gt; trying to tear down the session, and 
 > has flushed the call.<BR>&gt;&nbsp; &gt; &gt;<BR>&gt;&nbsp; &gt; &gt;&nbsp; This 
 > hung media stream causes problems and consumes 
 > resources.<BR>Obviously<BR>&gt;&nbsp; &gt; &gt; some work needs to be done on 
 > the MGC - MG implementation to avoid<BR>this<BR>&gt;&nbsp; &gt; &gt; problem and 
 > clean up after a crash.&nbsp; However, has there been 
 > any<BR>discussion<BR>&gt;&nbsp; &gt; &gt; regarding what the receiver of this 
 > media might do to inform the UA<BR>on the<BR>&gt;&nbsp; &gt; &gt; other end to 
 > shut it down (once that UA has come back up)?&nbsp; I 
 > suppose<BR>the<BR>&gt;&nbsp; &gt; &gt; receiving UA would need to maintain a 
 > history of previous sessions to<BR>tie a<BR>&gt;&nbsp; &gt; &gt; media stream 
 > back to a UA.&nbsp; Thoughts?<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; 
 > &gt;&nbsp;&nbsp;&nbsp; It ought to send an ICMP port unavailable. Also: it 
 > would<BR>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; probably be a good overall thing to 
 > use RTCP for liveliness<BR>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; heuristics since 
 > it's possible that the partition affected<BR>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; 
 > the MGC as well, in which case you might not be able to<BR>&gt;&nbsp; 
 > &gt;&nbsp;&nbsp;&nbsp; get the tear down command even with a well implemented 
 > MGC.<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; 
 > &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike<BR>&gt;&nbsp; 
 > &gt;<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt; 
 > _______________________________________________<BR>&gt;&nbsp; &gt; This list is 
 > for continuing development of the SIP protocol.<BR>&gt;&nbsp; &gt; The 
 > sip-implementor's list is the place to discuss implementation,<BR>&gt;&nbsp; 
 > &gt; and to receive advice on understanding existing sip.<BR>&gt;&nbsp; &gt; To 
 > subscribe to it, send mail to<BR>&gt;&nbsp; &gt; 
 > [email-masked] with "subscribe" in the 
 > body.<BR>&gt;&nbsp; &gt; &lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 
 > Transitional//EN"&gt;<BR>&gt;&nbsp; &gt; &lt;HTML&gt;&lt;HEAD&gt;<BR>&gt;&nbsp; 
 > &gt; &lt;META content="text/html; charset=iso-8859-1" 
 > http-equiv=Content-Type&gt;<BR>&gt;&nbsp; &gt; &lt;META content="MSHTML 
 > 5.00.2614.3500" name=GENERATOR&gt;&lt;/HEAD&gt;<BR>&gt;&nbsp; &gt; &lt;BODY 
 > style="FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; 
 > MARGIN-TOP:<BR>2px"&gt;<BR>&gt;&nbsp; &gt; &lt;DIV&gt;&lt;FONT size=1&gt;This 
 > problem (disappearing media streams), is an real<BR>issue<BR>&gt;&nbsp; &gt; 
 > with implementation of a wireless SIP deployment.&amp;nbsp; There needs to<BR>be 
 > some<BR>&gt;&nbsp; &gt; intrinsic protocol mechanism for bi-directional 
 > determination of<BR>&gt;&nbsp; &gt; active&amp;nbsp;states of the call 
 > participants.&lt;/FONT&gt;&lt;/DIV&gt;<BR>&gt;&nbsp; &gt; 
 > &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;<BR>&gt;&nbsp; &gt; &lt;DIV&gt;&lt;FONT 
 > size=1&gt;Suggestions on addressing this 
 > issue?&lt;/FONT&gt;&lt;/DIV&gt;<BR>&gt;&nbsp; &gt; 
 > &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;<BR>&gt;&nbsp; &gt; 
 > &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;<BR>&gt;&nbsp; &gt; 
 > &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;<BR>&gt;&nbsp; &gt; &lt;DIV&gt;Richard 
 > Watson&lt;BR&gt;Director of Telephony Product<BR>Marketing&lt;BR&gt;Wireless 
 > LAN<BR>&gt;&nbsp; &gt; Division&lt;BR&gt;Symbol Technologies, Inc.&lt;BR&gt;6480 
 > Via Del Oro&lt;BR&gt;San Jose,<BR>CA<BR>&gt;&nbsp; &gt; 
 > 95119-1208&lt;BR&gt;(408) 528-2820&lt;BR&gt;&lt;BR&gt;&amp;gt;&amp;gt;&amp;gt; 
 > Michael Thomas<BR>&gt;&nbsp; &gt; &amp;lt;[email-masked]&amp;gt; 06/09/01 
 > 06:49AM<BR>&gt;&nbsp; &gt; 
 > &amp;gt;&amp;gt;&amp;gt;&lt;BR&gt;&lt;BR&gt;&lt;BR&gt;&lt;BR&gt;[email-masked] 
 > writes:&lt;BR&gt;&amp;gt;<BR>&gt;&nbsp; &gt; &lt;BR&gt;&amp;gt;&amp;nbsp; I have 
 > looked through the archives and could not find<BR>anything on<BR>&gt;&nbsp; &gt; 
 > this&lt;BR&gt;&amp;gt; topic, please excuse me if it has been 
 > discussed.&amp;nbsp; We<BR>have<BR>&gt;&nbsp; &gt; encountered 
 > a&lt;BR&gt;&amp;gt; couple of different UAs that are a MGC<BR>controlling 
 > MGs,<BR>&gt;&nbsp; &gt; and if the UA&lt;BR&gt;&amp;gt; crashes and comes back 
 > up, a media stream from<BR>the MG<BR>&gt;&nbsp; &gt; continues.&amp;nbsp; By 
 > the&lt;BR&gt;&amp;gt; time it comes back up, the UA on the<BR>other 
 > end<BR>&gt;&nbsp; &gt; has done all it's retransmits&lt;BR&gt;&amp;gt; trying to 
 > tear down the session,<BR>and has<BR>&gt;&nbsp; &gt; flushed the 
 > call.&lt;BR&gt;&amp;gt; &lt;BR&gt;&amp;gt;&amp;nbsp; This hung media stream 
 > causes<BR>problems<BR>&gt;&nbsp; &gt; and consumes resources.&amp;nbsp; 
 > Obviously&lt;BR&gt;&amp;gt; some work needs to be<BR>done on<BR>&gt;&nbsp; &gt; 
 > the MGC - MG implementation to avoid this&lt;BR&gt;&amp;gt; problem and clean 
 > up<BR>after a<BR>&gt;&nbsp; &gt; crash.&amp;nbsp; However, has there been any 
 > discussion&lt;BR&gt;&amp;gt; regarding<BR>what the<BR>&gt;&nbsp; &gt; receiver 
 > of this media might do to inform the UA on the&lt;BR&gt;&amp;gt; other<BR>end 
 > to<BR>&gt;&nbsp; &gt; shut it down (once that UA has come back up)?&amp;nbsp; I 
 > suppose<BR>the&lt;BR&gt;&amp;gt;<BR>&gt;&nbsp; &gt; receiving UA would need to 
 > maintain a history of previous sessions to<BR>tie<BR>&gt;&nbsp; &gt; 
 > a&lt;BR&gt;&amp;gt; media stream back to a 
 > UA.&amp;nbsp;<BR>Thoughts?&lt;BR&gt;&lt;BR&gt;&amp;nbsp;&amp;nbsp; 
 > It<BR>&gt;&nbsp; &gt; ought to send an ICMP port unavailable. Also: it 
 > would&lt;BR&gt;&amp;nbsp;&amp;nbsp;<BR>probably<BR>&gt;&nbsp; &gt; be a good 
 > overall thing to use RTCP for 
 > liveliness&lt;BR&gt;&amp;nbsp;&amp;nbsp;<BR>heuristics<BR>&gt;&nbsp; &gt; since 
 > it's possible that the partition affected&lt;BR&gt;&amp;nbsp;&amp;nbsp; the 
 > MGC<BR>as well,<BR>&gt;&nbsp; &gt; in which case you might not be able 
 > to&lt;BR&gt;&amp;nbsp;&amp;nbsp; get the tear<BR>down command<BR>&gt;&nbsp; &gt; 
 > even with a well implemented 
 > MGC.&lt;BR&gt;&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;<BR>&amp;nbsp;&amp;nbsp;<BR>&gt;&nbsp; 
 > &gt;<BR>Mike&lt;BR&gt;&lt;BR&gt;&lt;BR&gt;&lt;BR&gt;_______________________________________________&lt;BR&gt;This<BR>list<BR>&gt;&nbsp; 
 > &gt; is for continuing development of the SIP 
 > protocol.&lt;BR&gt;The<BR>sip-implementor's list<BR>&gt;&nbsp; &gt; is the place 
 > to discuss implementation,&lt;BR&gt;and to receive advice on<BR>&gt;&nbsp; &gt; 
 > understanding existing sip.&lt;BR&gt;To subscribe to it, send mail 
 > to<BR>&gt;&nbsp; &gt; &lt;BR&gt;[email-masked] with 
 > "subscribe" in the<BR>&gt;&nbsp; &gt; 
 > body.&lt;BR&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;<BR>&gt;<BR>&gt; 
 > _______________________________________________<BR>&gt; This list is for 
 > continuing development of the SIP protocol.<BR>&gt; The sip-implementor's list 
 > is the place to discuss implementation,<BR>&gt; and to receive advice on 
 > understanding existing sip.<BR>&gt; To subscribe to it, send mail to<BR>&gt; 
 > [email-masked] with "subscribe" in the 
 > body.<BR>&gt;<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