Subject: Record-Route and Route header clarification

From: "Donovan, Steven R." <[email-masked]>
Date: Mon, 26 Apr 1999 17:59:22 -0000

The SIP specification as it exists is not 100% clear in the handling of
Record-Route and Route headers.  This memo outlines the understanding of one
implementation.  The goal being to either validate or update that
understanding and to explore whether clarifications to the specification are
needed.

> The purpose of the Record-Route and Route headers is to ensure that SIP
> requests for an established session and the ACK request resulting from the
> INVITE, 200 OK message pair get routed through interested proxy servers.
> The correct routing needs to occur in both directions, both when the
> request comes from the calling user agent and when it comes from the
> called user agent.
> 
> The SIP specification currently doesn't explicitly reference the required
> use of the route header when the request is generated by the called user
> agent.
> 
> The desired behavior is illustrated in the following call flows, which
> include three proxy servers, two of which want to be involved in
> subsequent SIP requests.  In the first scenario the calling user agent is
> identified by the presence of a contact header in the INVITE message.  In
> the second scenario the contact header is not present in the INVITE
> message, thus the From URI would be used to build the called user agents
> route list.
> 
> These scenarios rely on a proposed enhancement to the SIP specification
> that would require the called user agent to add a contact header to the
> 200 OK response to an INVITE message if that INVITE message contained a
> record-route header.  The need to add this behavior to the called user
> agent was discussed during the SIP Bake-off.
> 
> F = From
> T = To
> M = Contact
> I = Call-id
> Q = Cseq
> RR = Record-Route
> R = Route
> 
> Note 1: I understand that Q, R and RR are not formal true compact form
> headers.  I used them for brevity in the following flows.  It might be
> interesting to have some additional compact form headers added, especially
> for Cseq, which is a mandatory parameter.
> 
Note 2: The handling of via headers is intentionally left out of these flows
for the sake of brevity.

