Subject: [SIP] RECORD-ROUTE/ROUTE requirements

From: Bertil Engelholm <[email-masked]>
Date: Wed, 29 Nov 2000 13:48:57 +0100

This discussion seems endless 8-). 

There are a lot of implementation details discussed.
What I wonder is what the requirements are on ROUTE
RECORD-ROUTE. What's the "really" purpose with these 
headers ? What do they have to support ?

If we can agree on the requirements for these
headers maybe it's easier to find the best way
to "implement" this in the specification ?

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. 

The first requirement on ROUTE is that it has to include 
an address so that a SIP server (or client) can send the
next request to the correct server. The first issue I
see is how specific this address should be ? 

Should it specify a specific host (like maddr in a
SIP-URL) or is it enough to find one of the hosts
in the server and then it's up to the implementation
of that server to find the right host for this call ?

The way I see it is that this is implementation
dependent. It's up to each server implementation to
decide how specific the address is that it puts into
RECORD-ROUTE/ROUTE. So depending on how robust a 
server wants to be it might implement this in 
different ways. Should the specification require
a certain robustness in a server ?

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.

A similar issue is transport. Should it be possible to
have different transport types in the two directions ?
If a proxy is doing transport conversion I think it
would be nice if you can specify the different types
dependent on direction of the request.

    ----     ----     ----     ----  
---| P1 |---| P2 |---| P3 |---| P4 |---
    ----     ----     ----     ----  

What I mean by this is that if P3 uses UDP towards P2 
and TCP towards P4 maybe it wants to tell P2 and P4
what they should use in the next request. Of course
P2 and P4 could remember this but if e.g. P2 does
not RECORD-ROUTE P1 will not know what transport to 
use towards P3 unless this is said in ROUTE.

Another issue is identification. A server have to be
able to put some identification in RECORD-ROUTE/ROUTE
so that when the next request arrives it can find which
call states to use for this request. Certain server
implementations maybe find it more optimal to put
the state information in the message instead of an
identifier. So I beleave both possibilities needs to
be supported.

Have I forgot something ??

So from this reasoning I draw the conclusion that a
server needs the possibility to put in an address 
(host + port), a transport and an identification/state 
in RECORD-ROUTE/ROUTE. Since the address and transport
part have to be used by other servers (clients) this
information have to be detailed specified in the SIP
specification so that each server knows where to find
these parts. 
How the identification/state part looks like is 
implementation dependent and does not need to be 
as detailed as the other parts. It only need to be so
detailed so that the identification/state part can be 
sent to the next server by the previous server in the 
ROUTE chain. How a server use this part is up to each 
server and don't need to be specified (maybe as examples).  

So if I now go down to details I see different ways of
"implementing" the "requirements" in the specification.

I think I can atleast say that the identification part
MUST be a URI since it's going to be sent to the next
server as a request URI. But what a server have put
into the URI is up to him. 

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.

The possibility to have different portnumbers and/or
transport in the two directions I beleave can be solved
as Jonathan described. _IF_ a server wants to use different
address (port) or transport in the two directions it has
to modify it's own RECORD-ROUTE when the response is sent
back. Since this can be done already today I wonder if
the specification needs to say much about this (maybe as
examples). However I see a risk in this behaviour and that
is that a server might modify the wrong RECORD-ROUTE by
mistake and it will be very tricky to find which server
it was that did the modification unless you have logs
from all servers.

That's all for now folks. Maybe someone should set up
a discussion about this during the bakeoff ??

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

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 29 Nov 2000 14:44:25 -0000

> This discussion seems endless 8-). 

Indeed.  And there I was hoping that we would have this
sorted for the Bake-Off.  Oh well.

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

> see is how specific this address should be ? 

It MUST be specific enough such that 1.4.2 lookup
procedures _and nothing else_ will resolve to that same
(or similar in a farm, or whatever) proxy.

> different port numbers it should have the possibility

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.

> have different transport types in the two directions ?

No, it MUST be UDP.

> identifier. So I beleave both possibilities needs to

Indeed.  But one by no means rules out the other.

> Have I forgot something ??

No, I think you got it pretty much covered. &:)

> it directly. Instead it has to convert it into a SIP-URL 

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.

Cheers,

 - Jo.