tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5630

 
 
 

The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

Part 3 of 3, p. 36 to 56
Prev RFC Part

 


prevText      Top      Up      ToC       Page 36 
6.3.  Alice Calls Bob's SIP AOR Using TCP

   Bob's registration has already occurred as per Section 6.1.

   In the second example, Alice calls Bob's SIP AOR instead
   (sip:bob@example.com), and she uses TCP as a transport.  Registrar/
   Authoritative Proxy B consults the binding in the registration
   database, and finds the two Contact header field bindings.  Alice had
   addressed Bob with a SIP Request-URI (sip:bob@example.com), so
   Registrar/Authoritative Proxy B determines that the call needs to be
   routed both to bobpc (which registered with a SIP Contact header
   field) and bobphone (which registered with a SIPS Contact header
   field), and therefore the request is forked to
   sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through
   Edge Proxy B.  Note that Registrar/Authoritative Proxy B preserved
   the SIP scheme of the Request-URI instead of replacing it with the
   SIPS scheme of the Contact header field that was used for
   registration.  Both Registrar/Authoritative Proxy B and Edge Proxy B
   insert themselves in the Record-Route.  Bob's phone's policy is to
   accept calls to SIP and SIPS (i.e., "best effort"), so both his PC
   client and his SIP phone ring simultaneously.  Bob answers on his SIP
   phone, and the forked call leg to the PC client is canceled.

Top      Up      ToC       Page 37 
                           (eb)         (pb)
                           Edge      Registrar/
       Bob@bobpc          Proxy B   Auth. Proxy B   Proxy A     Alice
        |                   |            |            |            |
        |                   |            |            | INVITE F9  |
        |                   |            | INVITE F11 |<-----------|
        |                   | INVITE F13'|<-----------|   100 F10  |
        |    INVITE F15'    |<-----------|   100 F12  |----------->|
        |<------------------|   100 F14' |----------->|            |
        |     180 F16'      |----------->|            |            |
        |------------------>|   180 F17' |            |            |
        |                   |----------->|  180 F18'  |            |
        |   Bob@bobphone    |            |----------->|   180 F19' |
        |      |            | INVITE F13 |            |----------->|
        |      | INVITE F15 |<-----------|            |            |
        |      |<-----------|   100 F14  |            |            |
        |      |   180 F16  |----------->|            |            |
        |      |----------->|   180 F17  |            |            |
        |      |   200 F20  |----------->|   180 F18  |            |
        |      |----------->|   200 F21  |----------->|   180 F19  |
        |      |            |----------->|   200 F22  |----------->|
        |      |            |            |----------->|   200 F23  |
        |      |            |            |            |----------->|
        |      |            |            |            |   ACK F24  |
        |      |            |            |   ACK F25  |<-----------|
        |      |            |   ACK F26  |<-----------|            |
        |      |   ACK F27  |<-----------|            |            |
        |      |<-----------|            |            |            |
        |                   | CANCEL F26'|            |            |
        |    CANCEL F27'    |<-----------|            |            |
        |<------------------|            |            |            |
        |     200 F28'      |            |            |            |
        |------------------>|   200 F29' |            |            |
        |     487 F30'      |----------->|            |            |
        |------------------>|   487 F31' |            |            |
        |                   |----------->|            |            |


                         Alice Calls Bob's SIP AOR

Top      Up      ToC       Page 38 
   Message details

   F9 INVITE Alice -> Proxy A

   INVITE sip:bob@example.com SIP/2.0
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 70
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Route: <sip:proxya.example.net;lr>
   Contact: <sip:alice@alice-1.example.net>
   Content-Type: application/sdp
   Content-Length: {as per SDP}
   {SDP not shown}


   F10 100 (INVITE) Proxy A -> Alice

   SIP/2.0 100 Trying
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Content-Length: 0


   F11 INVITE Proxy A -> Registrar/Authoritative Proxy B

   INVITE sip:bob@example.com SIP/2.0
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 69
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route: <sip:proxya.example.net;lr>
   Contact: <sip:alice@alice-1.example.net>
   Content-Type: application/sdp
   Content-Length: {as per SDP}
   {SDP not shown}

Top      Up      ToC       Page 39 
   F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A

   SIP/2.0 100 Trying
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Content-Length: 0


   F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B

   INVITE sip:bob@bobpc.example.com SIP/2.0
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 68
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
   Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:alice@alice-1.example.net>
   Content-Type: application/sdp
   Content-Length: {as per SDP}
   {SDP not shown}


   F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 100 Trying
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Content-Length: 0

Top      Up      ToC       Page 40 
   F15' INVITE Edge Proxy B -> Bob's PC Client

   INVITE sip:bob@bobpc.example.com SIP/2.0
   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 67
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:alice@alice-1.example.net>
   Content-Type: application/sdp
   Content-Length: {as per SDP}
   {SDP not shown}


   F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=963258
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobpc.example.com>
   Content-Length: 0

Top      Up      ToC       Page 41 
   F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=963258
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobpc.example.com>
   Content-Length: 0


   F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=963258
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobpc.example.com>
   Content-Length: 0

Top      Up      ToC       Page 42 
   F19' 180 (INVITE) Proxy A -> Alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=963258
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobpc.example.com>
   Content-Length: 0


   F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B

   INVITE sip:bob@bobphone.example.com SIP/2.0
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 68
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
   Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:alice@alice-1.example.net>
   Content-Type: application/sdp
   Content-Length: {as per SDP}
   {SDP not shown}


   F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 100 Trying
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Content-Length: 0

Top      Up      ToC       Page 43 
   F15 INVITE Edge Proxy B -> Bob's Phone

   INVITE sip:bob@bobphone.example.com SIP/2.0
   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 68
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:alice@alice-1.example.net>
   Content-Type: application/sdp
   Content-Length: {as per SDP}
   {SDP not shown}


   F16 180 (INVITE) Bob's Phone -> Edge Proxy B

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0

Top      Up      ToC       Page 44 
   F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0


   F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0

Top      Up      ToC       Page 45 
   F19 180 (INVITE) Proxy A -> Alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0


   F20 200 (INVITE) Bob's Phone -> Edge Proxy B

   SIP/2.0 200 OK
   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0

Top      Up      ToC       Page 46 
   F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0


   F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0

Top      Up      ToC       Page 47 
   F23 200 (INVITE) Proxy A -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Record-Route:
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
   Contact: <sip:bob@bobphone.example.com>
   Content-Length: 0


   F24 ACK Alice -> Proxy A

   ACK sip:bob@bobphone.example.com SIP/2.0
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 70
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 ACK
   Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
   Content-Length: 0


   F25 ACK Proxy A -> Registrar/Authoritative Proxy B

   ACK sip:bob@bobphone.example.com SIP/2.0
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 69
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 ACK
   Route: <sip:pb.example.com;lr>,
          <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
    Content-Length: 0

Top      Up      ToC       Page 48 
   F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B

   ACK sip:bob@bobphone.example.com SIP/2.0
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 69
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 ACK
   Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
   Content-Length: 0


   F27 ACK Proxy B -> Bob's Phone

   ACK sip:bob@bobphone.example.com SIP/2.0
   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   Max-Forwards: 68
   To: Bob <sip:bob@example.com>;tag=5551212
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 ACK
   Content-Length: 0


   F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B

   CANCEL sip:bob@bobpc.example.com SIP/2.0
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Max-Forwards: 70
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 CANCEL
   Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
   Content-Length: 0

Top      Up      ToC       Page 49 
   F27' CANCEL Edge Proxy B -> Bob's PC Client

   CANCEL sip:bob@bobpc.example.com SIP/2.0
   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Max-Forwards: 69
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 CANCEL
   Content-Length: 0


   F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 CANCEL
   Content-Length: 0


   F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 CANCEL
   Content-Length: 0

Top      Up      ToC       Page 50 
   F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Content-Length: 0


   F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.net>;tag=8675309
   Call-ID: lzksjf8723k@sodk6587
   CSeq: 1 INVITE
   Content-Length: 0

6.4.  Alice Calls Bob's SIP AOR Using TLS

   Bob's registration has already occurred as per Section 6.1.

   The third example is identical to the second one, except that Alice
   uses TLS as the transport for her connection to her proxy.  Such an
   arrangement would be common if Alice's UA supported TLS and wanted to
   use a single connection to the proxy (as would be the case when using
   [RFC5626]).  In the example below, Proxy A is also using TLS as a
   transport to communicate with Outbound Proxy B, but it is not
   necessarily the case.

   When using a SIP URI in the Request-URI but TLS as a transport for
   sending the request, the Via field indicates TLS.  The Route header
   field (if present) typically would use a SIP URI (but it could also
   be a SIPS URI).  The Contact header fields and To and From, however
   would also normally indicate a SIP URI.

   The call flow would be exactly as per the second example
   (Section 6.3).  The only difference would be that all the Via header
   fields would use TLS Via parameters.  The URIs would remain SIP URIs
   and not SIPS URIs.

Top      Up      ToC       Page 51 
7.  Further Considerations

   SIP [RFC3261] itself introduces some complications with using SIPS,
   for example, when Record-Route is not used.  When a SIPS URI is used
   in a Contact header field in a dialog-initiating request and Record-
   Route is not used, that SIPS URI might not be usable by the other
   end.  If the other end does not support SIPS and/or TLS, it will not
   be able to use it.  The last-hop exception is an example of when this
   can occur.  In this case, using Record-Route so that the requests are
   sent through proxies can help in making it work.  Another example is
   that even in a case where the Contact header field is a SIPS URI, no
   Record-Route is used, and the far end supports SIPS and TLS, it might
   still not be possible for the far end to establish a TLS connection
   with the SIP originating end if the certificate cannot be validated
   by the far end.  This could typically be the case if the originating
   end was using server-side authentication as described below, or if
   the originating end is not using a certificate that can be validated.

   TLS itself has a significant impact on how SIPS can be used.  Server-
   side authentication (where the server side provides its certificate
   but the client side does not) is typically used between a SIP end-
   user device acting as the TLS client side (e.g., a phone or a
   personal computer) and its SIP server (proxy or registrar) acting as
   the TLS server side.  TLS mutual authentication (where both the
   client side and the server side provide their respective
   certificates) is typically used between SIP servers (proxies,
   registrars), or statically configured devices such as PSTN gateways
   or media servers.  In the mutual authentication model, for two
   entities to be able to establish a TLS connection, it is required
   that both sides be able to validate each other's certificates, either
   by static configuration or by being able to recurse to a valid root
   certificate.  With server-side authentication, only the client side
   is capable of validating the server side's certificate, as the client
   side does not provide a certificate.  The consequences of all this
   are that whenever a SIPS URI is used to establish a TLS connection,
   it is expected to be possible for the entity establishing the
   connection (the client) to validate the certificate from the server
   side.  For server-side authentication, [RFC5626] is the recommended
   approach.  For mutual authentication, one needs to ensure that the
   architecture of the network is such that connections are made between
   entities that have access to each other's certificates.  Record-Route
   [RFC3261] and Path [RFC3327] are very useful in ensuring that
   previously established TLS connections can be reused.  Other
   mechanisms might also be used in certain circumstances: for example,
   using root certificates that are widely recognized allows for more
   easily created TLS connections.

Top      Up      ToC       Page 52 
8.  Security Considerations

   Most of this document can be considered to be security considerations
   since it applies to the usage of the SIPS URI.

   The "last-hop exception" of [RFC3261] introduced significant
   potential vulnerabilities in SIP, and it has therefore been
   deprecated by this specification.

   Section 26.4.4 of [RFC3261] describes the security considerations for
   the SIPS URI scheme.  These security considerations also applies
   here, as modified by Appendix A.

9.  IANA Considerations

   This specification registers two new warning codes, namely, 380 "SIPS
   Not Allowed" and 381 "SIPS Required".  The warning codes are defined
   as follows, and have been included in the Warning Codes (warn-codes)
   sub-registry of the SIP Parameters registry available from
   http://www.iana.org.

   380  SIPS Not Allowed: The UAS or proxy cannot process the request
        because the SIPS scheme is not allowed (e.g., because there are
        currently no registered SIPS contacts).

   381  SIPS Required: The UAS or proxy cannot process the request
        because the SIPS scheme is required.

   Reference: RFC 5630

   The note in the Warning Codes sub-registry is as follows:

      Warning codes provide information supplemental to the status code
      in SIP response messages.

10.  Acknowledgments

   The author would like to thank Jon Peterson, Cullen Jennings,
   Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert
   Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage,
   Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham
   Karthabil, Dean Willis, Eric Tremblay, Hans Persson, and Ben Campbell
   for their careful review and input.  Many thanks to Rohan Mahy for
   helping me with the subtleties of [RFC5626].

Top      Up      ToC       Page 53 
11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5626]  Jennings, C., "Managing Client-Initiated Connections in
              the Session Initiation Protocol (SIP)", RFC 5626, October
              2009.