> SCENARIO ONE (Contact included in INVITE message)
> ------------
> 
>   A2          SPS1         SPS2         SPS3           B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>    M:A2         M:A2         M:A2         M:A2         
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)    
> 
>   At this point User B will store the Route SPS3,SPS1,A2
> 
>   A2           SPS1         SPS2         SPS3           B2
>    <------------<------------<------------<------------
>    200 OK       200 OK       200 OK       200 OK       
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>    M:B2         M:B2         M:B2         M:B2         
>    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    
>        SPS1)        SPS1)        SPS1)        SPS1)
> 
>   At this point User A will store the Route SPS1,SPS3,B2
> 
>   A2           SPS1         SPS2         SPS3           B2
>    ------------>------------------------->------------>
>    ACK SPS1     ACK SPS3                  ACK B2
>    F:User A     F:User A                  F:User A     
>    T:User B     T:User B                  T:User B     
>    Q:1 ACK      Q:1 ACK                   Q:1 ACK   
>    I:1@A        I:1@A                     I:1@A        
>    R:(SPS3,     R:(B2)                    
>       B2)       
> 
>   A2           SPS1         SPS2         SPS3           B2
>    <------------<-------------------------<------------
>    INVITE A2    INVITE SPS1               INVITE SPS3  
>    F:User B     F:User B                  F:User B     
>    T:User A     T:User A                  T:User A     
>    Q:2 INVITE   Q:2 INVITE                Q:2 INVITE
>    I:1@A        I:1@A                     I:1@A        
>                 R:(A2)                    R:(SPS1,    
>                                              A2)
> 
>   A2           SPS1         SPS2         SPS3           B2
>    <------------<-------------------------<------------
>    BYE A2       BYE SPS1                  BYE SPS3     
>    F:User B     F:User B                  F:User B     
>    T:User A     T:User A                  T:User A     
>    Q:3 BYE      Q:3 BYE                   Q:3 BYE   
>    I:1@A        I:1@A                     I:1@A        
>                 R:(A2)                    R:(SPS1,    
>                                              A2)
> 
> 
> SCENARIO TWO (No contact included in INVITE message)
> ------------
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------>------------>------------>
>    Invite SPS1  Invite SPS2  Invite SPS3  Invite B2
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>                 RR:(SPS1)    RR:(SPS1)    RR:(SPS3,
>                                               SPS1)    
> 
>   At this point User B will store the Route SPS3,SPS1,User A
> 
> User A         SPS1         SPS2         SPS3         B2
>    <------------<------------<------------<------------
>    200 OK       200 OK       200 OK       200 OK       
>    F:User A     F:User A     F:User A     F:User A     
>    T:User B     T:User B     T:User B     T:User B     
>    Q:1 INVITE   Q:1 INVITE   Q:1 INVITE   Q:1 INVITE
>    I:1@A        I:1@A        I:1@A        I:1@A        
>    M:B2         M:B2         M:B2         M:B2         
>    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    RR:(SPS3,    
>        SPS1)        SPS1)        SPS1)        SPS1)
> 
>   At this point User A will store the Route SPS1,SPS3,B2
> 
> User A        SPS1         SPS2         SPS3          B2
>    ------------>------------------------->------------>
>    ACK SPS1     ACK SPS3                  ACK B2
>    F:User A     F:User A                  F:User A     
>    T:User B     T:User B                  T:User B     
>    Q:1 ACK      Q:1 ACK                   Q:1 ACK   
>    I:1@A        I:1@A                     I:1@A        
>    R:(SPS3,     R:(B2)                    
>       B2)       
> 
> User A          SPS1         SPS2         SPS3         B2
>    <-------------<-------------------------<------------
>    INVITE User A INVITE SPS1               INVITE SPS3  
>    F:User B      F:User B                  F:User B     
>    T:User A      T:User A                  T:User A     
>    Q:2 INVITE    Q:2 INVITE                Q:2 INVITE
>    I:1@A         I:1@A                     I:1@A        
>                  R:(User A)                R:(SPS1,    
>                                               User A)
> 
> User A         SPS1         SPS2         SPS3         B2
>    <------------<-------------------------<------------
>    BYE User A   BYE SPS1                  BYE SPS3     
>    F:User B     F:User B                  F:User B     
>    T:User A     T:User A                  T:User A     
>    Q:3 BYE      Q:3 BYE                   Q:3 BYE   
>    I:1@A        I:1@A                     I:1@A        
>                 R:(User A)                R:(SPS1,    
>                                              User A)
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Apr 1999 15:59:10 -0400

> Donovan, Steven R. wrote:
> 
> The purpose of the Record-Route and Route headers is to ensure that
> SIP requests for an established session and the ACK request resulting
> from the INVITE, 200 OK message pair get routed through interested
> proxy servers.  The correct routing needs to occur in both directions,
> both when the request comes from the calling user agent and when it
> comes from the called user agent.

Yup. The operation is as you describe, except you have an SPS3 missing
from the reverse INVITE's in one of the flows below. The callee takes
the Record-Route header, adds the Contact from the request to the
bottom, and uses it as the Route header in subsequent requests. This has
been reported already. (Our UA does this already, in fact). 

> 
> These scenarios rely on a proposed enhancement to the SIP
> specification that would require the called user agent to add a
> contact header to the 200 OK response to an INVITE message if that
> INVITE message contained a record-route header.  The need to add this
> behavior to the called user agent was discussed during the SIP
> Bake-off.

Yes. I agree its a good idea, as did others at the bakeoff. In fact, its
easiest to simplify this further and simply change Contact in the
response from SHOULD to MUST (I think its SHOULD now).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 27 Apr 1999 12:58:05 +0100

> "Donovan, Steven R." wrote:
> 

Nice explanation of the problem. I have one small question...

> SCENARIO TWO (No contact included in INVITE message)

As there was no Contact in the INVITE, shouldn't B omit A from its
stored route, i.e. store the route SPS3,SPS1 and leave it to SPS1 to do
the final routing to A?

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK