[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Comments on lawrence-maxforward-problems
On Sun, 2005-11-06 at 10:14 -0500, Jonathan Rosenberg wrote:
> I just got around to reading this draft. Excellent document, thanks for
> doing this. It points out a real issue that will one day hurt a lot if
> we don't address it proactively.
>
> I also like the suggestion for inclusion of the request message in the
> body of the response for diagnostic purposes. One thing though - lots of
> folks use a SIP request with Max-Forwards of 0 as a single-hop ping to
> detect whether the downstream element is alive. Its really a waste to
> always include the request body in the response for these, as its not
> needed - this is truly a forced attempt at an error response.
It wouldn't be all that interesting in that case, I agree - I wasn't
aware that was done. It would perhaps be a good idea to check the
number of Vias on the message and only include the request in error
responses if there was more than one Via on it.
>
> Paul Kyzivat wrote:
>
> >
> >
> > Cullen Jennings wrote:
> >
> >> My favorite solution is "Disallow registration to arbitrary contacts".
> >> Register was meant to bind a contact to an AOR. When you use it to try
> >> and
> >> bind an AOR to an AOR to provision a forwarding rule, it is basically
> >> broken. I view this is the Doctor Doctor category and think that
> >> provisioning forwarding should be done in some other way than
> >> registrations.
> >> That way you can provide other info in the provisioning like if it
> >> should be
> >> serial or parallel fork.
> >
> >
> > I don't find this very attractive. Limiting a general mechanism to the
> > usages we currently think important is a good way to screw up the protocol.
> >
> > But more importantly, it wouldn't solve the problem. Other mechanisms
> > will surely be available for configuring forwarding addresses, whether
> > this change is made or not. And they are equally useful creating the
> > scenario.
>
> I agree with Cullen. I think that limiting registrations to "self" along
> the lines of sip-outbound is the right solution.
But doesn't that prohibit functionality that we really want to have?
Suppose I'm on a network where I must relay all SIP through a local
proxy - I register with that Proxy to get a GRUU, and then register my
'home' AOR to forward to that GRUU. The 'home' registration will to be
forwarding to my home domain, but I certainly want it to succeed.
> You are correct that
> one might still have ways to configure call forwarding (as they should)
> which might have this effect. However, I might argue that if these are
> provisioned in some other way, there are several things a proxy might do
> when handling these forwarding operations:
>
> 1. disallow forwarding to more than one destination if those
> destinations are outside of the domain; if they are inside the domain
> (i.e., hunt group), you can do a loop detection at PROVISIONING time,
> and fail the provisioning requests in the first place
Other than actually sending a request to the forwarded address to see if
you get it back, I don't think there is a practical way to do the loop
detection at provisioning time. The you only need the exploding
addresses to be at either end of chain of forwarded address, which could
be in the same domain or a different one.
> 2. If a request is forwarded, put some kind of flag in the request which
> disables additional forwarding, much like a diversion count (whose
> limits are set MUCH lower - like 2 or 3).
But additional forwarding is exactly what often makes SIP so robust.
I've lost track of the number of times that someone asked me to look at
a system configuration and I discovered that it was only working because
addresses spiraled through some odd sequence they were not aware of
("the phone rang, so I thought the routing was correct").
--
Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence at pingtel.com
Consulting Engineer - Pingtel Corp. http://www.pingtel.com/
sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP