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

From: [email-masked]
Date: Fri, 11 Jan 2002 04:58:03 -0700

Agreed.  All good points.  Lets wrap this one up.

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

_______________________________________________
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