Subject: [SIP] Record-Route and REGISTER

From: David Shrader <[email-masked]>
Date: Sun, 17 Dec 2000 15:40:27 -0500

I've been reading the record-route material and am considering its general
application to SIP requests and find that there it is not as general as we
think.

The mechanism described in the bis-02 relies on the interpretation of the
Contact header only for some messages. That is, the text states that the
Contact header, if included, is appended to the Route list. This assumes
that the Contact header is used only to represent the party to which a
subsequent request along that route would be sent.

When using the REGISTER method, however, the Contact header is NOT used for
that purpose. The Contact header in the Response to a REGISTER is simply a
list of registered contacts and does not in fact identify the recipient of a
subsequent request.

Scenario that generated this problem:
    1. REGISTER is sent from UAC to an outbound proxy, addressed to a
        service provider (i.e., sip:provider.net)
    2. The proxy inserts a Record-Route header into the REGISTER message and
        routes it to the host for sip:provider.net.
    3. The server then echoes the Record-Route header in the response and
        several registered Contact headers.
    4. The UAC then receives the Record-Route. When it attempts to refresh
        its reservation, it cannot follow the rules in the bis-02 spec
        because the Contact header cannot be used as a Route header in this
        case. The message will never get to the registrar server because the
        Request-URI would indicate the received record-route header and
        there is no header to include the sip:provider.net URI.

Any thoughts on a solution?

I've thought it strange that the UAC is expected to add the received Contact
header to the Route list. Perhaps the solution is really that the UAS
receiving the Record-Route header should add its own Contact as the final
Record-Route. In that way, the UAC doesn't have to do anything at all and
there is no ambiguity due to the overloading of Contact header that we have
done in the spec.

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]
http://www.EyeForTheFuture.com

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

---

From: "Wayne Cutler" <[email-masked]>
Date: Wed, 20 Dec 2000 16:49:15 +0000

>This issue is what I meant when I said:

>What is the the scope of the Route? To which set of messages does
>it apply? When can the route be purged?

>The obvious generalization of the current Route mechanism is that a UA uses
>the Routes for all requests with the same To/From/Call-ID. This would then
>effect refreshes of REGISTER, and is also how we handle record-routing of
>SUBSCRIBE/NOTIFY and MESSAGE as well.

>What would you use RR on REGISTER for? Not sure... any ideas?

One use could be to force all subsequent signalling to be routed to a specific
address - i.e. different from
that used in the REGISTER. All future sessions are within the context of this
registration and so it (sort of) fits in
with how RR is normally used.

Wayne.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 28 Dec 2000 15:01:12 -0800

> 
> The reason I raised this question originally is in the 
> context of a security
> architecture in which we maintain secure connections to user 
> agents outside
> of a secure/trusted perimeter. Upon establishment of a secure 
> connection for
> a user agent to the network, RR could be used to insure that 
> the secure
> channel is used in both directions for subsequent 
> interactions. The REGISTER
> message, of course, must be included in the overall structure.
> 
> Note: the overall solution to this problem might involve 
> pre-loaded Route
> headers as well which were not under discussion in this email.
> 
> As such, I think the RR mechanism could be useful as a generic routing
> mechanism that applies to any SIP call leg (To/From/Call-ID) 
> and whatever
> requests are a part of that call leg without having to define method
> specific processing.
> 

Hi David,

I don't understand. Are you saying that the REGISTER R-R is used for
subsequent INVITE transactions? 

The REGISTER doesn't have the same To/From/Call-Id. Additionally, R-R does
not allow you to specify different Request-URI's in subsequent transactions.

I guess you could define that the Record-ROute in the REGISTER is used as a
pre-loaded Route in INVITE transactions pertaining to this REGISTER. This
would definitely require method specific processing (and also assumes that
the "local" proxy and registrar must go through the same number of
record-routing proxies). It would require all sorts of funky ROute
construction (eg putting final request-URI after Contact from register). Is
is worth it? Probably not. We want generic methods not method specific cases
(as you said).

For your problem, can't you place a registrar & proxy outside your "secure
zone". Authentication and/or encrytption between the UA and external
registrar/proxy can then provide the "secure connection" and the proxy can
ensure that the UA uses the correct path (much like secure remote network
connection servers work today).

Regards,

Robert.