[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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