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

From: [email-masked]
Date: Mon, 25 Feb 2002 17:42:23 +0200

Hi Juha!

In certain network configurations (e.g. the IMS of
3GPP) such behavior makes sense.
The registar (let's call it S-CSCF) is one of the hops,
every INVITE has to pass, because the S-CSCF is at the
same time the element, which has to be visited for the
user's outbound services.

If there is a security (e.g. firewall) element between
the UA and the S-CSCF (let's call this security element
I-CSCF), the same mechanism can be used so that the
INVITE can be routed smoothly through, without heavy
processing in the proxies.
These kind of scenarios I believe cannot be solved
using your earlier proposal.

The LOOSE routing does not fully cover the requirments,
which are addressed by the Path header proposal.

 Conclusion:
 Your proposal does not fullfill all requirements,
 which can be solved by the Path header proposal. 

cheers,
 Bernie

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 25. February 2002 12:54
To: Drage, Keith (Keith)
Cc: 'Dean Willis'; [email-masked]'
Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc?

i don't quite understand how people can say that the working group
should introduce a new protocol mechanism (path header) although there
has been no technical evidence that the existing mechanism are not
enough for the user to accomplish the same thing as the with path
header.

there was an email exchange about this a few days ago, but i didn't get
any response to my email where i described how the same thing can be
done without any new message headers.

this path header business started BEFORE we had LOOSE source routing in
the bis.  without loose source routing we would have needed something
like path header, but not anymore when loose source routing.  therefore
there is no more any justification for the path header as a working
group item.

-- 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, 25 Feb 2002 18:02:35 +0200

> user's outbound services.

fine, then simply create an SVR record for the home domain of the UA
that points to the S-CSCF.  if the UA wants to use services of its home
domain for an invite, then the UA creates a loose source route that
contains this S-CSCF and sends the invite the outbound proxy that it has
learned via dhcp from the visited domain.

 > using your earlier proposal.

see above. using the outbound proxy of the visited domain should get the
messages through local firewalls.

 >  which can be solved by the Path header proposal. 

conclusion:  you still fail to show why path message is needed.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 25 Feb 2002 13:02:39 -0600

Keith and Juha have requested a scenario outside of 3GPP wherein a mechanism
like PATH is useful. Keith is specifically interested in services where the
PATH may not be symmetric.

Here's one. It's the "non-adjacent registrar" problem that I've been

I have a SIP phone at home that I use for business purposes.

I use a registrar/location server at the office to provide a contact point
for the address-of-record sip:[email-masked].

Today, my phone sends a REGISTER to this registrar, associating
sip:[email-masked] with sip:[email-masked].

Normally, people making a SIP call to me use the SRV procedures and find my
location server. They send it an INVITE. It looks in the registration
database, finds the registration from my home and office phones, and forks
out INVITES to those phones. I don't have outbound services from this
proxy/location server, it's just used for inbound calls. Pretty basic so
far, right?

Ok, being a paranoid sort, I really want a home proxy-firewall that also
offers outbound services for calls placed from my home SIP phone. Once I
have this installed, the IP address of my phone becomes 192.168.139.3 . . .

So, what gets registered on the dynamicsoft registrar?

As is, the phone generates a contact of sip:192.168.139.3. It passes this in
a REGISTER thru my proxy-firewall.The registrar dutifully records this a a
contact for sip:[email-masked]

But what happens when I get a call? The location server tries to fork the
INVITE to the the address 192.168.139.3, finds that it has no route to that
address, and fails.

What we need is a way to get the incoming INVITE sent from the location
server to my proxy-firewall instead of directly to the registered contact.

Three proposals have been suggested:

1) Give my home phone knowledge of the proxy it's behind, and have it insert
an adjusted Contact: in the REGISTER. This of course requires replacing all
the phone software, and is a pain in the behind (I have a 3Com phone right
now, no software updates available as far as I know).

2) Have the firewall-proxy patch the contact address in the REGISTER to be
dwillis@proxyip. This would probably work, but has the annoying habit of
breaking extended-digest authentication (which, since I'm using standard
digest, is ok for me, but makes it not a generally good solution).

3) Have the firewall proxy add a Path: header containing its own IP address
on the REGISTER. The registrar then stores both the Contact: value and the
Path: value from REGISTER.

So, assume we use #3.

(Warning, I'm using an easy-read synopsis format of SIP messages, so some
details are missing)

1) Phone sends REGISTER with Contact: sip:[email-masked] toward
registrar "dynamicsoft.com".

2) Proxy adds Path:  63.6.250.83 to the Register.

3) Registrar stores Contact and Path values for identity
[email-masked]

 . . . . we're registered . .  .

4) Juha calls sip:[email-masked] from his deskphone in Finland

5) Using SRV procedures, INVITE is delivered to location server
"dynamicsoft.com".

6) Location server proxies INVITE toward my home phone, preloading the
Route: header with the loose route value stored earlier (Path).

7) Loose routing delivers INVITE to my home proxy firewall at 63.64.250.83

8) Proxy firewall strips off loose route element, delivers INVITE to phone
at 192.168.39.3

9) My phone rings, I say "Paiva" (caller ID, eh) and Juha and I discuss the
magic of Path and tell jokes at Keith's expense.

Note that I don't want OUTGOING calls from my home phone routed through my
office location server. That would just be a waste of CPU . . . (that's why
the asymmetric mechanism, Keith!)

--
Dean