Subject: RE: [Sip] Path to Working Group Item

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 5 Mar 2002 13:07:33 -0500

PATH.  The name is known to many people, the 3GPP, the cable labs, etc.
It is used in dozens, if not more,  *large size* documents on both fronts.  

As far as I can tell there is only one lone voice that does not like the
name PATH.
We dont need to redit all of the above documents & re-educate people who
actually have a vested interest  just for philosophical stands.
There must be more compelling reasons to that. I havent seen any.

Rgds/gf

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:39 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Path to Working Group Item
> 
> 
> 
> >  > So would you propose to call the header-for-use-with-REGISTER
> Record-Route
> >  > instead of Path?
> >
> > no.  as i said, there is no need to invent a new header name. we can
> > simply define the semantics of record-route for register messages.
> > behavior of proxies would be exactly the same as for record routing
> > other messages.  you simply add a new configuration variable
> > "recordRouteRegisterMessages" to which the operator of the proxy can
> > assign a true or false value.
> 
> 
> I suppose its a philosphical distinction as to whether one 
> calls RecordRoute
> on REGISTER a "new" header" (as it isn't defined for REGISTER 
> now) or a
> "define the semantics for record-route on REGISTER messages". 
> In either case
> it's new functionality.
> 
> > the semantics at the registrar were already discussed yesterday: the
> > registrar would add the recorded route along with the 
> contact address in
> > to its database. when the proxy of the registrar then 
> receives a request
> > bound for a local user, it would forward the request 
> towards the contact
> > address and add the recorded route to the route header of 
> the request.
> 
> Yes, that's exactly what the Path draft proposes be done with 
> the record
> information on user-terminated calls.
> 
> > the only reason why we would need to invent a new header 
> name would be
> > if using record routing of register request would not be backwards
> > compatible with rfc 2543, i.e., if an old proxy that gets a register
> > request that includes record-route, would break the 
> request.  i don't
> > think that that would happen, because record-route has 
> always been an
> > optional header in register request.
> 
> Hey -- The REST of you people? How do you feel about calling this
> functionality Record-Route for REGISTER as opposed to Path 
> for REGISTER?
> 
> > this solution would be fully compatible with sip protocol 
> architecture,
> > where a register request serves the purpose of others being able to
> > reach me and where i have no need to send a register request as a
> > prerequisite of me reaching others.
> 
> Well' I'd argue that it's fully compatible with the 
> architecture whether
> it's called Record-Route, Path, or Fritz-the-Far-Out-Header.
> 
> But remember there were two problems being solved: 1) How to get
> user-terminated calls back to the user when there are 
> intermediate proxies,
> which we've apparently solved here -- we're just arguing 
> about the name. and
> 2) How to get user-originated calls routed through a home 
> service proxy when
> there are intermediate proxies.
> 
> There is only a need to send a REGISTER request as a prerequisite for
> reaching others if 1) One wishes to use the services of a non-adjacent
> intermediate proxy, and 2) one is using the REGISTER process 
> to discover the
> route to that intermediate proxy. When would one do something 
> like this? I
> don't know about the other guys, but I have speed-dialing 
> functions on some
> of my proxies. Sure, this could be in the UA, but remember I'm using a
> primitive old 3Com phone that doesn't have that capability. 
> So I've got this
> proxy that knows "If dwillis sends an invite to "1", proxy that to
> sip:[email-masked]" (ok, I just 
> made that up,
> my real speed dial list is boring), because that's just too 
> long a URL to
> type on a 10-key keypad. I don't HAVE to use this service 
> proxy, but I want
> to be able to use it when I want to use it, and that's a 
> valid architectural
> principle.
> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> 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

---

From: [email-masked]
Date: Tue, 5 Mar 2002 21:23:52 +0200

> As far as I can tell there is only one lone voice that does not like the

name is not a big deal to me as long as you take the functions out from
the path message that don't belong to the registering process, i.e.,
letting others to reach the registering party.  by the way, my
suggestion is record-register-route, which is intuitive to people who
know what record-route does.

-- juha