Subject: [SIP] Record-Route and ports (Was: Questions on new loop detection mentioned in RFC2543 bis)

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 19 Jul 2000 17:14:56 +0100

Hi,

The cogs in my mind have been slowly turning, and I am now
worried. &:)

Section 6.35.2 (Construction of a Route Header) of the most
recent draft, states the following:
   "If a UA find a Record-Route header in a request, it copies the
   Record-Route maddr parameters only, maintaining their ordering, to
   the Route header field of future requests. Since the URIs contained
   in the Record-Route header fields 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."

This means that there is no way for a proxy to indicate what
port to send to.  In fact, I think it's worse than that, since
I think that correct client behaviour specifies that a client
should send to the address in the Request-URI.  Now, the maddr
will override the IP, but if the originating UA Contact address
contained a port that wasn't 5060, couldn't subsequent requests
from Callee to Caller get completely lost?

(I also note that 6.47.3 says nothing about sending to the port
in the received parameter -- surely this is incorrect, given
the "special" behaviour of User Agent and Redirect Servers in
6.47.4?)

It would be unwise to change the behaviour in 6.35.2 so that
the name-addr included the appropriate port, I guess, since
then the Contact address could be broken; however, I'm not sure
that doing something like adding a `proxy-port' parameter is
any better (it should be backwards compatible, but proxies
are still going to have to be receptive on 5060 to work with
older clients).

Thoughts?

Cheers,

 - Jo.
-- 
  Jo Hornsby; IT Professional         --       mailto:[email-masked]
 Ubiquity Software Corporation        --         http://www.ubiquity.net/

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