Subject: RE: [Sip] Open Issue #207: Handling of session failures

From: [email-masked]
Date: Thu, 10 Jan 2002 12:51:50 -0700

Comments inline.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 12:04 PM
> To: Christer Holmberg
> Cc: [email-masked]; Hearty, John
> Subject: Re: [Sip] Open Issue #207: Handling of session failures
> 
> 
> CHANGE IN DIRECTION OF THIS ISSUE - read below!! (I suspect most have 
> not been following this thread)
> 
> 
> 
> 
> 
> Christer Holmberg wrote:
> 
> > Hi,
> 
> >>>Q3:
> >>>
> >>>Also, the draft doesn't say anything about the case where 
> BOTH nodes
> >>>detect the media failure. Assume that both UA1 and UA2 detects the
> >>>media failure. The re-INVITE sent by UA1 may end up at UA3, and the
> >>>re-INVITE
> >>>sent by UA2 may end up at UA4, in which case things may 
> get messy. One
> >>>of my phones may send the re-INVITE, and suddenly my other phone
> >>>starts ringing... or something like that... 
> >>>
> >>See above. Requests are not generally routed to alternates
> >>gratuitously.
> >> 
> >>The above case would only happen if both ends actually fail
> >>simultaneously. I am not that concerned about this situation.
> >>
> > 
> > NONE of the end nodes have to fail. BOTH may, however, 
> detect the media
> > failure simuntaneously, due to an error in the IP network, 
> in which case
> > BOTH would generate re-INVITE - and what I described above 
> may happend.
> 
> 
> True, but you are asusming above that those re-invites are routed to 
> different servers. They are regular in-dialog requests, and 
> unless there 
> has been an element failure that invokes srv or failure 
> processing at a 
> proxy, it will be delivered to the proper UA.
> 
> 
> >>The issue is simple - on detection of a media failure, do we specify
> >>that a UA SHOULD generate a re-INVITE, in order to allow 
> the far end to
> >>reconsistute session and dialog state in the event the media failure
> >>was
> >>due to a failed endpoint? The cost is low, the potential 
> benefits are
> >>high. I say yes.
> >>
> > 
> > What do you mean by "failed endpoint"? A SIP endpoint? Does 
> this mean
> > that the node have to check that the ICMP message actually 
> came from the
> > remote SIP user (and not, for example, from an intermediate router)
> > before it decides if to send a re-INVITE or not?
> 
> 
> No, you are reading too much into the statement.
> 
> 
> > 
> > I do NOT have anything against adding what you propose as a 
> SHOULD to
> > bis, but I would like the text to say that it should be 
> done only when
> > the client is pretty sure that the remote SIP endpoint really has
> > failed, and that a re-INVITE would do any good. Otherwise 
> the network
> > could be overloaded with "useless" re-INVITEs when there is a major
> > failure in the IP network, but the SIP nodes are working 
> just fine... In
> > this case I think we would even avoid many of the issues 
> above (Q3, for
> > example).
> 
> 
> Now, THIS is a good point.
> 
> A network failure, could trigger a storm of INVITEs which might only 
> make the situation worse.
> 
> OK, I am willing to concede that use of the mecahnism when you don't 
> know that it is the endpoint that failed, could be quite bad.
> 
> So, since:
> 
> (1) it could actually hurt alot

It is not clear to me this would hurt alot.  The extra SIP messages are
likely to be insignificant compared to all the RTP and ICMPs bouncing
around.  I'll conceed they may not be going exactly the same place, so some
network segments could get pounded that previously saw little traffic.

> (2) it is possible to add this later through an extension (Supported: 
> reconstitute in INVITE, Require: reconstitute in 2xx)
> (3) you can't COUNT on it being there anyway, since its not 
> in rfc2543 
> or many versions of bis
> 
> I will back off and we will punt this to an extension if people still 
> feel it is valuable, but we do need to do some work to make 
> sure that it 
> works properly, and I don't want to hold up bis on it.
> 
> In place of this, I would propose that the proper endpoint 
> behavior on 
> detection of media failure is a matter of local policy; however, 
> automated generation of BYE or re-INVITE is not recommended to avoid 
> flooding the network with traffic (the user will likely hang up 
> themselves). If these messages do need to be sent automatically, they 
> should be sent after some randomized interval.
> 

My main goal was to have the end receiving ICMPs do something to figure out
if there was a valid session, and either stop sending RTP or reconstitute
the session.  Anything would be better than no action at all.  I'm a bit
concerned that leaving this up to local policy = no action at all.  At this
point it appears the bis is not the place to address this problem.  I agree
with the randomized interval for automated generation of messages though.

John Hearty
Level3

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2002 08:39:58 +0200

Hi,

>network segments could get pounded that previously saw little traffic.

Yes, and especially if the control- and media nodes are separated (eg
using H.248/MGCP) the SIP signalling and RTP media will most likely use
different paths.

I DO agree (I've said it myself in the UDP vs TCP discussion) that the
signalling traffic (number of IP packets) is pretty small compared to
the media traffic, but why make things worse?

Also, the signalling traffic also affects intermediate SIP nodes, which
we don't want to overload unless necessary (eg a proxy could suddenly
get tens of thousands of re-INVITEs from a gateway, and as many
re-INVITEs from the endnodes talking to that gateway, and none of these
re-INVITEs will do any good since the error is in the IP network...).

I think, and agree with Jonathan, that this should be done based on
local policy. That, however, doesn't mean we don't have to say a word
about it. But, as proposed it should be done within an extension (by
defining a new SIP extension or simply by making a BCP document) outside
the scope of bis.

Regards,

Christer Holmberg
Ericsson Finland