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

From: "George Foti (LMC)" <[email-masked]>
Date: Sat, 2 Mar 2002 07:29:41 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, March 02, 2002 2:30 AM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: [Sip] Path to Working Group Item
> 
> 
> Rosen, Brian writes:
> 
>  > There has been considerable discussion on the PATH header 
> on the list
>  > indicating more than significant interest to consider it a working 
>  > group item.  Are there any objections?
> 
> the number of people (in this case the mobile gang) interested in
> something should not be the only criteria of making that 
> something a sip
> working group document.  the first criteria should be that 
> the contents
> of the draft and the requirements behind it don't conflict 
> with the sip
> standard itself.

You now what the requirements are. Suggest alternatives that *address* those
requirements without breaking SIP, which you haven't done. But opted to cry
wolf.
Your only alternative has been to discount the requirements.
I suggest you switch to the mobile world and get a better comprehension of
how things work. Then we can talk.

> 
> a lot would need to changed in the bis in order to avoid the current
> conflicts.  so go ahead and get that done first and then try 
> to make the
> path header a working group document.  or may be things have 
> changed and
> now it is only money that speaks like we were able to read from a very
> frank posting earlier this week.
> 

I though it has been like that for the last 20 centuries. Nothing has
changed.

> may be our area directors can give us some guidance here?
> 
> -- juha
> 
> 

George Foti
Ericsson Canada
> _______________________________________________
> 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: Sat, 2 Mar 2002 14:45:47 +0200

George Foti (LMC) writes:

 > wolf. Your only alternative has been to discount the requirements.

that is not true.  i have suggested that you use three things instead of
the path header:

- dhcp to locate the proxy of the visited network
- dns with load balancing to figure out the proxy of the home network
- loose source routing to get the requests to the home network

and i haven't heard of any *convincing* arguments why that is not
enough.  

the only requirement i remember discounting is pinning of a particular
home proxy, which i consider a bad idea in general.  load balancing
helps to reduce the load of the entry proxies which can then route the
request further, if necessary, to a particular service proxy.

what comes to the requirements in general, i don't think that the sip
working group should take the 3gpp requirements as given from top down
by your gods, but should be allowed to consider first if they make
any sense.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Mar 2002 13:53:30 -0500

> and i haven't heard of any *convincing* arguments why that is not

Path fills two needs, and you have omitted the second one. The second
one is so that INCOMING calls to me, can be routed from my home proxy
through an intermediate proxy that needs to be visited. I think this is
well within the scope of an extension to REGISTER, and I know of no
other alternative to solve it. This is needed for any kind of
visiting/roaming network where a local proxy needs to be visited for
incoming calls. 

I would prefer to let us agree to adopt path as a work item, with the
current draft as a starting point, and then we can continue to debate
handling of outgoing calls.

-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

---

From: [email-masked]
Date: Sat, 2 Mar 2002 21:38:09 +0200

> visiting/roaming network where a local proxy needs to be visited for

no i have not omitted that one.  i proposed that if i'm visiting in a
network xyz.com, then my home proxy can route incoming calls to the
proxy of xyz.com that in turn knows where to forward the message within
that network.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 2 Mar 2002 17:01:21 -0600

> proxy of xyz.com that in turn knows where to forward the message within

Foair enough. How does the home proxy know that you're visiting xyz.com and
to route incoming calls to you care of xyz?

Two proposals have been put forward:

1) xyz.com's proxy edits your REGISTER message such that your Contact:
becomes @xyz.com and then maintains the state needed to make that work for
you in the future.

2) xyz.com's proxy adds itself to some sort of "record route" on the
REGISTER so that your home proxy can route back through it.

#1 seems to be conflict with some approaches to e2e message integrity and
requires registration-stafeulnes at the xyz.com proxy, which is an
intermediate node that may otherwise not need to be registration-stateful.

#2 doesn't seem to break integrity protection and keeps all state at the
registrar or UA, which are by definition registration-stateful anyhow.

Do you have another workable alternative to propose?

--
Dean

---

