[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] New I-D on UA loose routing
Ok, so revising my earlier response, what about embedding a SIP header
called "UA-Opaque" in the URI so that we can (I think) continue to use
baseline UA behavior.
Regards,
Brian
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan.mahy at gmail.com]
> Sent: Monday, October 30, 2006 9:22 AM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] New I-D on UA loose routing
>
> Hi,
>
> First I'd like to propose a concrete counter proposal. Dean
> would call this an additional "band-aid" but I feel like the
> patient has painfully managed to recover pretty well from 2nd
> degree burns over 60% of the body and now just has a
> persistent paper cut.
>
> We define a new URI parameter called 'ua-opaque'. When an
> authoritative proxy receives a request with this parameter in
> the request URI (in an AOR or a GRUU), it copies the value of
> this parameter into any URI it retargets to. This
> functionality is mandatory for URIs which are GRUU. This
> parameter effectively replaces the 'grid' parameter by
> providing a simple superset of the functionality.
>
> I believe that this approach has significantly better
> backwards compatility and maturity than the UA loose-route
> approach. Below I will list the technical problems I see with
> the UA loose route approach.
>
> 1) Outbound. the current outbound draft has language about
> what the first edge proxy needs to do. One of the ways to
> tell if the first proxy did its job is to check the first
> element in the Path vector for the 'ob' parameter. I don't
> believe this would work anymore. Maybe I am not smart
> enough, but I can't think of a way to make detection that
> outbound will work in a UA loose-route environment, short of
> a first-hop Proxy-Require, which a number of folks where
> adamantly against.
>
> 2) Forking / HERFP. There are some UAs which reject requests
> to them with Route headers left with a 400 and some with a
> 403. To be safe, a proxy will need to forward in the
> traditional manner to non-loose-route UAs, or risk
> exacerbating HERFP. A proxy forking to both UA loose-route
> and non-UA loose UAs therefore needs to keep track of both
> and effectively run two separate code paths for different
> branches for the same target set.
>
> 3) Marid-style assumptions. Like the problem with outbound,
> a proxy that wants to check that requests are either for its
> domain or from its domain and that it is receiving requests
> for its domain directly (not through an intervening proxy)
> may have a harder time figuring out if it is the first proxy.
>
> thanks,
> -rohan
>
>
> On 10/26/06, Jonathan Rosenberg <jdrosen at cisco.com> wrote:
> > You are equating processing a Route header, with being a proxy.
> > Nothing in RFC 3261 says that if you process a Route
> header, you are a proxy.
> > Indeed, RFC 3261 is silent on the applicability of Route
> headers to UA.
> > Certainly I agree we don't want to require a UA to do thigns like
> > mutual TLS.
> >
> > Indeed, I would like to understand what concrete problems you see.
> > Your note points out that there could be other solutions, and then
> > complains that this is making things confusing. Yes, there could be
> > other solutions - I look forward to your draft. I don't
> think it makes
> > things more confusing.
> >
> > I think this mechanism is quite elegant in that extends the idea of
> > loose routing to UA, and is arguably what we should have
> done in SIP
> > in the first place.
> >
> > -Jonathan R.
> >
> >
> >
> >
> >
> > Rohan Mahy wrote:
> >
> > > Hi,
> > >
> > > I have read this draft and I think it is a terrible idea
> in SIP/2.0
> > > to send a UA an incoming request with a Route header. If we were
> > > working on SIP/2.1 or SIP/3.0, I think this approach would be a
> > > fruitful idea to consider as baseline behavior, but I
> think this is
> > > too major of a change from the current spec and state of
> implementation.
> > >
> > > Lets analyze the requirements described in the document.
> The unkown
> > > gruu, limited-use gruu, subaddressing, and service invocation
> > > requirements can all be met just by restoring the grid
> parameter to
> > > its rightful place in GRUU. The emergency services
> requirement is a
> > > tautology; if a proxy wants to rewrite the Request-URI
> from an SOS
> > > URN, don't do that, insert a loose-route instead; no additional
> > > mechanism or specification is necessary. The freephone
> requirement
> > > deals with mixed SIP and PSTN networks, where the existing
> > > History-Info (or dare I say Diversion) mechanism is perfectly
> > > adequate and more likely to be implemented in this
> environment. The
> > > alias requirement can be addresses in a variety of ways including
> > > configuration, or simply restoring the To header to
> usefulness. My
> > > conclusion is that this mechanism does not solve any
> requirements we
> > > are not already addressing. (If we were starting from
> scratch, we
> > > might do things differently).
> > >
> > > As for the implications of handling loose-routing on the UA, I do
> > > not believe the expected behavior is easily containable. The only
> > > entities that should receive requests with additional
> Route headers
> > > are proxy servers. Embedding a proxy server in/on a UA then
> > > requires the UA to implement TLS, strict route fix ups, loop
> > > detection, and a host of other things. I don't think we
> want to go
> > > there. The alternative is for us to break the rules and define a
> > > "sort of a proxy" role. I expect picking apart what parts of
> > > RFC3261 need to be implemented as a proxy would be a
> nightmare. I
> > > can also imagine the impact on the outbound draft if each
> outbound
> > > UA needs to route through an embeded edge proxy. How
> will the first
> > > "real" edge proxy decide if outbound processing has been
> done correctly?
> > >
> > > The concept of logical roles such as proxy, registrar, identity
> > > server, etc. is already confusing to many implementors.
> If we start
> > > redefining or breaking the rules which describe existing roles, I
> > > believe we are going to have a real mess on our hands.
> > >
> > > thanks,
> > > -rohan
> > >
> > >
> > >
> > > On 10/13/06, Jonathan Rosenberg <jdrosen at cisco.com> wrote:
> > >
> > >> I've submitted a new I-D which describes this concept of
> UA loose
> > >> routing that we've been discussing on the list. This fell out of
> > >> the GRUU discussions as an alternative solution for grid. As the
> > >> draft explains, the mechanism also solves many other
> problems, like
> > >> sub-addressing, limited use adresses, 8xx number usage,
> and is even
> > >> required for proper 911/emergency services operation with ecrit.
> > >>
> > >> Until the draft appears in the archives, you can pick it up at:
> > >>
> http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00
> > >> .txt
> > >>
> > >> Thanks,
> > >> Jonathan R.
> > >> --
> > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> > >> Cisco Fellow
> Parsippany, NJ 07054-2711
> > >> Cisco Systems
> > >> jdrosen at cisco.com FAX:
> (973) 952-5050
> > >> http://www.jdrosen.net PHONE:
> (973) 952-5000
> > >> http://www.cisco.com
> > >>
> > >> _______________________________________________
> > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > >> This list is for NEW development of the core SIP Protocol Use
> > >> sip-implementors at cs.columbia.edu for questions on
> current sip Use
> > >> sipping at ietf.org for new developments on the application of sip
> > >>
> > >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> > Cisco Fellow Parsippany,
> NJ 07054-2711
> > Cisco Systems
> > jdrosen at cisco.com FAX: (973) 952-5050
> > http://www.jdrosen.net PHONE: (973) 952-5000
> > http://www.cisco.com
> >
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip