Subject: RE: [SIP] Killing hung media streams

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2001 16:56:01 -0400

(moving the thread to the new list)

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 10:36 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; [email-masked]; [email-masked]
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> Jonathan Rosenberg writes:
>  > 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...
> 
>    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?

Lets say A and B are in a call, and B is a type of device that if it fails,
the call is over. When A detects this, through ICMP errors, it should not
bother with a re-INVITE, but rather, consider the call over. On the other
hand, if B is a type of device that, if it fails, a simple re-INVITE will
allow the call to be recovered at an alternate device (the alternate would
be figured out through downstream SRV or other routing approaches), then A
should send that re-INVITE immediately.

So, how does A know which to do?

I suppose we could mandate that a re-INVITE is always done, and then, if a
481 is generated, the call is considered terminated. That would generally
work, I think, but would often be a waste. I suppose for simplicities sake
we could just specify that, although I could have sworn I had come up with a
reason you really needed to know....

-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

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: [email-masked]
Date: Tue, 12 Jun 2001 16:35:16 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]]
> 
> work, I think, but would often be a waste.

Some might even go so far as to phrase that as 
choosing "generality over efficiency."

;)

/a

P.S. I don't like the word "mandate" in this context. I
     kind of prefer "suggest."

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Jun 2001 08:18:45 -0700 (PDT)

> reason you really needed to know....

   Unless there's some other reason, I would think that
   this is just an implementation detail, and up to the
   UA. The reason is that there are probably more reasons
   to do a re-invite than just this. For example, I may
   as a matter of course want my UA to reinvite if it's
   on a flakey network (like, oh say, cellular) to help
   smooth out bumps.

	      Mike