From: [email-masked]
Date: Sun, 3 Mar 2002 08:33:10 +0200

> to route incoming calls to you care of xyz?

by checking from the registrar where my contact points to.  my home
proxy can make a reverse lookup if i haven't registered with a domain
name in the contact or, better, the registrar does it before it enters
the contact in its database.

jonathan, i start to suspect that also your company has vested interest
in 3gpp :-).  also the other "fathers" of the sip protocol that have
previously very vigorously protected sip from unnecessary extensions
have been surprisingly quiet on this one.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 3 Mar 2002 00:54:04 -0600

> the contact in its database.

Ok, please pretend I'm stupid (shouldn't be hard, might even be true) and
explain this in very small words.

Here's a real scenario, called "Dean's House".

My SIP phone (a lovely antique 3Com) has an address of 63.64.250.84 which it
was assigned by a nearby DHCP server.

So it registers with a Contact: [email-masked]. There's a proxy at
63.64.250.83 that  I need incoming INVITES to traverse.

Let's say I register with a remote registrar, like the one at
"dynamicsoft.com" (63.110.3.106).

How the heck does the registrar know about the proxy at 63.64.250.83?

Please feel free to examine the DNS, do reverse lookups, etc. in order to
answer the question.

Keep in mind that this is a real-world scenario, with valid addresses, real
equipment, and with the DNS limitations imposed by at least two different
real-life ISPs.

.--
Dean

---

From: [email-masked]
Date: Sun, 3 Mar 2002 09:39:57 +0200

> How the heck does the registrar know about the proxy at 63.64.250.83?

dynamicsoft's registrar doesn't need to know about the proxy of the
domain you are visiting.  it just converts your contact
[email-masked] into domain name, e.g.,
[email-masked] and enters it in its database.

when someone tries to invite you at [email-masked], the call
gets routed using normal rules to the proxy of dynamicsoft.com.  the
proxy of dynamicsoft.com then asks the registrar where you are
registered at and turns the invite to [email-masked] into
invite to [email-masked].  

that invite will then get routed EXACTLY as the book says, i.e., the
proxy of dynamicsoft queries dns to find out the proxy of
host.visitedDomain, and will forward the invite there.  that proxy will
then have local knowledge on how to reach you.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 3 Mar 2002 15:07:21 -0600

----- Original Message -----
From: <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 03, 2002 1:39 AM
Subject: Re: [Sip] Path to Working Group Item

> then have local knowledge on how to reach you.

Methinks you have a very different understanding of SIP and DNS than I do.

Here's the proof, which you apparently didn't bother to research (despite
theoretically having all the necessary knowledge available) before
responding.

In this test case, if the dynamicsoft.com proxy were to do a reverse lookup
on 63.64.250.84, it would find that that this address resolves as
"dwillis3.directlink.net".

In this case, directlink.net is my ISP. They won't delegate PTR records so
that I can handle the DNS. This is pretty much normal -- ISPs have little
interest in doing DNS right for smaller customers like me. I had to fight
them to get a name that was even that close -- they started out with
something like dlci2184-3.dallas.directlink.net.

Furthermore, Directlink doesn't run a proxy, and if they did, I still
wouldn't trust them to run MY firewall proxy.

So, your proposed mechanism completely doesn't work in an ordinary,
real-world case affecting a real-live-not-completely-ignorant end user (me),
and it's not likely to work.

That's why we have the Path proposal, and I believe this pretty much wraps
up the discussion.

On a related note, if you're reading the service location procedures this
way in bis-09, we didn't clean the language up as much as we thought,
because I think you missed the point completely. Following your example, and
assuming the registrar was stupid enough to try and convert the Contact IP
address into a hostname (which they normally don't do), it still wouldn't
look for visitedDomain. Instead it would look for service records for
host.visitedDomain, which of course aren't there, as visitedDomain has no
idea that "host" is currently being used as a SIP UA and couldn't be
bothered to put that information into DNS even if it were.

--
Dean

---

From: [email-masked]
Date: Sun, 3 Mar 2002 23:21:25 +0200

dean,

i don't see how your example relates to the 3gpp requirements, which i
though was the topic of this thread. they do have a proxy at the visited
network and they can make sure that there exists an srv record for the
visited domain.  so my proposal covers they requirements without a path
header.

now you seem to be talking about something else, which i don't know what
it is.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 3 Mar 2002 21:56:44 -0600

That's the point. This is a general SIP problem that we've been talking
about for years. It just happens to apply to the 3G environment too.

It's pretty reactionary to assume that a problem is not  real just because
it was also noticed by 3G. This is real, we're solving general problems, and
the vast majority of the people who have historically contributed a great
deal to SIP seem to agree.

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.

--
Dean

---

From: [email-masked]
Date: Mon, 4 Mar 2002 07:59:57 +0200

> completely differently from regular SIP? That seems like a questionable idea

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

---

From: [email-masked]
Date: Mon, 4 Mar 2002 08:30:02 +0200

dean.

even if i myself prefer the record-route solution to your problem,i
still want to get back to your dns message, since your reply was full of
misunderstandings.

 > theoretically having all the necessary knowledge available) before

the above is a bit nasty considering you first didn't seem to read or
bother to understand my proposal.  see below.

 > "dwillis3.directlink.net".

that would be fine.

 > something like dlci2184-3.dallas.directlink.net.

directlink.net doesn't need to delegate you any ptr records.  the only
thing they need to do is to insert an srv record for
dwillis3.directlink.net pointing to your fw/proxy.  by the way, a good
isp provides you a web page to control your domain names.

 > wouldn't trust them to run MY firewall proxy.

they don't need to run a proxy.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 4 Mar 2002 10:34:09 -0600

Juha said:
> Dean Said:

I'm really working very hard to try and keep this relationship as open and
interoperable as possible. One of the things I've been repeatedly told by
the ADs is that if a 3GPP phone is designed such that it can't interwork
cleanly with "normal" internet systems, then we've failed horribly.

On first glance, I think what you are proposing could be done in a fairly
transparent manner, but I have the hunch there would be some real
complexities involving many of the load-balancing and availability
mechanisms that might be needed. I also suspect it would end up confusing a
lot of people.

> found anything that would suit the budged of a home/small business user.

It's the advantage of working with clever developers. I think the commercial
version with hardware sells for something like $100k . . . Actually, Billy
Biggs had a working SIP ALG for LINUX available at one time, and I believe
Intertex has a "consumer oriented" SIP firewall box in the $200 price range.

> a small change to the text of the bis regarding record routing of