11.2.  Informative References

   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3327, December 2002.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [RFC3608]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Service Route Discovery
              During Registration", RFC 3608, October 2003.

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
              Protocol (SIP) "Replaces" Header", RFC 3891,
              September 2004.

   [RFC3893]  Peterson, J., "Session Initiation Protocol (SIP)
              Authenticated Identity Body (AIB) Format", RFC 3893,
              September 2004.

Top      Up      ToC       Page 54 
   [RFC3911]  Mahy, R. and D. Petrie, "The Session Initiation Protocol
              (SIP) "Join" Header", RFC 3911, October 2004.

   [RFC4168]  Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
              Stream Control Transmission Protocol (SCTP) as a Transport
              for the Session Initiation Protocol (SIP)", RFC 4168,
              October 2005.

   [RFC4244]  Barnes, M., "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 4244,
              November 2005.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent URIs (GRUU) in the Session Initiation Protocol
              (SIP)", RFC 5627, October 2009.

Top      Up      ToC       Page 55 
Appendix A.  Bug Fixes for RFC 3261

   In order to support the material in this document, this section makes
   corrections to RFC 3261.

   The last sentence of the fifth paragraph of Section 8.1.3.5 is
   replaced by:

      The client SHOULD retry the request, this time, using a SIP URI
      unless the original Request-URI used a SIPS scheme, in which case
      the client MUST NOT retry the request automatically.

   The fifth paragraph of Section 10.2.1 is replaced by:

      If the Address of Record in the To header field of a REGISTER
      request is a SIPS URI, then the UAC MUST also include only SIPS
      URIs in any Contact header field value in the requests.

   In Section 16.7 on p. 112 describing Record-Route, the second
   paragraph is deleted.

   The last paragraph of Section 19.1 is reworded as follows:

      A SIPS URI specifies that the resource be contacted securely.
      This means, in particular, that TLS is to be used on each hop
      between the UAC and the resource identified by the target SIPS
      URI.  Any resources described by a SIP URI (...)

   In the third paragraph of Section 20.43, the words "the session
   description" in the first sentence are replaced with "SIP".  Later in
   the paragraph, "390" is replaced with "380", and "miscellaneous
   warnings" is replaced with "miscellaneous SIP-related warnings".

   The second paragraph of Section 26.2.2 is reworded as follows:

      (...)  When used as the Request-URI of a request, the SIPS scheme
      signifies that each hop over which the request is forwarded, until
      the request reaches the resource identified by the Request-URI, is
      secured with TLS.  When used by the originator of a request (as
      would be the case if they employed a SIPS URI as the address-of-
      record of the target), SIPS dictates that the entire request path
      to the target domain be so secured.

   The first paragraph of Section 26.4.4 is replaced by the following:

      Actually using TLS on every segment of a request path entails that
      the terminating UAS is reachable over TLS (by registering with a
      SIPS URI as a contact address).  The SIPS scheme implies

Top      Up      ToC       Page 56 
      transitive trust.  Obviously, there is nothing that prevents
      proxies from cheating.  Thus, SIPS cannot guarantee that TLS usage
      will be truly respected end-to-end on each segment of a request
      path.  Note that since many UAs will not accept incoming TLS
      connections, even those UAs that do support TLS will be required
      to maintain persistent TLS connections as described in the TLS
      limitations section above in order to receive requests over TLS as
      a UAS.

   The first sentence of the third paragraph of Section 26.4.4 is
   replaced by the following:

      Ensuring that TLS will be used for all of the request segments up
      to the target UAS is somewhat complex.

   The fourth paragraph of Section 26.4.4 is deleted.

   The last sentence of the fifth paragraph of Section 26.4.4 is
   reworded as follows:

      S/MIME or, preferably, [RFC4474] may also be used by the
      originating UAC to help ensure that the original form of the To
      header field is carried end-to-end.

   In the third paragraph of Section 27.2, the phrase "when the failure
   of the transaction results from a Session Description Protocol (SDP)
   (RFC 2327 [1]) problem" is deleted.

   In the fifth paragraph of Section 27.2, "390" is replaced with "380",
   and "miscellaneous warnings" is replaced with "miscellaneous SIP-
   related warnings".

Author's Address

   Francois Audet
   Skype Labs

   EMail: francois.audet@skypelabs.com