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

From: "George Foti (LMC)" <[email-masked]>
Date: Mon, 4 Mar 2002 07:12:10 -0500

First, you are extending the meaning of record-route in core SIP. 
Secondly,  it does not fully solve the problem of 3GPP, as the registrar
will need to include itself in the PATH, in the response sent to the mobile
for subsequent requests.
I dont think it is clean to tinker with record-route. 

/gf

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 1:00 AM
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] Path to Working Group Item
> 
> 
> Dean Willis writes:
> 
>  > It seems that you are suggesting that 3G's implementation 
> of SIP should work
>  > completely differently from regular SIP? That seems like a 
> questionable idea
>  > to me.
> 
> 3gpp is a closed community which will exactly define how their phone,
> registrar, or proxy will work and will specify it in their standards.
> so it would not be any hassle for them to say that a 3gpp registrar
> stores the contact information of visiting phones as domain 
> names.  this
> was the only new thing that i proposed and it would be purely an
> implementation issue not affecting ietf sip standards.
> 
> but lets now get back to your new example, where (i think) 
> you have been
> given a subnet of global ip addresses for your home or small business,
> but your isp is not willing to add an srv record for the domain
> *.dlci2184-3.dallas.directlink.net. that so if i have understood
> correctly, your case is this:
> 
> SIP UA --- LAN --- FW/Proxy --- Internet --- Registrar
> 
> and that would like to do is to make incoming calls to your ua to be
> routed via your fw/proxy.
> 
> by the way, since you said that this is a real world example, 
> where did
> you buy the FW/Proxy?  i would like to buy one too, but haven't yet
> found anything that would suit the budged of a home/small 
> business user.
> 
> what you describe is a valid problem and luckily we already have a
> header that solves it.  that header is called record-route.  when you
> send your register message to your fw/proxy, that proxy, 
> knowing that it
> needs to be on the path when someone calls you, adds a record-route
> header to the register message and forwards it to your 
> registrar.  your
> registrar then inserts the record route along with the contact address
> in its database.  when someone calls you, the proxy of the registrar's
> domain adds the corresponding route header to the invite 
> message and we
> are done.
> 
> the only thing we thus need to do to solve this valid problem 
> is to make
> a small change to the text of the bis regarding record routing of
> register messages.
> 
> -- juha
> 
> 
> _______________________________________________
> 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: Mon, 4 Mar 2002 14:28:34 +0200

> will need to include itself in the PATH, in the response sent to the mobile

what i'm proposing is make record routing now to apply also to the
register messages, which is much cleaner that inventing a new message
for the same purpose.  by record routing a register message, the network
allows registering both the contact address and the route to it, which
is consistent of the meaning of record route.

your other "requirement", i.e., that the mobile should get back the
route to be used for subsequent requests, i have already before
dismissed as bogus, because it is grossly against the sip protocol
architecture. in sip, register messages do not establish a dialogue and
in sip anyone is able to make a call without first registering itself.

-- juha