Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Tue, 15 Jan 2002 08:30:51 -0700

If loop detection is not reasonable, it may be still reasonable to make
loop avoidance a topic in the forthcoming implementer's guide. Our
existing PBX product, for instance, initiates a 15-second timer when
forwarding. New calls received within that period are treated as if the
forwarding request were not in place, thus preventing a form of deadly
embrace between the local phone switch and the PBX across all remaining
trunks. I would think a similar solution is applicable to SIP servers,
but as an implementation detail.

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 

-----Original Message-----
From: Neil Deason [mailto:[email-masked]]
Sent: Tuesday, January 15, 2002 5:31 AM
To: [email-masked]
Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft:
Pre-existing Route headers

> Christer Holmberg wrote:
> 
> > Hi,
> >  
> > 
> >>Anyone for deprecating loop detection? A proxy that doesn't 
> do it would
> >>have to insert max-forwards if not already present, that is the
> >>
> > penalty.
> > 
> >>We also need a minimum value for Max-Forwards, something like 20 is
> >>more than sufficient, I think.
> >>
> > 
> > Do we need to specify a minimum value in the spec? I think 
> the value is
> > something which is very dependent on the size and 
> architechture of the
> > network, and should be configurable. 
> 
> 
> That is a recipe for disaster. Big disasters.
> 
> Remember, calls go between domains that are frequently not in 
> any kind 
> of business relationship. I have no way of knowing what kind 
> of network 
> is downstream. So, we choose a value which is sufficiently large to 
> cover all realistic cases. Having it configurable means it could be 
> right today, but wrong tomorrow. Shall I have all my 
> customers support 
> calls get forwarded to you, Christer, so you can explain why a call 
> yesterday won't work today because a different network provider 
> installed a new proxy?

If we have no way of knowing what network SIP will run
over now, or in the future, what is guaranteed to
always be a large enough number? Though this will 
create inefficient network usage. It is unclear how 
B2BUAs would interact with Max-Forwards headers as they 
pass through their UAS|UAC state machine. RFC2543 UAs may 
(i.e. will) not typically add in Max-Forwards 
RFC 2543 Proxies certainly wont add it where omitted.

Cheers,
Neil
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

<snip>

_______________________________________________
Sip mailing list  https://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

_______________________________________________
Sip mailing list  https://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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 19:57:44 -0500

> but as an implementation detail.

I think that is a really bad idea for SIP servers. I also think its a 
bad idea for a PBX, since I do sometimes get two calls within 15s, now 
you are saying forwarding would not work in that case.

Why does it make no sense for a proxy?

1. what is the meaning of NOT forwarding in the case of a proxy??? You 
are talking about the forwarding FEATURE, here we are talking about the 
proxy function. The only thing it can do is proxy a request.

2. How does it know that the request received a second time is the same? 
Your PBX probably looks at DNIS or something. This is equivalent to 
looking at the request-URI in SIP, and checking if there is another 
transaction in progress for that same r-uri. This would require an 
additional mapping of all transactions using purely the r-uri as the 
key. The alternative is to include the original r-uri in a hash in the 
via, and then, well, we are right back to the originally specified 
algorithm.

That said, in all honesty, nothing prevents a proxy from doing loop 
detection, since its a matter of local policy in any case. However, we 
are trying to simplify, remove and cleanse, and this is something for 
which there is a far simpler, well understood, and sufficient (given the 
probabilities of ocurrence). It is easy to do wrong, which has been a 
source of constant errors.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com