Subject: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc?

From: "Dean Willis" <[email-masked]>
Date: Fri, 15 Feb 2002 14:07:11 -0600

The document draft-willis-sip-path-01.txt introduces the Path extension header suggested by 3GPP in the Garcia 3GPP requirements draft in SIPPING. 

The basic requirements being met are to 1) allow a UA to REGISTER a contact which requires traversing a sequence of proxies on future messages between the registrar and the UA, with that sequence dynamically discovered during the REGISTER, and 2) allow a UA to discover from a REGISTER response a sequence of proxies between it and a known proxy offering outbound services for that UA.

The approach taken in the draft generalizes the 3GPP requirements by allowing the sequences to be asymetric-- for example, the inbound and outbound sequences might traverse different proxies, or there might only be a sequence in one direction (A firewall proxy sits between UA and its registrar, but UA does not use the registrar for outbound services).

I'd like to poll for three things:

1) Do we want to address the requirements raised by 3GPP?

2) Do we have a general consensus on something like the PATH header as an appopriate mechanism?

3) Is draft-willis-sip-path-01.txt a reasonable baseline document?

If we have consensus on all three accounts, I propose to accept draft-willis-sip-path-01.txt as a working group document, and pursue future revisions as draft-ietf-sip.xx.

If not, then please make a counterproposal.

Opinions, please.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2002 16:01:48 -0500

> 1) Do we want to address the requirements raised by 3GPP?

Yes. I think we need this for other scnearios, the infamous "hotel" case
which has a similar architecture to the 3gpp configuration. 

> 2) Do we have a general consensus on something like the PATH header as

Yes. Now that the loose route stuff in bis has been sorted out, the path
header feeds nicely into it, as a way to learn a route set to reach a
resource.

> 3) Is draft-willis-sip-path-01.txt a reasonable baseline document?

Sure.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 17 Feb 2002 15:26:41 +0200

Hi Dean:

I also agree with your proposals. I think we should take your document as a WG item. Definitely needed by 3GPP.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 19 Feb 2002 00:13:26 +0200

Miguel A. Garcia writes:

 > > The basic requirements being met are to 1) allow a UA to REGISTER a
 > > contact which requires traversing a sequence of proxies on future
 > > messages between the registrar and the UA, with that sequence
 > > dynamically discovered during the REGISTER, 

why does it matter via which proxies (other than the UA's outbound
proxy) the register message goes to the registrar?  why can't the
UA's outbound proxy add the desired source route to the messages?

 > > and 2) allow a UA to
 > > discover from a REGISTER response a sequence of proxies between it
 > > and a known proxy offering outbound services for that UA.

why can't the UA learn its outboud proxy via regular means, such as
dhcp?

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Feb 2002 17:56:06 -0600

Thanks. Although I would like to point out that this isn't "my" proposal --
I just took the liberty of writing down what I though 3GPP was asking for
(although I think I might have made one tiny impovement in the process).
Feel free to kick it around. It's not MY baby! In fact, if somebody (esp.
from 3GPP, or one of the "service route" guys who also inspired it) wants to
take over as editor, I'll happily consider offers.

--
Dean

----- Original Message -----
From: "Miguel A. Garcia" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Sunday, February 17, 2002 7:26 AM
Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc?

> > The document draft-willis-sip-path-01.txt introduces the Path extension
header suggested by 3GPP in the Garcia 3GPP requirements draft in SIPPING.
> > The basic requirements being met are to 1) allow a UA to REGISTER a
contact which requires traversing a sequence of proxies on future messages
between the registrar and the UA, with that sequence dynamically discovered
during the REGISTER, and 2) allow a UA to discover from a REGISTER response
a sequence of proxies between it and a known proxy offering outbound
services for that UA.
> >
> >
> > The approach taken in the draft generalizes the 3GPP requirements by
allowing the sequences to be asymetric-- for example, the inbound and
outbound sequences might traverse different proxies, or there might only be
a sequence in one direction (A firewall proxy sits between UA and its
registrar, but UA does not use the registrar for outbound services).
> > If we have consensus on all three accounts, I propose to accept
draft-willis-sip-path-01.txt as a working group document, and pursue future
revisions as draft-ietf-sip.xx.

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Feb 2002 18:05:15 -0600

----- Original Message -----
From: "Juha Heinanen" <[email-masked]>
To: "Miguel A. Garcia" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, February 18, 2002 4:13 PM
Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc?

> UA's outbound proxy add the desired source route to the messages?

It can, it it knows the route, without using the aproach described in this
draft. The first-hop-default-local-outbound proxy can also use the technique
described in this draft to learn the service route from the REGISTER
response. This of course requires it to be a "registration stateful" proxy,
which is probably appropriate in mobile environments using proxy-level
sgnaling compression.

> why can't the UA learn its outboud proxy via regular means, such as

It learns its first-hop default local outbound proxy from DHCP just fine.
However, this occurs in the visited network, which one assumes has no
knowledge of the services needed by the user in the user's home network. In
the situation addressed by Path combined with loose routing, the user wants
outbound services from some remote proxy (the "home proxy") , and it doesn't
yet know what other proxies (there may be many more than one) must be
traversed before its messages will get to the home proxy.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 19 Feb 2002 09:46:05 +0200

i still don't get it.  lets assume that my mobile phone (like any UA) has
been configured with its sip uri, e.g., sip:[email-masked].

when it registers, it sets the request uri to sip:mobile.com and sends
the register message either to its outbound proxy (which it had learned
via dhcp when it was turned on) or it makes a dns query and asks who is
the proxy for mobile.com and sends it directly there. it should not
matter at all to the UA or the registar through which proxies the
message got to the registrar of mobile.com.

the same for invites.  when the UA makes an invite, it can choose to use
its outbound proxy with or without a loose source route containing an
entry for its home proxy or send the invite directly to its home proxy.

-- juha

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 19 Feb 2002 23:42:18 +0200

Hi Juhan:

Your UA will send the INVITE to your outbound proxy. However, that outbound
will not be able to route the INVITE to your home server that provides you
with services, IF you didn't include some preloaded Routes.

How did you find this preloaded Routes? Through the mechanism described in
the path header draft.

So, let's go back:
a) Your switch on your mobile phone and DHCP will return you the address
   of your outbound proxy.
b) You send a REGISTER to your outbound proxy, that will route it to another
   proxy in the same visited network that is controlling a firewall. This
   other one finds the entry point in your home network, and finally your
   registrar gets the REGISTER. 4 proxies were involved for this example
   This are returned back in the 200 OK response. 
c) When you send an INVITE, your UAC will add 4 Route headers to traverse
   your outbound proxy, the firewall controller, the entry point in your
   home network and the proxy/registrar that is providing you with 
   services. After that, the INVITE is routed based on the destination.

This was an extreme example, but it may be possible.

DHCP will only provide you with the first outbound proxy address, but
not with the vector of proxies to traverse.

/Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 20 Feb 2002 08:51:25 +0200

> a) Your switch on your mobile phone and DHCP will return you the address

fine, or as bis says, if the UA is dns capable, it doesn't even need the
proxy returned by dhcp, because it can directly send the register to its
home proxy.

 >    This are returned back in the 200 OK response. 

this sounds ok if the UAC doesn't want to send the register directly to
its home proxy.

 >    services. After that, the INVITE is routed based on the destination.

if the UAC wants (which is its option) to use the services of a proxy in
its home domain, it can be either configured with the domain name of the
proxy of its home domain or it can make a dns query to find it out.  i
don't see any need for the registrar to provide that information to the
UAC with some new protocol mechanism.

-- juha