That's exactly what the Path: header mechanism does. It defines a new
header, Path, that works basically like Record-Route might if record-route
worked on Register messages (which it doesn't right now). We debated using
Record-Route as the header name instead of Path, and seemed to think that
the behavior with REGISTER was just enough different from the behavior with
INVITE that it justified a different header name. The major difference is
that Path, as documented, provides asymmetric routing and record-route is by
definition symmetric.

So would you propose to call the header-for-use-with-REGISTER Record-Route
instead of Path?

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 4 Mar 2002 10:58:00 -0600

> isp provides you a web page to control your domain names.

Ah. Perhaps Finnish ISPs are more competent than American ones. I pay
$110/month for this connection, and actually, I'm very glad to have even the
service I get. I waited three months for installation.  I don't believe the
version of bind that Directlink was running even supported SRV records, much
less nifty stuff like NAPTR.. As I said, it took several days of persuasion
to get the original Directlink people not to give me hostnames like
dlci-xxxx-y . . . Then the original Directlink was acquired by Allied-Riser,
which ran it for about three months then bailed out of the ISP business
giving me a 30-day notice to find a new ISP. The assets were acquired by
Waymark, who (although they keep the service running pretty well) has
expressed no interest to me in making any improvements. And if Waymark goes
away, I have the choice of going to $300/month commercial service from
Verizon, the local phone company (former GTE), or switching to an AT&T cable
modem.

And if you think either of these two phone-megaliths (Verizon or AT&T) has
any interest in making my SIP connection work the way I want it to, you're
sadly mistaken. AT&T would probably force me to disconnect service if they
noticed me running a SIP server at all, just like they do for people who run
their own SMTP servers. They also only support DHCP, which would require
some sort of dynamic-DNS customization to work the way you're proposing.
They would have to dynamically create the SRV binding based on sort sort of
known-association between two address-requesting hosts using the DHCP
identifier string. That's hard. I'm sure AT&T is considering selling me some
sort of specialized-3GPP-like QoS connection service for SIP, but I bet
they'll expect me to use their proxies and probably their hard phone too.

Verizon's DNS provides no consumer SRV records and their PTR records all
encode the IP address. No joke, the ptr record for 66.12.12.130 (where
www.softarmor.com lives this week) is bdsl.66.12.12.130.gte.net. That's
right, every host in their network has the same name, but they are all in
different subdomains. We  pay roughly $800/month for this service at the
office for a 1/2 T1-equivalent DSL connection. The string "bdsl" appears to
mean "business dsl", as in the American colloquialism "giving us the
businesss".

So in short, expecting flexibility from the US ISPs providing DNS service is
not likely to be a path leading to success. Perhaps the rest of the world is
more fortunate.

--
Dean

---

From: [email-masked]
Date: Tue, 5 Mar 2002 10:49:36 +0200

> cleanly with "normal" internet systems, then we've failed horribly.

i haven't proposed anything that would make a 3gpp phone from
interworking cleanly with sip phones on the internet.  it is up to the
3gpp folks if they will allow such interworking to take place smoothly.
based on the comments on this list, they seem work hard to limit the
interworking freedom of a 3gpp phone user in order to be able to collect
from him or her as much money as possible.

 > So would you propose to call the header-for-use-with-REGISTER Record-Route

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. 

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.

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.

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.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 5 Mar 2002 11:38:45 -0600

> 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.

> 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.

> 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?

> 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

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 5 Mar 2002 11:55:40 -0600

----- Original Message -----
From: "Sean Olson" <[email-masked]>
To: "Dean Willis" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 05, 2002 11:55 AM
Subject: Re: [Sip] Path to Working Group Item

> I was opposed to this when the Path mechanism was
> first being discussed. If we define the functionality
> of Record-Route: for REGISTER, it should follow the
> same general idea as Record-Route: for INVITE. That
> is, it should define how subsequent requests within
> the same dialog are routed. This is not the same
> thing that Path: is doing.

Well, there ARE no subsequent requests within the same dialog, as REGISTER
doesn't create a dialog . . .

--
Dean

---

From: Sean Olson <[email-masked]>
Date: Tue, 5 Mar 2002 09:59:22 -0800 (PST)

Exactly ...

--- Dean Willis <[email-masked]> wrote:
> > > Hey -- The REST of you people? How do you feel
> about
> > > calling this
> > > functionality Record-Route for REGISTER as
> opposed
> > > to Path for REGISTER?
> >

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

---

From: Sean Olson <[email-masked]>
Date: Tue, 5 Mar 2002 09:55:00 -0800 (PST)

/sean

=====

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 5 Mar 2002 13:27:44 -0500

> functionality Record-Route for REGISTER as opposed to Path for REGISTER?

Note the comment in section 10.3 of bis-09:

        A registrar might receive a request that traversed a proxy
        which treats REGISTER as an unknown request and which added
        a Record-Route header field value.

This is the justification for the text that says that both UACs and UASs
MUST ignore Record-Route in REGISTER requests and responses.

This was, indeed, exactly the motivation for calling this header something
other than Record-Route.

-- 
Jonathan Lennox
[email-masked]

---

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

> it's called Record-Route, Path, or Fritz-the-Far-Out-Header.

i agree with that, but as i have said too many times already, the real
problem is not the name, but piggy packing with the register message
service location information.  see the previous message for why.

 > there are intermediate proxies.

sip solution to that is (a) use dns to locate the home service proxy and
use dhcp learned outbound proxy information + loose source route to the
home proxy to send the message out.

 > route to that intermediate proxy. 

see above. 

-- juha