Subject: [SIP] Record-Route and maddr

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 20 Jul 2000 18:55:53 -0400

Let us say proxy "proxy.domain.com" listening at port 5060 receives
this request :

INVITE sip:[email-masked] SIP/2.0

and it introduces a Record-Route header.
My question is should the Record-Route look like :

<sip:[email-masked]:5060;maddr=proxy.domain.com>

or 

<sip:proxy.domain.com:5060>

On a related note, what should proxies do with maddr parameter in
the incoming request-URI ( the request may or may not have a Route).

My third question is about the following statement in section 4.3

"The host portion of the Request-URI typically agrees with one of 
the host names of the receiving server. If it does not the proxy
SHOULD proxy the request to the address indicated or return a 404..."

As per the above statement, if the proxy "proxy.domain.com" at port
5060 gets the following request :

INVITE sip:[email-masked]:5055 SIP/2.0

it would try to lookup user abc instead of forwarding the request
on the local machine to port 5055. Is it okay to do this ??

-- 
Best regards,
Shail

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Jul 2000 01:07:45 -0400

> <sip:proxy.domain.com:5060>

Actually, neither. Its:

i.e., you *copy* the request URI into the record-route, and add your own
address into the port, maddr, transport parameters.

> the incoming request-URI ( the request may or may not have a Route).

If the domain in the request URI is your own, and you are using some
kind of location service to translate the address, you do nothing with
it. If, however, you are a local outbound proxy, and you are simply
forwarding to the server listed in the request URI, you will send it to
the server at the maddr.

See:
http://www.cs.columbia.edu/~hgs/sip/faq/cache/62.html

> on the local machine to port 5055. Is it okay to do this ??

Sure. Routing is your own decision. 

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 21 Jul 2000 10:21:32 +0100

> <sip:proxy.domain.com:5060>

I think the former.

> the incoming request-URI ( the request may or may not have a Route).

Going on Section 1.4.2 (steps 1, 2, 7) in the bis, it should send
it to the IP corresponding to the maddr parameter, and figure the
port based on the paragraph immediately proceeding these steps.

(As a side note: is it really the intention that port numbers in
SRV records should override an _explicitly_ specified port number
in a Request-URI?  This seems a little odd.  For example, say
I wanted to run a test server on an obscure port on some machine
that was running a live server; how would I get a conforming UAC
to talk to the right server?)

> on the local machine to port 5055. Is it okay to do this ??

Basically, it's okay to do anything. &:)

I would say that's completely fine; it's odd (see my parenthesised
rant above), but if that's what policy dictates...

HTH,

 - Jo.

---

From: Neil Deason <[email-masked]>
Date: Fri, 21 Jul 2000 11:58:22 +0100

> <sip:[email-masked]:5060;maddr=proxy.domain.com>

This is exactly the same as the first suggestion?? 

> address into the port, maddr, transport parameters.

I thought that proxies MUST include the maddr param 
in the URI of the Record-Route header, but MUST NOT
include a transport param. (Section 6.35.1) 

Is a proxy also supposed to write it's port number 
into the Request-URI if it is not 5060? This isn't 
clear to me in the spec but seems necessary for 
clients to know where to send to later on.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK

---

From: Shail Bhatnagar <[email-masked]>
Date: Fri, 21 Jul 2000 11:08:36 -0400

> to talk to the right server?)

I thought that if there is an explicit port in the SIP URL, then 
type "A" query should be done, otherwise type "SRV" query.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Jul 2000 12:16:26 -0400

> This is exactly the same as the first suggestion??

Wow. Talk about caffeine deprivation. Sorry about that.

> include a transport param. (Section 6.35.1)

Forgot about that one as well. Thats a result of the recent discussions
on UDP in one side, TCP on the other. Thanks.

> clients to know where to send to later on.

If you put an IP address into the maddr parameter, yes, the port number
will need to be there if its not 5060. If you put a domain name, you
will not need it if you wish to rely on SRV records. If you are relying
on A records, again, you'll need it there. Record-routing with domain
names that point to SRV records can be both good and bad. If may cause
subsequent requests to go to a different server. Good for failover, bad
if you don't have state replication mechanisms in the back end between
servers.

> type "A" query should be done, otherwise type "SRV" query.

Correct.

-Jonathan R.

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 21 Jul 2000 17:37:54 +0100

> > type "A" query should be done, otherwise type "SRV" query.

Okay, I think I finally get it. &:)

> If you put an IP address into the maddr parameter, yes, the port
> number will need to be there if its not 5060. If you put a domain
> name, you will not need it if you wish to rely on SRV records. If
> you are relying on A records, again, you'll need it there.
> Record-routing with domain names that point to SRV records can be
> both good and bad. If may cause subsequent requests to go to a
> different server. Good for failover, bad if you don't have
> state replication mechanisms in the back end between servers.

