Subject: [SIP] Record-Route consensus

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 19 Nov 2000 16:28:48 -0800

Was there any consensus reached on Record-Route changes? It would be nice to
get this one nailed down.

Problems to be solved:
- handling of non-SIP Request-URI's properly.
- request transaction identification in proxies for reverse direction (I
forget the specifics)
- proxy doesn't see any inserted record-route headers in reverse direction
(eg loss of state or address info)
- detecting new behaviour in Record-Route response. 

I think the first three can be solved by the UAS only replacing the
user@host:port sections by the From/Contact in the reverse Route. The first
also requires a new Record-Route header to store the maddr. This is used in
preference to the maddr which might also be placed in the header for
backwards compat.

Detecting the new behaviour in the UAS? Any ideas? Having the UAS add a
Record-Route parameter or adding something to its COntact are both fairly
kludgey but would suffice. Proxies who support the new behavior but don't
detect this added parameter in the response know that they must store full
state for the call. 

Cheers,

Robert.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Sun, 19 Nov 2000 19:48:26 -0600

Fairlie-Cuninghame, Robert ([email-masked]):

> Was there any consensus reached on Record-Route changes? It would be
> nice to get this one nailed down.

  In my opinion, the consensus is that going through all the addresses
in the Record-Route and changing them for the reverse direction is out.
Proxies should insert an address that indicates to them enough state to
perform their function, and the spec should probably give some examples.

  The only open issue is whether to allow non-SIP URIs in the Route.  In
order to support them, the suggestion is to define Record-Route
parameters to indicate the IP address, port, and transport.  I think
this is dangerous because it won't work with outbound proxies.

  Does anyone feel strongly otherwise?

  See my post:
    http://lists.bell-labs.com/pipermail/sip/2000q4/004005.html

  And Sean Olson's post on other URI schemes:
    http://lists.bell-labs.com/pipermail/sip/2000q4/004037.html

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 20 Nov 2000 09:46:37 -0000

> this is dangerous because it won't work with outbound proxies.

I'd like to take this oppurtunity &:) to point out that the
solution I proposed -- just inserting the SIP URL of the proxy,
and embedding the Request-URI as a parameter thereof -- handles
non-SIP URIs.

I did go a step further, and suggest that called UAs did extra
mangling in the reverse direction, in that they insert the
Contact address of the caller UA as another parameter; however,
it doesn't so matter whether this is done or not, since it
would only come into play if the Route broke somehow.

So, for example, say I'm a proxy on the machine sip0.example.com,
listening on port 6000.  I receive a request:

    INVITE tel:999 SIP/2.0
    ...

I proxy on:

    INVITE sip:[email-masked] SIP/2.0
    ...
    Record-Route: <sip:sip0.example.com:6000;uri=tel:999>
    ...

Hopefully, it's now evident that in either direction, I am
going to be totally routeable (as long as sip0.example.com is
globally routeable), so as long as both caller and called UA
copy all parameters.

Unfortunately, we do lose the notion that the Request-URI
contains, somehow, the ultimate destination, but it would
be possible to perhaps have a BCP along the lines of
called UAs inserting another parameter indicating the
Contact/From (I guess it could literally be done as a
header parameter).  I did originally propose renaming
uri to original-uri, and making uri the Contact/From,
yada yada, but it does seem unecessarily painful to me
now.

Thoughts?

 - Jo.

---

From: Bertil Engelholm <[email-masked]>
Date: Mon, 20 Nov 2000 12:27:52 +0100

> this is dangerous because it won't work with outbound proxies.

Hi,

I don't I understand why this will not work with outbound
proxies. If you have a firewall that can handle SIP that
firewall will need to work as a SIP proxy and thereby add
itself to the ROUTE chain. That 'proxy' also needs to be
addressable from outside the firewall how will you otherwise 
be able to call someone behind the firewall ?

/Bertil 

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 09:17:46 -0600

Bertil Engelholm ([email-masked]):

> Billy Biggs wrote:
> > 
> >   The only open issue is whether to allow non-SIP URIs in the Route.
> > In order to support them, the suggestion is to define Record-Route
> > parameters to indicate the IP address, port, and transport.  I
> > think this is dangerous because it won't work with outbound
> > proxies.
> 
> I don't I understand why this will not work with outbound proxies. If
> you have a firewall that can handle SIP that firewall will need to
> work as a SIP proxy and thereby add itself to the ROUTE chain. That
> 'proxy' also needs to be addressable from outside the firewall how
> will you otherwise be able to call someone behind the firewall ?

  Proxies don't need to add themselves to the Route.  So, say I buy a
