Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus)

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2000 17:52:34 -0500

Before we begin writing new text, lets look at the sub-problems and build up
a solution. I have another possibility that may be the best of all worlds.
I'll start with Roberts list:

1. non SIP URLs in request URI

We can either define record-route parameters, or else make sure that the URL
put into the record route is a sip url. I originally propose RR parameters,
but I think insisting on a SIP URL is backwards compatible and more
reasonable. That seems to be consensus.

2. transaction ID in the reverse direction

This was the problem that if there was a spiral in the forward direction,
and the current bis approach was used by the UAS to construct the Route
header, a request would arrive twice at the spiraled-at proxy. These could
be identified as separate transactions (as a result of Via header
differences), but there is no way to determine which of the two iterations
through it is. 

The solution is that the request URI need some info that the proxy created
and is returned to it. There seems to be little disagreement on that.

3. Proxy doesn't see URI parameters it inserted in RR, returned to it in
request URI

This is a consequence of the current bis text for building the route.
Proposed solution for this component is that the construction process at the
UAS has to copy the URI parameters from the RR rather than the Contact/From.

4. detecting new behavior

I don't think this is an issue, since we need a solution thats backwards
compatible.

5. (this one is my own) The request URI should refer to the resource for
whom the message is destined

The solutions proposed are either to have the UAS and UAC construct the
Route differently (as is done in the current bis), else Jo's text here where
this information is carried somehow as parameters. I think this is a big
hack, and quite a pain. When a proxy receives a re-INVITE, it will have a
hard time knowing which direction the re-INVITE is going, and consequently,
which of the pieces of info to extract for processing purposes.

Putting it all together, its clear from (1) that the record routes must
always be SIP URLs. From 2 and 3, at least the parameters placed into the RR
should be copied into the Route by both sides, and from 5, the URI should
contain information that identifies the recipient of the message, different
in both directions.

My new proposal does all of the above, and requires no mangling of RR in the
UA. Here's how it goes.

When a request arrives, and a proxy record-routes, it places a URI into the
RR which identifies the *calling UA* as a resource on this proxy. This URI
can be derived from the Contact/From, but should not be exactly equal to it.
This must be a SIP URL. THe UAS copies the RR set into the response. It also
constructs a Route header by taking the RR's in order, and adding the
Contact from the INVITE at the end. Now, here's the trick. As the response
traverses the proxies, any proxy that record-routed, finds its RR entry, and
*replaces it* with a new URI; this URI identifies the called party at this
server. Probably this is the request URI that was originally received in the
INVITE. The UAC then constructs the Route as defined in rfc2543.

Now, the result of this is that the URIs in the two Route sets are
different; they identify the actual recipient of the message, and they are
inserted by the proxy and can thus be set by the proxy. Seems to have
everything we want.

Here's an example. A calls B, through a record-routing Proxy P1. Here are
message snipits:

A->P1

INVITE sip:[email-masked]
Contact: sip:[email-masked]

P1->B
INVITE sip:[email-masked]
Contact: sip:[email-masked]
Record-Route: <sip:[email-masked]>

B->P1
200 OK 
Contact: sip:[email-masked]
Record-Route <sip:[email-masked]>

P1->B
200 OK
Contact: sip:[email-masked]
Record-Route <sip:[email-masked]>

The Route constructed by A is:

sip:[email-masked]
sip:[email-masked]

and by B:

sip:[email-masked]
sip:[email-masked]

