Subject: Re: [Sip] New I-D on UA loose routing

From: Shida Schubert <[email-masked]>
Date: Wed, 01 Nov 2006 15:21:26 -0800

Both Brian's and your proposal concerns me a bit. Although,
I may simply be confused about all this.

AFAIK grid is only meaningful to the entity that provided the
grid in the first place(UA that provided the grid in the Contact,
conference server etc.).

Imagine a scenario below.

1. Alice receives a call from Bob's home phone and
ua-opaque is used to identify each family member's phone in
Bob's household(sub-addresing).
2. Contact Alice receives in the INVITE has
[email-masked];ua-opaque=steve
3. Alice later calls Bob using the call-log but call is
redirected to Carol's house who is Bob's sister.
4. So R-URI is rewritten from [email-masked];ua-opaque=steve
to [email-masked];ua-opaque=steve if the ua-opaque is
retained through retargeting as you suggested.
5. If Carol's house has steve as a family member and uses
ua-opaque to address each family members as Bob's house,
call will be routed towards Steve.

Now, there may be no problems with the outcome mentioned
above, but I really don't know if this is the kind of behavior we want.

Also the solution mentioned below will only address one of the
issues loose-route is trying to address(Retaining opaque value
through AoR to contact translation). The loose-route AFAIU also
tries to retain the original request target(AoR), which your solution
does not address.(Although I question why p-called-party-id can't
be used to address this issue)

Lastly I don't agree with having GRUU dependent on ua-opaque or grid
like mechanism. They both address different issues. GRUU has its place,
and grid or ua-opaque also has its place but I see no reason to necessitate
dependencies.

Regards
Shida

Rohan Mahy wrote:
> 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 <[email-masked]> 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 <[email-masked]> 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
>> >> [email-masked] 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 [email-masked] for questions on current sip
>> >> Use [email-masked] for new developments on the application of sip
>> >>
>> >
>>
>> -- 
>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
>> Cisco Fellow Parsippany, NJ 07054-2711
>> Cisco Systems
>> [email-masked] 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 [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