SIP phone and I set its outbound proxy to be some SIP proxy on the
Internet which doesn't add itself to the route, and then some bozo puts
as the first Record-Route:

  R-R: <tel:54321>;sendto=12.43.52.23:5060;transport=udp

  What can I do?  The phone has to send the request to its outbound
proxy.  You get the same problem if you configure a SIP proxy to forward
all requests it gets to another proxy: you can't convey these parameters
in the request-URI.

  This shows why its too brittle to allow non-SIP URIs in the Route,
unless you force every proxy to know how to route based on tel: or http:
URIs... ;-)

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 09:23:01 -0600

Jo Hornsby ([email-masked]):

> I'd like to take this oppurtunity &:) to point out that the solution I
> proposed -- just inserting the SIP URL of the proxy, and embedding the
> Request-URI as a parameter thereof -- handles non-SIP URIs.

  Right, but this is a special case of not allowing SIP URIs.  If you're
a proxy that needs (for its state information or whatever) to know the
orignal request-URI it saw, then of course, throw it as a parameter.
But many (most? if not all?) proxies won't need this state to perform
their job.  Please see my post on this:

> mangling in the reverse direction, [...]

  In my opinion, this increases the complexity for little gain.

  Basically, you're just proposing that we don't allow non-SIP URIs in
the Route, and I think this is completely reasonable.

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 20 Nov 2000 15:40:02 -0000

>   http://lists.bell-labs.com/pipermail/sip/2000q4/004005.html

Right.  So we're saying remove the bit where the bis specifies
that the Request-URI is copied into the Record-Route, and
instead note that the proxy is free to put any SIP URL in (of
course, it should be routable); and also remove the bit where
the bis specifies the Route Request-URI mangling by the called
UA.

>   In my opinion, this increases the complexity for little gain.

I certainly wouldn't argue this point.  It's just an option, if
someone feels they really need it.

> the Route, and I think this is completely reasonable.

Agreed.  After all, we already say that a proxy is not allowed
to mandate TCP (via the transport parameter) in Record-Route;
allowing non-SIP URIs, I would say, is orders of magnitude more
painful.

Cheers,

 - Jo.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 09:55:59 -0600

Jo Hornsby ([email-masked]):

> Right.  So we're saying remove the bit where the bis specifies that
> the Request-URI is copied into the Record-Route, and instead note that
> the proxy is free to put any SIP URL in (of course, it should be
> routable); and also remove the bit where the bis specifies the Route
> Request-URI mangling by the called UA.

  Totally.  It should put in some SIP URI that is routable in both
directions.

> >   Basically, you're just proposing that we don't allow non-SIP URIs
> > in the Route, and I think this is completely reasonable.
> 
> Agreed.  After all, we already say that a proxy is not allowed to
> mandate TCP (via the transport parameter) in Record-Route; allowing
> non-SIP URIs, I would say, is orders of magnitude more painful.

  Dude, you rock my world.

  Now, where's Sean Olson's argument? :)

---

From: David Shrader <[email-masked]>
Date: Mon, 20 Nov 2000 23:59:00 -0500

Where do we stand on which server removes the Route header? If I recall, the
current spec says that the preceding server remotes the route header for the
next destination. OTOH, I also saw posts suggesting that the server remove
its own Route header (like the Via header).

David

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]
http://www.EyeForTheFuture.com

> From: Billy Biggs <[email-masked]>
> Date: Mon, 20 Nov 2000 09:55:59 -0600
> To: Jo Hornsby <[email-masked]>
> Cc: Sean Olson <[email-masked]>, "Fairlie-Cuninghame, Robert"
> <[email-masked]>, SIP List <[email-masked]>
> Subject: Re: [SIP] Record-Route consensus
>

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 23:43:55 -0600

David Shrader ([email-masked]):

> Where do we stand on which server removes the Route header? If I
> recall, the current spec says that the preceding server remotes the
> route header for the next destination. OTOH, I also saw posts
> suggesting that the server remove its own Route header (like the Via
> header).

  I don't recall that thread, but I can't see how it would help
anything, and it would definitely break all existing implementations.