Subject: Re: [Sip] Header name in draft-willis-sip-path-02.txt, was: I-D ACTION:draft-illis...

From: [email-masked]
Date: Mon, 1 Apr 2002 15:32:01 -0500

Some quick questions:

*) Question 1
============
Section 4.1 quotes:
"It has been suggested that the UA MAY choose to store the contents of    the Path header for future use as a preloaded
Route for use when the  UA wishes to send a SIP message that, for reasons of acquiring  services in the home network,
need to transit the service proxies in    the home network.  Such usage is explicitly outside the scope of this
 document."

Section 4.4: Procedures at the Home Proxy

"With the addition of Path, the home service proxy also copies  (inverted) the route set associated with the specific
contact in the  registrar database into the Route header of the outgoing message as a preloaded route.
 This causes the outoing message to transit the set   of proxies that indicated that they were to be used in future
   messages to that contact by including themseleves in the Path header"

ARC> Is it correct to assume that in such a n/w the homeproxy will surely be in the path of all SIP requests originating
from this UA ? If so, then Path orders are already being converted to Route Sets by the outgoing proxy as per above
qoute. So if the UA were to 'pre load' this same route (earlier quote) for whatever reason,
 what would happen when this pre-loaded route arrives at the Home Proxy who will attempt the same operation ?

*) Question 2
============
Also, the path header is being introduced because doing the same in RR is
not backward compatible.
Just wondering: The RR has progressed in such a way that we now have the
old R-R (no pre-loaded routes)
and the new R-R (pre-loaded routes). The current RFC states that
record-routes should be ignored in REGISTERs
and not followed in its 200OK.  To allow this case, cant this wording be
changed in the RFC saying the REGISTRar
may choose to ignore Route sets in REG/OK ? Even as of today, putting RR in
REGISTER wont break impl - it would
be ignored. Anyway backwards compatibility hardly seems to be the concern
specifically with RR looking at how
it has changed over time. So why not relax its usage and avoid another
header that does exactly the same thing ?

I am in favour of not overloading one header to mean a hundred things, but
to me this case looks like it means the same
thing really. Just that now we are saying RR is possible for all requests.
What the entities do with RR in non-dialog
related transactions is upto it.

Regds
Arjun
--
Arjun Roychowdhury @ Hughes
11717  Exploration Lane,
Germantown, MD, 20876
(O): 301-212-7860    (M):240-475-2139

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Tue, 2 Apr 2002 08:36:29 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, April 01, 2002 2:32 PM
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] Header name in 
> draft-willis-sip-path-02.txt, was: I-D ACTION:draft-illis...
> 
> 
> 
> Some quick questions:
> 
> 
> *) Question 1
> ============
> Section 4.1 quotes:
> "It has been suggested that the UA MAY choose to store the 
> contents of    the Path header for future use as a preloaded
> Route for use when the  UA wishes to send a SIP message that, 
> for reasons of acquiring  services in the home network,
> need to transit the service proxies in    the home network.  
> Such usage is explicitly outside the scope of this
>  document."
> 
> 
> "With the addition of Path, the home service proxy also 
> copies  (inverted) the route set associated with the specific 
> contact in the  registrar database into the Route header of 
> the outgoing message as a preloaded route.
>  This causes the outoing message to transit the set   of 
> proxies that indicated that they were to be used in future
> ARC> Is it correct to assume that in such a n/w the homeproxy will 
> ARC> surely be in the path of all SIP requests originating
> from this UA ? If so, then Path orders are already being 
> converted to Route Sets by the outgoing proxy as per above 
> qoute. So if the UA were to 'pre load' this same route 
> (earlier quote) for whatever reason,  what would happen when 
> this pre-loaded route arrives at the Home Proxy who will 
> attempt the same operation ?

Doing something like that which is explicitly out of scope for this
document in 4.2 is an attempt to force the home proxy to be in the path
of all SIP requests from this UA. Without some kind of mechanism, the UA
may not have any way to route requests thru that home proxy. In this
scenario, the pre-loaded route is consumed getting to the home proxy, so
I don't thgink what you're worried about here actually happens.

See draft-willis-sip-svcrtdisco-00.txt for discussion of this technique.

> *) Question 2
> ============
> Also, the path header is being introduced because doing the 
> same in RR is not backward compatible. Just wondering: The RR 
> has progressed in such a way that we now have the old R-R (no 
> pre-loaded routes) and the new R-R (pre-loaded routes). The 
> current RFC states that record-routes should be ignored in 
> REGISTERs and not followed in its 200OK.  To allow this case, 
> cant this wording be changed in the RFC saying the REGISTRar 
> may choose to ignore Route sets in REG/OK ? Even as of today, 
> putting RR in REGISTER wont break impl - it would be ignored. 
> Anyway backwards compatibility hardly seems to be the concern 
> specifically with RR looking at how it has changed over time. 
> So why not relax its usage and avoid another header that does 
> exactly the same thing ?

There was list discussion of this several weeks ago, and I recall
Jonathan Lennox made a definitive report on why RR is not the way to go.

--
Dean