This is similar to Jo's proposal but maintains the property that a request
from A to B has a URI that always points to a resource that gets routed to
B, and vice a versa (in Jo's case, the URI is the same in both directions).
Thus, I think it satisfies everyone. Note that maddr is no longer needed so
long as the host port gets routed back to the same server; of course it can
put maddr if it likes.

The drawback is that the proxy needs to do a bit more work. Not a lot,
though.

Comments?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 12:45 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [SIP] New Section 6.34 (was: Record-Route consensus)
> 
> 
> Okay, here's a proposal for a new Section 6.34.  Hopefully, this
> is as backwardly-compatible (to 2543) as we could possibly be
> (that is, it should work with a 2543 proxy, and it even has a
> good chance of working with a 2543 UA, if it was the one calling).
> 
> Also, this should solve using Record-Route when a proxy receives
> a request with a non-SIP Request-URI.  The changes are basically
> now that a proxy is free to put just about any URI into a
> Record-Route value, as long as it's a UDP SIP URL; and the called
> UA no-longer does the nasty mangling when copying into the Route.
> 
> Anyway, without further ado...
> 
> 
> 
> 6.34 Record-Route
> 
> 
> 6.34.1 Operation
> 
>  The Record-Route request and response header field is added to a
> request by any proxy that insists on being in the path of subsequent
> requests for the same call leg.  A proxy SHOULD add it to any request
> for robustness, but a request route, once established, persists until
> the end of the call leg, regardless of whether the Record-Route header
> is present in subsequent requests.
> 
>     Some proxies, such as those controlling firewalls or in an
>     automatic call distribution (ACD) system, need to maintain call
>     state and thus need to receive any BYE, re-INVITE and ACK packets
>     for the call.
> 
>  Each Record-Route header field contains a globally reachable SIP URL
> that identifies a proxy server.  Any proxy that wishes to remain in
> the signalling path of a call leg adds its own SIP URL to the
> beginning of the list of these fields.  This SIP URL MUST represent an
> address that is reachable via UDP.  Requests between both user agents
> involved in the call leg, in either direction, traverse this route.
> 
>     Inclusion of, say, a TCP transport parameter may prevent a UA that
>     supports only UDP but reached the proxy inserting the Record-Route
>     via another proxy from reaching this proxy.
> 
>  The UAS copies the Record-Route request header field unchanged into
> the response.  (Record-Route is only relevant for 2xx responses and
> responses where the server can expect the client to retry for the same
> Call-ID, as in 401 (Unauthorized) or 484 (Address Incomplete).)
> 
>  *** Should we remove this bit about 401 and 484?  It makes things
>      more complicated, and also what if a proxy has collected a load
>      of WWW-Authenticate and Proxy-Authenticate headers into a
>      401 (Section 12.4 of bis2) -- the Record-Route could be 
> arbitrary.
> 
> 
> 6.34.2 Construction of Route header
> 
>  If a UAC finds a list of Record-Route header fields in a final
> response to the initial request in a call leg, it copies this list
> into Route header fields of all subsequent requests within the same
> call leg, reversing the order of fields, so that the first entry is
> the server closest to the UAC.
> 
>  *** I haven't said initial INVITE here, since wasn't there 
> some talk about
>      abstracting it for, say SUBSCRIBE/NOTIFY purposes?
> 
>  If a UAS finds a list of Record-Route header fields in the initial
> request in a call leg, it copies this list, maintaining its ordering,
> into the Route header fields of all subsequent requests within the
> same call leg.
> 
>  In either case, the UA MUST copy all SIP URLs verbatim.
> 
>     This allows a proxy to add a SIP URL parameter indicating a
>     request's original Request-URI, for instance.
> 
>  If the request/response featured a Contact header field, the 
> UA Contact
> header value is appended to the list of Route header fields.  If this
> Contact header value is found to have changed in a subsequent request
> or response, then the new value MUST then be used.  Note that the same
> is not true of changes to list of Record-Route header values.
> 
>  *** If no Contact, should add the From?
> 
> 
> 6.34.3 Request Destination
> 
> If a client finds a list of Route header fields in a request, it
> SHOULD send the request to the first SIP URL in the list.  A client
> MAY forward the request to a designated proxy instead, for example, if
> it lacks DNS resolution capability.  If a client uses the first Route
> entry to route the request, it removes it.
> 
> 
> 6.34.4 Syntax
> 
> The Record-Route header field has the following syntax:
> 
>     Record-Route = "Record-Route" ":" 1#(name-addr *(";" rr-param))
>         rr-param = generic-param
> 
> 
> 6.34.5 Example
> 
> Example for a request where the proxy servers at vanity-domain.com,
> ieee.org, and sunnydale-high.edu, in that order, insist on being part
> of subsequent request paths:
> 
>     Record-Route: <sip:[email-masked]>
>       <sip:ieee.org;uri=sip:[email-masked]>
>       <sip:sip.vanity-domain.com:6000;uri=tel:+1-972-555-2222>
> 
>  *** I took the liberty of making the example Record-Route slightly
>      more exotic. &;)
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Billy Biggs <[email-masked]>
Date: Wed, 22 Nov 2000 17:09:47 -0600

Jonathan Rosenberg ([email-masked]):

> 5. (this one is my own) The request URI should refer to the resource
> for whom the message is destined
> 
> The solutions proposed are either to have the UAS and UAC construct
> the Route differently (as is done in the current bis), else Jo's text
> here where this information is carried somehow as parameters. I think
> this is a big hack, and quite a pain. When a proxy receives a
> re-INVITE, it will have a hard time knowing which direction the
> re-INVITE is going, and consequently, which of the pieces of info to
> extract for processing purposes.

  The proxy should look at the To and the From to tell direction,
instead of doing this ugly hack! [1]

  The only note then is that if a UA calls itself through a
Record-Route'ing outbound proxy, then the tags it inserts had better be
different.  [I think you've heard that argument before!]

  Still, bis shouldn't talk about any of this.  Keep the spec really
simple, and let proxies which need to keep state figure out how to
record-route to their advantage.  Jo's text is pretty much on the mark.

 [1]  Or, it can always just look at which address is at the end of the
      Route...  Regardless, your suggestion is an ugly hack.

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

---

From: Billy Biggs <[email-masked]>
Date: Wed, 22 Nov 2000 17:16:20 -0600

> instead of doing this ugly hack! [1]

  To clarify myself, I refer to Jonathan's hack of having the proxy
mangle the Record-Route in the response which comes back.

  I should have quoted his message better.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 23 Nov 2000 10:23:01 -0000

Jonathan Rosenberg wrote:
>
> Before we begin writing new text,

Ah, but I finally got you to bite. &;)

> else Jo's text here where this information is carried somehow as
> parameters. I think this is a big hack, and quite a pain.

I feel this is a little unfair; ultimately, I specified very
little about the Request-URI that the proxy inserted, beyond
it being a globally reachable address for the proxy.  It was
only a motivational item and the examples at the end that
suggested using a parameter to indicate the original
Request-URI.

> When a proxy receives a re-INVITE, it will have a hard time
> knowing which direction the re-INVITE is going, and
> consequently, which of the pieces of info to extract for
> processing purposes.

As Billy pointed out, making this determination isn't too
difficult.

> When a request arrives, and a proxy record-routes, it places a 
> URI into the RR which identifies the *calling UA* as a resource
> on this proxy. This URI can be derived from the Contact/From,
> but should not be exactly equal to it.  This must be a SIP URL.
> THe UAS copies the RR set into the response. It also constructs
> a Route header by taking the RR's in order, and adding the
> Contact from the INVITE at the end. Now, here's the trick. As
> the response traverses the proxies, any proxy that record-routed,
> finds its RR entry, and *replaces it* with a new URI; this URI
> identifies the called party at this server. Probably this is
> the request URI that was originally received in the INVITE.
> The UAC then constructs the Route as defined in rfc2543.

Very nice -- it's cool that you've found a way to maintain
"the Request-URI points to the ultimate destination" as an
invariant.

So instead of:

how about:

  Each Record-Route header field contains a globally reachable SIP URL
 that identifies a proxy server.  Any proxy that wishes to remain in
 the signalling path of a call leg adds its own SIP URL to the
 beginning of the list of these fields in a request.  This SIP URL
 MUST represent an address that is reachable via UDP, and SHOULD
 represent the calling UA (i.e., be derived from the Contact/From).
 In addition, a proxy SHOULD modify its URL in the corresponding
 response(s) to reflect the called UA (i.e., be derived from the
 original Request-URI).  Requests between both user agents
 involved in the call leg, in either direction, traverse this route.

could also perhaps add some motivational text indicating how this
behaviour helps to maintain the Request-URI semantic invariant.

> >      401 (Section 12.4 of bis2) -- the Record-Route could be 
[and]
> >      some talk about abstracting it for, say SUBSCRIBE/NOTIFY
> >      purposes?
[and]
> >  *** If no Contact, should add the From?

Now that we've got the overall operation sorted out &:), does
anybody have anything to contribute with regards to these
points?  Please? &:)

Cheers,

 - Jo.

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 23 Nov 2000 16:21:08 +0100

> INVITE. The UAC then constructs the Route as defined in rfc2543.

Like Robert I struggle with this RR URI which "identifies the
[caller/callee] as a resource on this proxy". In the typical case only
one of the two parties would be known in any meaningful way to the
proxy.  The proxy record-routes using its own SIP URL and can derive a
user name from the caller/callee but they won't necessraily mean
anything to it, and it wouldn't necessarily be able to route messages on
it (and it won't have to - that's what the Route is for). This means [5]
isn't really satisfied anyway.

> ...

Well, until now proxies just had to pop the top Via and forward the
response, with this proposal they have to decode some or all
Record-Route headers, figure out which one it generated itself and
modify it.

It might be tempting for proxy writers NOT to put a user part into its
own Record-Route headers to begin with. That way there's less work on
the return path and routing works exactly the same.  Alternatively, as
has also been suggested, proxies can put whatever private state they
like in there and just consider it a piece of state which identifies the
call to that proxy.

It seems to me that Jonathans and Jo's proposals degenerate to the same
approach: always use SIP URLs in Record-Route and not make any
assumptions what goes into the user part.

Anders

---

From: Sean Olson <[email-masked]>
Date: Sun, 26 Nov 2000 10:22:54 +0100

> reasonable. That seems to be consensus.

Please do not make this mistake. If we don't require a SIP URL in the
Request-URI,
the From,  the To, or even the Contact, then why mandate it in the
Record-Route:?

--
Sean Olson <[email-masked]>

---

From: Billy Biggs <[email-masked]>
Date: Mon, 27 Nov 2000 00:15:09 -0600

Sean Olson ([email-masked]):

> > We can either define record-route parameters, or else make sure that
> > the URL put into the record route is a sip url. I originally propose
> > RR parameters, but I think insisting on a SIP URL is backwards
> > compatible and more reasonable. That seems to be consensus.
> 
> Request-URI, the From,  the To, or even the Contact, then why mandate
> it in the Record-Route:?

  Do you want Record-Route and Contact header parameters indicating the
IP address and port to send the request?

  I don't mind non-SIP URLs, but I do mind new parameters: they just
provide a false sense of security that things will magically work.  If
you put a non-SIP URL in the Contact or Record-Route or Request-URI, you
had better know for sure that whomever is going to process the message
knows how to forward it on its own.

  Non-SIP URLs in the To/From don't matter because Contact is now
mandatory pretty much everywhere.  You don't need to look at the From to
route messages.

---

From: Sean Olson <[email-masked]>
Date: Mon, 27 Nov 2000 09:23:34 +0100

> IP address and port to send the request?

I would be happy with that.

> knows how to forward it on its own.

Hmmm. Sort of like using a non-SIP URL in say, the To/From/Contact ...
If we can't use parameters for things like this, then why do we have
parameters
at all??? (I mean parameters on the RR)

> mandatory pretty much everywhere.  You don't need to look at the From to

But the To/From is there for a reason. At a transaction level, I am all for
treating them as opaque strings. Higher up in the application strata,
these should have some meaning besides just strings -- at least there
should be the possibility for these to have meaning.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 27 Nov 2000 10:14:58 -0600

Sean Olson ([email-masked]):

>>   Do you want Record-Route and Contact header parameters indicating
>> the IP address and port to send the request?
> 
>> provide a false sense of security that things will magically work.
>> If you put a non-SIP URL in the Contact or Record-Route or
>> Request-URI, you had better know for sure that whomever is going to
>> process the message knows how to forward it on its own.
> 
> parameters at all??? (I mean parameters on the RR)

  Sorry, let me be more specific.  Say I use a non-SIP URI in the RR (or
Contact) of:

  <tel:911>;raddr=udp/22.33.44.55:5060

  My only choice for request-URI is "tel:911", but this does not convey
the destination of the request.  Since you now can't route based on
request-URI, you can't use an outbound proxy, stuff breaks in general.

  Now, what if I have a cluster of proxies which all route messages
internally using tel URIs.  I have no problem with this, and placing
these non-SIP URIs in the RR totally makes sense.  But I see two issues:

  1. Should the spec instruct UAs to copy RR parameters into the Route,
     so that the raddr can be useful within this cluster?

     I think yes, definitely.  This is cheap and useful.

  2. Should we standardize an raddr RR parameter and allow this to be
     used for SIP URIs?

     I say no.  In general this technique breaks with outbound proxies
     or transparent proxies.  If necessary, this could be standardized
     outside of the SIP spec.

  I got the impression earlier that you were looking for point 2 to be
in the spec.

>> mandatory pretty much everywhere.  You don't need to look at the
>> From to route messages.
> 
> But the To/From is there for a reason. At a transaction level, I am
> all for treating them as opaque strings. Higher up in the application
> strata, these should have some meaning besides just strings -- at
> least there should be the possibility for these to have meaning.

  Totally, but a client should know to convert a tel URI to a SIP URI
like phonenumber@gateway.  I thought that was the point of them, not to
use them as a Request-URI.

---

From: Sean Olson <[email-masked]>
Date: Mon, 27 Nov 2000 11:00:14 +0100

> request-URI, you can't use an outbound proxy, stuff breaks in general.

Why doesn't the outbound proxy RR?

>      I think yes, definitely.  This is cheap and useful.

Agreed

>      or transparent proxies.  If necessary, this could be standardized

Standardizing this as an extension doesn't really help. I'm curious
why transparent proxies would be in the signalling path.  Outbound
proxies should RR (am I missing something here?)

>   I got the impression earlier that you were looking for point 2 to be

That was my intention.

> use them as a Request-URI.

In this specific case, it may or may not be possible for the UAC to
translate the
tel: URI into a SIP URI. (How does the client know which "domain" owns a
specific
number?) This is where an outbound proxy may play a role. In any case, it
may
be useful in certain cases to use a Request-URI which is not directly
routable.
A proxy downstream can translate this into a Request-URI which is routable.
I see no good reason to make an arbitrary limitation of the RR to SIP URLs.
Is there an intractable problem here that I am missing? It is Monday after
all :)

---

From: Billy Biggs <[email-masked]>
Date: Mon, 27 Nov 2000 11:28:50 -0600

Sean Olson ([email-masked]):

>>   Sorry, let me be more specific.  Say I use a non-SIP URI in the RR
>> (or Contact) of:
>>
>>   My only choice for request-URI is "tel:911", but this does not
>> convey the destination of the request.  Since you now can't route
>> based on request-URI, you can't use an outbound proxy, stuff breaks
>> in general.
> 

  It does, but what if you call me directly and not through my outbound
proxy?  The INVITE transaction completes without my outbound proxy being
placed in the Route.  When I send a BYE or whatever, it will go to the
outbound proxy, and now your URI loses its significance.

  That's very brittle.

>>   2. Should we standardize an raddr RR parameter and allow this to
>>      be used for SIP URIs?
>>
>>      I say no.  In general this technique breaks with outbound
>>      proxies or transparent proxies.  If necessary, this could be
>>      standardized outside of the SIP spec.
> 

  Transparent proxies are useful when you want to divert SIP requests
going out to the internet to go to a special firewall proxy.  This is
common with HTTP.

  SIP and HTTP are elegant in their proxy-awareness.  Messages can be
forwarded between proxies without information loss.  However, with an
raddr or whatever, now the IP layer has significance to the meaning of
the message, which breaks the model.

>>   [...] but a client should know to convert a tel URI to a SIP URI
>> like phonenumber@gateway.  I thought that was the point of them,
>> not to use them as a Request-URI.
> 
> translate the tel: URI into a SIP URI. (How does the client know which
> "domain" owns a specific number?) This is where an outbound proxy may
> play a role. In any case, it may be useful in certain cases to use a
> Request-URI which is not directly routable.  A proxy downstream can
> translate this into a Request-URI which is routable.  [...]

  But now the client and the outbound proxy are together acting as a
single logical client.  This technique, translating a tel: URI into a
SIP URI, can only be done at the edges, and does not work unless you are
sure you are not going to hit some transparent proxy in the middle.

  My point is that URI schemes other than SIP are useful for internal
purposes.