Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 29 Nov 2000 22:27:53 -0800

Comments below.

> 
> > This discussion seems endless 8-). 
> 
> Indeed.  And there I was hoping that we would have this
> sorted for the Bake-Off.  Oh well.
> 

I still think we can have a proposal before the bake-off [and unfotunately I
can't make the bake-off]. At least that gives a starting point.

> > The main purpose with RECORD-ROUTE/ROUTE as I 
> > understand it is that a server can make shure it will 
> > get all new requests for a certain call-leg by adding 
> > a RECORD-ROUTE to the first (and consequtive) request. 
> 
> Exactly.  And that is why I think we should mandate (i.e.,
> MUST) that it is a SIP URL with either no transport
> parameter, or a transport parameter that matches /UDP/i.
> If these conditions are not met, then we cannot guarantee
> that a client will be able to route successfully.
> 
> As an analogy, consider the fact that UDP is a MUST.
> I wouldn't be surprised if someone writes something that
> doesn't do UDP, because TLS is essential (for some reason).
> Now they can't expect to be able to interoperate, but
> doubtless that won't matter, since the parameters of
> the network this non-UDP-supporting-something is going
> to be running in will ensure that it can interoperate
> with whatever it needs to.
> 
> In the same way, someone might one day insert a non-SIP
> URI into a Record-Route, but they can't expect it to
> work unless they know that the devices in the network
> are controlled such that they'll understand this non-SIP
> URI.
> 
Yes! yes! yes! I agree entirely. 

> > The next issue I see is port number. Today you have 
> > to use the same port number from both caller and callee
> > because the same ROUTE is used in both directions.
> > Should it be possible to use different port numbers ?
> > I would say yes to this. If a server wants to have
> > different port numbers it should have the possibility
> > to do so.
> 
> Well, if a proxy is prepared to modify the Record-Route
> in the response, then it is free to expose a different
> port to callee/caller.
> 
Right, its all up to the proxy as to what it puts in there. We just have to
say what is the minimum that it should put in there.

> > The more controversial parts I guess is the address 
> > and the transport. Should they be RECORD-ROUTE/ROUTE 
> > parameters or URI parameters ? Personally I prefere
> > RECORD-ROUTE/ROUTE parameters because that means I
> > don't have to look inside the ROUTE-URI and that makes 
> > me more future proof towards possibly new types of URIs. 
> >
> > The other possibility that has been discussed is to
> > only allow SIP-URL as URI in ROUTE and put the address 
> > in there as today (maddr). I don't like this solution 
> > because if a new type of URI pops up in the future that 
> > a server needs to put in as identification it can't do
> > it directly. Instead it has to convert it into a SIP-URL 
> > in some way.
> 
> If a proxy needs to embed exotic URIs (or whatever) in
> Record-Route, then I think it should have to suffer all
> the pain involved.
> 
> If we use anything other than UDP SIP URLs, I can't see
> how we can guarantee interoperability.
> 
Exactly. I think this is more a matter of confusion than controversy. Bertil
said:

> > The more controversial parts I guess is the address 
> > and the transport.

So a SIP URL is adquate for all host based networks and UDP transport is
required - so why make life hard. Just because _the original_ call routing
is done on mailto, tel or whatever esoteric URI scheme doesn't impact the
fact that a Route header MUST be sent to the specified UDP reachable host.

As you say Jo, if someone wants to use non-SIP Route URL's that's fine but
you can't guarantee interoperability so it should not be put in the SIP
spec.

Ok so as I see it:

-Record-Route headers must be SIP URL's. 
-The address in the SIP URL must be the UDP reachable address of the proxy
inserting the route.
-The username and any parameters added to the URL to the header are
implementation defined. 
-The Record-Route should use angle brackets. 
Ie, Record-Route: <xxxxx@proxyaddress:port;yyyyy=yyyyy>;zzzzz=zzzzz
where y are the implementation defined Record-Route URL parameters and zzzz
are the implementation defined Record-Route header parameters. xxxxx may be
empty.
-If multiple Record-Routes are added for the same request (ie, spiral
route), then each Record-Route added SHOULD be different so that they can be
distinguished.
-In the response to a Record-Route'd request, a proxy MAY change any
Record-Route header that the it originally generated. 
- A UAS must copy the Record-Route unchanged into the Route header; a UAC
must copy the Record-Route unchanged into the Route header, reversing the
order. A Route header is added if a Contact is added (as before). 
- If a proxy inserts Record-Route header into a request without Contact or
Record-Route headers, then the Proxy SHOULD insert a Contact into the
request with the From URL information and a maddr of the source address.
[This ia KISS option. Contacts are now mandatory and so this is only
required for supporting older UA's and why don't we keep the proxy behaviour
as simple as possible. Can anyone see any reasons why this would cause
problems?]
- If a proxy receives a response to a request in which it added a
Record-Route header AND the request does not contain a COntact header AND no
new headers have been added by other proxies (ie is last Record-Route), then
the proxy SHOULD add a Contact header field to the response with the
original Request-URI and an additional maddr parameter with the forward
address (to replicate the original routing action).
[This ia KISS option. Contacts are now mandatory and so this is only
required for supporting older UA's and why don't we keep the proxy behaviour
as simple as possible (please!!). Can anyone see any reasons why this would
cause problems?]

In my mind, this allows the proxy the most freedom of how much information
is placed in the Record-Route and how to encode it. The backwards compat
case where there is no Contact added is handled in the simplest way possible
that should give a good chance of success. 

Jonathan, do you still want to argue for more stringent restrictions that
the username cannot be empty and that the proxy MUST change the Record-Route
in the response ?

Comments or omissions?

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 30 Nov 2000 10:34:51 -0000

Robert wrote:
> So a SIP URL is adquate for all host based networks and UDP
> transport is required - so why make life hard. Just because
> _the original_ call routing is done on mailto, tel or whatever
> esoteric URI scheme doesn't impact the fact that a Route
> header MUST be sent to the specified UDP reachable host.

Very much so.

> As you say Jo, if someone wants to use non-SIP Route URL's
> that's fine but you can't guarantee interoperability so it
> should not be put in the SIP spec.

Indeed.

> -The address in the SIP URL must be the UDP reachable address
> of the proxy inserting the route.
> -The username and any parameters added to the URL to the header
> are implementation defined. 
> where y are the implementation defined Record-Route URL 
> parameters and zzzz are the implementation defined Record-Route
> header parameters. xxxxx may be empty.

(as may be yyyyy / zzzzz)

> -If multiple Record-Routes are added for the same request
> (ie, spiral route), then each Record-Route added SHOULD be
> different so that they can be distinguished.
> -In the response to a Record-Route'd request, a proxy MAY
> change any Record-Route header that the it originally
> generated. 
> - A UAS must copy the Record-Route unchanged into the Route
> header; a UAC must copy the Record-Route unchanged into the
> Route header, reversing the order. A Route header is added
> if a Contact is added (as before).

No arguments here. &:)

> - If a proxy inserts Record-Route header into a request
> without Contact or Record-Route headers, then the Proxy SHOULD
> insert a Contact into the request with the From URL information
> and a maddr of the source address.  [This ia KISS option.
> Contacts are now mandatory and so this is only required for
> supporting older UA's and why don't we keep the proxy behaviour
> as simple as possible. Can anyone see any reasons why this
> would cause problems?]
> - If a proxy receives a response to a request in which it
> added a Record-Route header AND the request does not contain
> a COntact header AND no new headers have been added by other
> proxies (ie is last Record-Route), then the proxy SHOULD add
> a Contact header field to the response with the original
> Request-URI and an additional maddr parameter with the forward
> [This ia KISS option. Contacts are now mandatory and so this
> is only required for supporting older UA's and why don't we
> keep the proxy behaviour as simple as possible (please!!).
> Can anyone see any reasons why this would cause problems?]

I don't think that proxies should start second-guessing UAS.
I would say that the simplest thing is just to say that when the
UA is building the Route header list, it should append the
Contact, if present; failing that, the From.

Really old UAs might lose, but they were always going to do
that, anyway[0].

Cheers,

 - Jo.

[0] I'm obviously a bis snob.