Is it possible to rely on SRV _at all_ with Record-Route, though,
since the maddr parameter is a MUST?

As far as I can tell from 1.4.2, the maddr is either going to be
an IP or a host name; if it's the latter, then clients perform
an A (or AAAA, or whatever) lookup...

Cheers,

 - Jo.

---

From: Neil Deason <[email-masked]>
Date: Fri, 21 Jul 2000 17:38:45 +0100

> if you don't have state replication mechanisms in the back end between

What about on reverse request paths where components other 
than the maddr param are taken from the originating name-addr 
value (i.e. Contact header or From header if there is no 
Contact). In this case isn't any port info placed in the 
Request-URI by a proxy wanting to be on the route lost.

Cheers,
Neil.
http://www.ubiquity.net

---

From: Shail Bhatnagar <[email-masked]>
Date: Fri, 21 Jul 2000 13:36:15 -0400

> forwarding to the server listed in the request URI, you will send it to

I think this will not work with Record-Route,since the host portion
of the SIPURL would be entirely different from the maddr parameter
of the Request-URI ( actually I think a proxy will see its address
in the maddr parameter of the incoming Request-URI, but the host
portion of the SIP URL could be anything.)

Comments ??

> http://www.cs.columbia.edu/~hgs/sip/faq/cache/62.html

From the bis version of the spec :

"The transport, maddr and ttl parameters MUST NOT be used in the From/
To headers fields and the Request-URI, they are ignored if present."

This needs to be changed ??

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jul 2000 02:23:10 -0400

> portion of the SIP URL could be anything.)

This rule above is only in the case where there is no Route header. If
there is a Route header, you always send the request to the IP address
in the maddr of the Route, if present, otherwise, the IP address
resulting from looking up the domain portion of the URI in the Route.

So, it works fine.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jul 2000 02:23:50 -0400

> Request-URI by a proxy wanting to be on the route lost.

I can't seem to parse this response. Can you rephrase?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jul 2000 02:24:44 -0400

> since the maddr parameter is a MUST?

Yes, as I said, since the maddr itself can contain a domain name.

> an A (or AAAA, or whatever) lookup...

and in the former, an SRV lookup.

-Jonathan R.

---

From: Neil Deason <[email-masked]>
Date: Mon, 24 Jul 2000 09:37:03 +0100

> and in the former, an SRV lookup.

I thought that if the maddr is the former, i.e. an IP address,
the client is going to contact the server directly at that given
address. If it is a host name the client queries the DNS server
for address records (A RR's, AAAA RR's) for the host portion of
the maddr. Therefore no lookup for SRV records for a SIP server
is done in Record-Routing.

Cheers,
Neil.

---

From: Neil Deason <[email-masked]>
Date: Mon, 24 Jul 2000 11:05:04 +0100

> I can't seem to parse this response. Can you rephrase?

I was thinking about the possible effect of a proxy server
relying on the mechanism of writing it's port number, if it is
not 5060, in the Request-URI. In the case of reverse request
paths wont this be useless? According to Section 6.35.2 ...

"Since the URIs contained in the Record-Route are not useful for
the reverse request path, the UA fills all other components of
the Route name-addr value with the originating name-addr value.
The originating name-addr value is the name-addr value found in
the Contact header of the request or the From header field, if
there is no Contact header field."

If the Contact header, or potentially the From, contain a port
number different to that which the proxy is listening on the
request will be lost.

Cheers,
Neil

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jul 2000 02:36:44 -0400

> is done in Record-Routing.

Right. I misread the order here and also did not realize that the draft
specification
says to use only A records if maddr contains a domain name. I'm not sure
why
this is there, actually. I guess its to make sure that subsequent
requests for the
same call go through exactly the same server. But, in this case, you
should put an IP address in to guarantee that. The advantage of the
domain name (and thus SRV lookup) is that, for stateless services or for
proxies which replicate state, you could route subsequent requests for
the same call through different servers, achieving some nice failover
properties.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jul 2000 02:40:21 -0400

Neil Deason wrote:
> not 5060, in the Request-URI.

I think you mean Record-Route.

> In the case of reverse request

I think I have mentioned already on the list that I believe the text in
6.35.2 is
wrong. Its not just the maddr copied from the Record-route, it would
also be port.

-Jonathan R.

---

From: Neil Deason <[email-masked]>
Date: Wed, 26 Jul 2000 10:23:12 +0100

> I think you mean Record-Route.

Well yes, I meant the URI taken from the incoming Request-URI 
once it had been copied into the Record-Route.

> 6.35.2 is wrong. 

Can you recall the thread - I have searched back to no avail.

> Its not just the maddr copied from the Record-route, it would
> also be port.

This would potentially mean building a new SIP URL by 
combining the maddr + port from the one in the Record-Route 
with the other elements of one in the Contact/From. This 
really represents a meaningless SIP URL. This ugliness 
seems to come about beacuse we are overloading the port 
part of the SIP URL in the Record-Route header to 
represent port of a proxy on the route. Is adding a new 
param for the proxy-port not an alternative?

At this point, and pre-IETF/Bakeoff, perhaps it is also 
worth re-raising the issue of a proxy being able to add 
something into the Record-Route to indicate call state. 
This was discussed at the 4th bakeoff but it was pointed 
out using a rr-extension is no use as a proxy wouldn't get 
it back via the Route header as this gets stripped off. If 
there is a real desire to achieve this perhaps something 
added in the name-addr part could work as the proxy should 
get this as part of the incoming Request-URI?

Finally Jo has pointed out to me that maybe the spec also
wants to say that a server MUST NOT add itself more than
once into the Record-Route. Otherwise this could happen on 
a 'legal' loop and the subsequent requests on the call leg
fail due to an illegal loop being created.

Cheers,
Neil.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2000 15:35:37 -0400

Jonathan Rosenberg wrote:

> the same call through different servers, achieving some nice failover

Makes sense. Changed to normal (DNS SRV, etc.) lookup procedure:

\item If the \header{maddr} parameter exists, it becomes the
\emph{destination address} used below; if not, the \header{host} element
in the \header{Request-URI} is the destination address.

\item If the destination address is an IP address, the client contacts
the server at the given address and ignores the remaining steps.

\item The \header{Request-URI} is examined. If it contains an explicit
port number other than 5060, the next two steps are skipped.

\item If the \header{Request-URI} specifies a transport protocol is
supported by the client, the client queries the name server for SRV
records for SIP servers of that protocol type only.  Otherwise, it goes
to the next step.

If the client does not support the protocol specified in the
\header{Request-URI}, it gives up.  The searching technique outlined in
RFC 2782 \cite{rfc2782} is used to select servers from the DNS response
in order.  If DNS does not return any records, the user goes to the last
step.  Otherwise, the user attempts to contact each server in the order
listed.  If no server is contacted, the user gives up.

\item If the \header{Request-URI} does not specify a protocol, the
client queries the name server for SRV records for all transport
protocols supported by the client.  The format of these queries is
defined in RFC 2782 \cite{rfc2782}.  The results of the query or queries
are merged and ordered based on priority.  Then, the searching technique
outlined in RFC 2782 \cite{rfc2782} is used to select servers in order.
If DNS does not return any records, the user goes to the last step.
Otherwise, the user attempts to contact each server in the order listed.
If none of the servers can be contacted, the user gives up.

\item The client queries the DNS server for address records for the
destination address.  Address records include A RR's, AAAA RR's, or
other similar records, chosen according to the client's network protocol
capabilities.  If the DNS server returns no address records, the client
stops, as it has been unable to locate a server.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2000 15:46:41 -0400

Jonathan Rosenberg wrote:

> wrong. Its not just the maddr copied from the Record-route, it would

Changed to:

If a UA finds a \header{Record-Route} header in a request received as a
UAS, it copies the \header{Record-Route} \header{maddr} parameters and
any \header{port} value, maintaining their ordering, to the
\header{Route} header field of future requests issued as a UAC.  Since
the URIs contained in the \header{Record-Route} header fields are not
useful for the reverse request path, the UA fills all other components
of the \header{Route} \header{name-addr} value with the
\header{name-addr} value found in the \header{Contact} or the
\header{From} header field.  The latter is used only if there is no
\header{Contact} header field.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jul 2000 17:56:31 -0400

Neil Deason wrote:
> with the other elements of one in the Contact/From. 

Exactly.

> This

Ugly, yes, but functional and backwards compatible. Adding proxy-port
would not be.

The one wrinkle with this is when you get an incoming request with a tel
URL, and you want to record-route. Now, the tel URL does not have an
maddr or port parameter. So, we may need to define these anyway, for use
in non-sip urls. With sip urls, you would use the URI parameters for
compatibility.
Old proxies won't recognize the new RR parameters, and so they would
rerun the
tel URL routing decision. But, thats what they would do now anyway if
these
parameters weren't there.

> get this as part of the incoming Request-URI?

The $10M question is this: if a proxy copies a route header into the
request URI,
does it also copy the URI parameters, even ones it doesn't know about?
What about 
record-route parameters? If the answer to either is yes, that would
provide one
way to accomplish such state pushing, although using State header is
cleaner.

> fail due to an illegal loop being created.

Interesting. This would only happen in the reverse path, since its
only in that case that the request URIs are the same (denoting
a loop as opposed to a spiral). Its a problem,
though, since the proxy really may need to record-route both times.
The solution might be some URI parameter just used as a differentiator.
A different value for this parameter would be inserted in each
Record-Route.
This would be popped into the request URI. Since the request URI is then
different for both, the hashes to compute the branch ID parameter are 
different, and this shows up as a spiral.

-Jonathan R.