tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5626

 
 
 

Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)

Part 3 of 3, p. 30 to 50
Prev RFC Part

 


prevText      Top      Up      ToC       Page 30 
9.  Example Message Flow

   Below is an example message flow illustrating most of the concepts
   discussed in this specification.  In many cases, Via, Content-Length,
   and Max-Forwards headers are omitted for brevity and readability.

   In these examples, "EP1" and "EP2" are outbound proxies, and "Proxy"
   is the authoritativeProxy.

   The section is subdivided into independent calls flows; however, they
   are structured in sequential order of a hypothetical sequence of call
   flows.

9.1.  Subscription to Configuration Package

   If the outbound proxy set is already configured on Bob's UA, then
   this subsection can be skipped.  Otherwise, if the outbound proxy set
   is learned through the configuration package, Bob's UA sends a
   SUBSCRIBE request for the UA profile configuration package
   [CONFIG-FMWK].  This request is a poll (Expires is zero).  After
   receiving the NOTIFY request, Bob's UA fetches the external
   configuration using HTTPS (not shown) and obtains a configuration
   file that contains the outbound-proxy-set "sip:ep1.example.com;lr"
   and "sip:ep2.example.com;lr".

     [----example.com domain-------------------------]
     Bob         EP1   EP2     Proxy             Config
      |           |     |        |                  |
    1)|SUBSCRIBE->|     |        |                  |
    2)|           |---SUBSCRIBE Event: ua-profile ->|
    3)|           |<--200 OK -----------------------|
    4)|<--200 OK--|     |        |                  |
    5)|           |<--NOTIFY------------------------|
    6)|<--NOTIFY--|     |        |                  |
    7)|---200 OK->|     |        |                  |
    8)|           |---200 OK ---------------------->|
      |           |     |        |                  |

   In this example, the DNS server happens to be configured so that sip:
   example.com resolves to EP1 and EP2.

Top      Up      ToC       Page 31 
   Example Message #1:

   SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com
     SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnlsdkdj2
   Max-Forwards: 70
   From: <anonymous@example.com>;tag=23324
   To: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>
   Call-ID: nSz1TWN54x7My0GvpEBj
   CSeq: 1 SUBSCRIBE
   Event: ua-profile ;profile-type=device
    ;vendor="example.com";model="uPhone";version="1.1"
   Expires: 0
   Supported: path, outbound
   Accept: message/external-body, application/x-uPhone-config
   Contact: <sip:192.0.2.2;transport=tcp;ob>
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Content-Length: 0

   In message #2, EP1 adds the following Record-Route header:

   Record-Route:
    <sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>

   In message #5, the configuration server sends a NOTIFY with an
   external URL for Bob to fetch his configuration.  The NOTIFY has a
   Subscription-State header that ends the subscription.

   Message #5

   NOTIFY sip:192.0.2.2;transport=tcp;ob SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.5;branch=z9hG4bKn81dd2
   Max-Forwards: 70
   To: <anonymous@example.com>;tag=23324
   From: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>;tag=0983
   Call-ID: nSz1TWN54x7My0GvpEBj
   CSeq: 1 NOTIFY
   Route: <sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>
   Subscription-State: terminated;reason=timeout
   Event: ua-profile
   Content-Type: message/external-body; access-type="URL"
    ;expiration="Thu, 01 Jan 2009 09:00:00 UTC"
    ;URL="http://example.com/uPhone.cfg"
    ;size=9999;hash=10AB568E91245681AC1B
   Content-Length: 0

Top      Up      ToC       Page 32 
   EP1 receives this NOTIFY request, strips off the Route header,
   extracts the flow-token, calculates the correct flow, and forwards
   the request (message #6) over that flow to Bob.

   Bob's UA fetches the configuration file and learns the outbound proxy
   set.

9.2.  Registration

   Now that Bob's UA is configured with the outbound-proxy-set whether
   through configuration or using the configuration framework procedures
   of the previous section, Bob's UA sends REGISTER requests through
   each edge proxy in the set.  Once the registrations succeed, Bob's UA
   begins sending CRLF keep-alives about every 2 minutes.

     Bob         EP1   EP2     Proxy     Alice
      |           |     |        |         |
    9)|-REGISTER->|     |        |         |
   10)|           |---REGISTER-->|         |
   11)|           |<----200 OK---|         |
   12)|<-200 OK---|     |        |         |
   13)|----REGISTER---->|        |         |
   14)|           |     |--REG-->|         |
   15)|           |     |<-200---|         |
   16)|<----200 OK------|        |         |
      |           |     |        |         |
      |  about 120 seconds later...        |
      |           |     |        |         |
   17)|--2CRLF--->|     |        |         |
   18)|<--CRLF----|     |        |         |
   19)|------2CRLF----->|        |         |
   20)|<------CRLF------|        |         |
      |           |     |        |         |

   In message #9, Bob's UA sends its first registration through the
   first edge proxy in the outbound-proxy-set by including a loose
   route.  The UA includes an instance-id and reg-id in its Contact
   header field value.  Note the option-tags in the Supported header.

Top      Up      ToC       Page 33 
   Message #9

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
   Max-Forwards: 70
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>
   Call-ID: 16CB75F21C70
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Content-Length: 0

   Message #10 is similar.  EP1 removes the Route header field value,
   decrements Max-Forwards, and adds its Via header field value.  Since
   EP1 is the first edge proxy, it adds a Path header with a flow token
   and includes the "ob" parameter.

   Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>

   Since the response to the REGISTER (message #11) contains the
   outbound option-tag in the Require header field, Bob's UA will know
   that the registrar used outbound binding rules.  The response also
   contains the currently active Contacts, and the Path for the current
   registration.

   Message #11

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
   Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>;tag=6AF99445E44A
   Call-ID: 16CB75F21C70
   CSeq: 1 REGISTER
   Supported: path, outbound
   Require: outbound
   Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
   Content-Length: 0

   The second registration through EP2 (message #13) is similar except
   that the Call-ID has changed, the reg-id is 2, and the Route header
   goes through EP2.

Top      Up      ToC       Page 34 
   Message #13

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
   Max-Forwards: 70
   From: Bob <sip:bob@example.com>;tag=755285EABDE2
   To: Bob <sip:bob@example.com>
   Call-ID: E05133BD26DD
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep2.example.com;lr>
   Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Content-Length: 0

   Likewise in message #14, EP2 adds a Path header with flow token and
   "ob" parameter.

   Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>

   Message #16 tells Bob's UA that outbound registration was successful,
   and shows both Contacts.  Note that only the Path corresponding to
   the current registration is returned.

   Message #16

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
   From: Bob <sip:bob@example.com>;tag=755285EABDE2
   To: Bob <sip:bob@example.com>;tag=49A9AD0B3F6A
   Call-ID: E05133BD26DD
   Supported: path, outbound
   Require: outbound
   CSeq: 1 REGISTER
   Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2;expires=3600
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
   Content-Length: 0

9.3.  Incoming Call and Proxy Crash

   In this example, after registration, EP1 crashes and reboots.  Before
   Bob's UA notices that its flow to EP1 is no longer responding, Alice
   calls Bob.  Bob's authoritative proxy first tries the flow to EP1,

Top      Up      ToC       Page 35 
   but EP1 no longer has a flow to Bob, so it responds with a 430 (Flow
   Failed) response.  The proxy removes the stale registration and tries
   the next binding for the same instance.

     Bob         EP1   EP2     Proxy     Alice
      |           |     |        |         |
      |    CRASH  X     |        |         |
      |        Reboot   |        |         |
      |           |     |        |         |
   21)|           |     |        |<-INVITE-|
   22)|           |<---INVITE----|         |
   23)|           |----430------>|         |
   24)|           |     |<-INVITE|         |
   25)|<---INVITE-------|        |         |
   26)|----200 OK------>|        |         |
   27)|           |     |200 OK->|         |
   28)|           |     |        |-200 OK->|
   29)|           |     |<----------ACK----|
   30)|<---ACK----------|        |         |
      |           |     |        |         |
   31)|           |     |<----------BYE----|
   32)|<---BYE----------|        |         |
   33)|----200 OK------>|        |         |
   34)|           |     |--------200 OK--->|
      |           |     |        |         |


   Message #21

   INVITE sip:bob@example.com SIP/2.0
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE

   Bob's proxy rewrites the Request-URI to the Contact URI used in Bob's
   registration, and places the path for one of the registrations
   towards Bob's UA instance into a Route header field.  This Route goes
   through EP1.

   Message #22

   INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>

Top      Up      ToC       Page 36 
   Since EP1 just rebooted, it does not have the flow described in the
   flow token.  It returns a 430 (Flow Failed) response.

   Message #23

   SIP/2.0 430 Flow Failed
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE

   The proxy deletes the binding for this path and tries to forward the
   INVITE again, this time with the path through EP2.

   Message #24

   INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>

   In message #25, EP2 needs to add a Record-Route header field value,
   so that any subsequent in-dialog messages from Alice's UA arrive at
   Bob's UA.  EP2 can determine it needs to Record-Route since the
   request is a dialog-forming request and the Route header contained a
   flow token and an "ob" parameter.  This Record-Route information is
   passed back to Alice's UA in the responses (messages #26, 27, and
   28).

   Message #25

   INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Record-Route:
     <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>

Top      Up      ToC       Page 37 
   Message #26

   SIP/2.0 200 OK
   To: Bob <sip:bob@example.com>;tag=skduk2
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Record-Route:
     <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>

   At this point, both UAs have the correct route-set for the dialog.
   Any subsequent requests in this dialog will route correctly.  For
   example, the ACK request in message #29 is sent from Alice's UA
   directly to EP2.  The BYE request in message #31 uses the same route-
   set.

   Message #29

   ACK sip:bob@192.0.2.2;transport=tcp SIP/2.0
   To: Bob <sip:bob@example.com>;tag=skduk2
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 ACK
   Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>

   Message #31

   BYE sip:bob@192.0.2.2;transport=tcp SIP/2.0
   To: Bob <sip:bob@example.com>;tag=skduk2
   From: Alice <sip:alice@a.example>;tag=02935
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 2 BYE
   Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>

9.4.  Re-Registration

   Somewhat later, Bob's UA sends keep-alives to both its edge proxies,
   but it discovers that the flow with EP1 failed.  Bob's UA re-
   registers through EP1 using the same reg-id and Call-ID it previously
   used.

Top      Up      ToC       Page 38 
     Bob         EP1   EP2     Proxy     Alice
      |           |     |        |         |
   35)|------2CRLF----->|        |         |
   36)|<------CRLF------|        |         |
   37)|--2CRLF->X |     |        |         |
      |           |     |        |         |
   38)|-REGISTER->|     |        |         |
   39)|           |---REGISTER-->|         |
   40)|           |<----200 OK---|         |
   41)|<-200 OK---|     |        |         |
      |           |     |        |         |

   Message #38

   REGISTER sip:example.com SIP/2.0
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>
   Call-ID: 16CB75F21C70
   CSeq: 2 REGISTER
   Supported: path, outbound
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"

   In message #39, EP1 inserts a Path header with a new flow token:

   Path: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr;ob>

9.5.  Outgoing Call

   Finally, Bob makes an outgoing call to Alice.  Bob's UA includes an
   "ob" parameter in its Contact URI in message #42.  EP1 adds a Record-
   Route with a flow-token in message #43.  The route-set is returned to
   Bob in the response (messages #45, 46, and 47), and either Bob or
   Alice can send in-dialog requests.

Top      Up      ToC       Page 39 
     Bob         EP1   EP2     Proxy     Alice
      |           |     |        |         |
   42)|--INVITE-->|     |        |         |
   43)|           |---INVITE---->|         |
   44)|           |     |        |-INVITE->|
   45)|           |     |        |<--200---|
   46)|           |<----200 OK---|         |
   47)|<-200 OK---|     |        |         |
   48)|--ACK----->|     |        |         |
   49)|           |-----ACK--------------->|
      |           |     |        |         |
   50)|-- BYE---->|     |        |         |
   51)|           |-----------BYE--------->|
   52)|           |<----------200 OK-------|
   53)|<--200 OK--|     |        |         |
      |           |     |        |         |

   Message #42

   INVITE sip:alice@a.example SIP/2.0
   From: Bob <sip:bob@example.com>;tag=ldw22z
   To: Alice <sip:alice@a.example>
   Call-ID: 95KGsk2V/Eis9LcpBYy3
   CSeq: 1 INVITE
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:bob@192.0.2.2;transport=tcp;ob>

   In message #43, EP1 adds the following Record-Route header.

   Record-Route:
     <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>

   When EP1 receives the BYE (message #50) from Bob's UA, it can tell
   that the request is an "outgoing" request (since the source of the
   request matches the flow in the flow token) and simply deletes its
   Route header field value and forwards the request on to Alice's UA.

   Message #50

   BYE sip:alice@a.example SIP/2.0
   From: Bob <sip:bob@example.com>;tag=ldw22z
   To: Alice <sip:alice@a.example>;tag=plqus8
   Call-ID: 95KGsk2V/Eis9LcpBYy3
   CSeq: 2 BYE
   Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
   Contact: <sip:bob@192.0.2.2;transport=tcp;ob>

Top      Up      ToC       Page 40 
10.  Grammar

   This specification defines a new header field "Flow-Timer", and new
   Contact header field parameters, "reg-id" and "+sip.instance".  The
   grammar includes the definitions from [RFC3261].  Flow-Timer is an
   extension-header from the message-header in the [RFC3261] ABNF.

   The ABNF [RFC5234] is:

    Flow-Timer     = "Flow-Timer" HCOLON 1*DIGIT

    contact-params =/ c-p-reg / c-p-instance

    c-p-reg        = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)

    c-p-instance   =  "+sip.instance" EQUAL
                      DQUOTE "<" instance-val ">" DQUOTE

    instance-val   = 1*uric ; defined in RFC 3261

   The value of the reg-id MUST NOT be 0 and MUST be less than 2^31.

11.  IANA Considerations

11.1.  Flow-Timer Header Field

   This specification defines a new SIP header field "Flow-Timer" whose
   syntax is defined in Section 10.

     Header Name        compact    Reference
     -----------------  -------    ---------
     Flow-Timer                    [RFC5626]

11.2.  "reg-id" Contact Header Field Parameter

   This specification defines a new Contact header field parameter
   called reg-id in the "Header Field Parameters and Parameter Values"
   sub-registry as per the registry created by [RFC3968].  The syntax is
   defined in Section 10.  The required information is:

                                                  Predefined
   Header Field            Parameter Name         Values      Reference
   ----------------------  ---------------------  ----------  ---------
   Contact                 reg-id                 No          [RFC5626]

Top      Up      ToC       Page 41 
11.3.  SIP/SIPS URI Parameters

   This specification augments the "SIP/SIPS URI Parameters" sub-
   registry as per the registry created by [RFC3969].  The required
   information is:

   Parameter Name     Predefined Values     Reference
   --------------     -----------------     ---------
   ob                 No                    [RFC5626]

11.4.  SIP Option Tag

   This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of [RFC3261].

   Name:  outbound

   Description:  This option-tag is used to identify UAs and registrars
      that support extensions for Client-Initiated Connections.  A UA
      places this option in a Supported header to communicate its
      support for this extension.  A registrar places this option-tag in
      a Require header to indicate to the registering User Agent that
      the registrar used registrations using the binding rules defined
      in this extension.

11.5.  430 (Flow Failed) Response Code

   This document registers a new SIP response code (430 Flow Failed), as
   per the guidelines in Section 27.4 of [RFC3261].  This response code
   is used by an edge proxy to indicate to the Authoritative Proxy that
   a specific flow to a UA instance has failed.  Other flows to the same
   instance could still succeed.  The Authoritative Proxy SHOULD attempt
   to forward to another target (flow) with the same instance-id and
   AOR.  Endpoints should never receive a 430 response.  If an endpoint
   receives a 430 response, it should treat it as a 400 (Bad Request)
   per normal procedures, as in Section 8.1.3.2 of [RFC3261].  This
   response code is defined by the following information, which has been
   added to the method and response-code sub-registry under the SIP
   Parameters registry.

     Response Code                               Reference
     ------------------------------------------  ---------
     Request Failure 4xx
       430 Flow Failed                           [RFC5626]

Top      Up      ToC       Page 42 
11.6.  439 (First Hop Lacks Outbound Support) Response Code

   This document registers a new SIP response code (439 First Hop Lacks
   Outbound Support), as per the guidelines in Section 27.4 of
   [RFC3261].  This response code is used by a registrar to indicate
   that it supports the 'outbound' feature described in this
   specification, but that the first outbound proxy that the user is
   attempting to register through does not.  Note that this response
   code is only appropriate in the case that the registering User Agent
   advertises support for outbound processing by including the outbound
   option tag in a Supported header field.  Proxies MUST NOT send a 439
   response to any requests that do not contain a "reg-id" parameter and
   an outbound option tag in a Supported header field.  This response
   code is defined by the following information, which has been added to
   the method and response-code sub-registry under the SIP Parameters
   registry.

     Response Code                               Reference
     ------------------------------------------  ---------
     Request Failure 4xx
       439 First Hop Lacks Outbound Support      [RFC&rfc.number;]

11.7.  Media Feature Tag

   This section registers a new media feature tag, per the procedures
   defined in [RFC2506].  The tag is placed into the sip tree, which is
   defined in [RFC3840].

   Media feature tag name:  sip.instance

   ASN.1 Identifier:  23

   Summary of the media feature indicated by this tag:  This feature tag
      contains a string containing a URN that indicates a unique
      identifier associated with the UA instance registering the
      Contact.

   Values appropriate for use with this feature tag:  String (equality
      relationship).

   The feature tag is intended primarily for use in the following
      applications, protocols, services, or negotiation mechanisms:
      This feature tag is most useful in a communications application,
      for describing the capabilities of a device, such as a phone or
      PDA.

   Examples of typical use:  Routing a call to a specific device.

Top      Up      ToC       Page 43 
   Related standards or documents:  RFC 5626

   Security Considerations:  This media feature tag can be used in ways
      which affect application behaviors.  For example, the SIP caller
      preferences extension [RFC3841] allows for call routing decisions
      to be based on the values of these parameters.  Therefore, if an
      attacker can modify the values of this tag, they might be able to
      affect the behavior of applications.  As a result, applications
      that utilize this media feature tag SHOULD provide a means for
      ensuring its integrity.  Similarly, this feature tag should only
      be trusted as valid when it comes from the user or User Agent
      described by the tag.  As a result, protocols for conveying this
      feature tag SHOULD provide a mechanism for guaranteeing
      authenticity.

12.  Security Considerations

   One of the key security concerns in this work is making sure that an
   attacker cannot hijack the sessions of a valid user and cause all
   calls destined to that user to be sent to the attacker.  Note that
   the intent is not to prevent existing active attacks on SIP UDP and
   TCP traffic, but to ensure that no new attacks are added by
   introducing the outbound mechanism.

   The simple case is when there are no edge proxies.  In this case, the
   only time an entry can be added to the routing for a given AOR is
   when the registration succeeds.  SIP already protects against
   attackers being able to successfully register, and this scheme relies
   on that security.  Some implementers have considered the idea of just
   saving the instance-id without relating it to the AOR with which it
   registered.  This idea will not work because an attacker's UA can
   impersonate a valid user's instance-id and hijack that user's calls.

   The more complex case involves one or more edge proxies.  When a UA
   sends a REGISTER request through an edge proxy on to the registrar,
   the edge proxy inserts a Path header field value.  If the
   registration is successfully authenticated, the registrar stores the
   value of the Path header field.  Later, when the registrar forwards a
   request destined for the UA, it copies the stored value of the Path
   header field into the Route header field of the request and forwards
   the request to the edge proxy.

   The only time an edge proxy will route over a particular flow is when
   it has received a Route header that has the flow identifier
   information that it has created.  An incoming request would have
   gotten this information from the registrar.  The registrar will only
   save this information for a given AOR if the registration for the AOR
   has been successful; and the registration will only be successful if

Top      Up      ToC       Page 44 
   the UA can correctly authenticate.  Even if an attacker has spoofed
   some bad information in the Path header sent to the registrar, the
   attacker will not be able to get the registrar to accept this
   information for an AOR that does not belong to the attacker.  The
   registrar will not hand out this bad information to others, and
   others will not be misled into contacting the attacker.

   The Security Considerations discussed in [RFC3261] and [RFC3327] are
   also relevant to this document.  For the security considerations of
   generating flow tokens, please also see Section 5.2.  A discussion of
   preventing the avalanche restart problem is in Section 4.5.

   This document does not change the mandatory-to-implement security
   mechanisms in SIP.  User Agents are already required to implement
   Digest authentication while support of TLS is recommended; proxy
   servers are already required to implement Digest and TLS.

13.  Operational Notes on Transports

   This entire section is non-normative.

   [RFC3261] requires proxies, registrars, and User Agents to implement
   both TCP and UDP but deployments can chose which transport protocols
   they want to use.  Deployments need to be careful in choosing what
   transports to use.  Many SIP features and extensions, such as large
   presence notification bodies, result in SIP requests that can be too
   large to be reasonably transported over UDP.  [RFC3261] states that
   when a request is too large for UDP, the device sending the request
   attempts to switch over to TCP.  It is important to note that when
   using outbound, this will only work if the UA has formed both UDP and
   TCP outbound flows.  This specification allows the UA to do so, but
   in most cases it will probably make more sense for the UA to form a
   TCP outbound connection only, rather than forming both UDP and TCP
   flows.  One of the key reasons that many deployments choose not to
   use TCP has to do with the difficulty of building proxies that can
   maintain a very large number of active TCP connections.  Many
   deployments today use SIP in such a way that the messages are small
   enough that they work over UDP but they can not take advantage of all
   the functionality SIP offers.  Deployments that use only UDP outbound
   connections are going to fail with sufficiently large SIP messages.

14.  Requirements

   This specification was developed to meet the following requirements:

   1.  Must be able to detect that a UA supports these mechanisms.

   2.  Support UAs behind NATs.

Top      Up      ToC       Page 45 
   3.  Support TLS to a UA without a stable DNS name or IP address.

   4.  Detect failure of a connection and be able to correct for this.

   5.  Support many UAs simultaneously rebooting.

   6.  Support a NAT rebooting or resetting.

   7.  Minimize initial startup load on a proxy.

   8.  Support architectures with edge proxies.

15.  Acknowledgments

   Francois Audet acted as document shepherd for this document, tracking
   hundreds of comments and incorporating many grammatical fixes as well
   as prodding the editors to "get on with it".  Jonathan Rosenberg,
   Erkki Koivusalo, and Byron Campen provided many comments and useful
   text.  Dave Oran came up with the idea of using the most recent
   registration first in the proxy.  Alan Hawrylyshen co-authored the
   document that formed the initial text of this specification.
   Additionally, many of the concepts here originated at a connection
   reuse meeting at IETF 60 that included the authors, Jon Peterson,
   Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat.  The TCP
   design team consisting of Chris Boulton, Scott Lawrence, Rajnish
   Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input and text.
   Nils Ohlmeier provided many fixes and initial implementation
   experience.  In addition, thanks to the following folks for useful
   comments: Francois Audet, Flemming Andreasen, Mike Hammer, Dan Wing,
   Srivatsa Srinivasan, Dale Worely, Juha Heinanen, Eric Rescorla,
   Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel,
   Derek MacDonald, Dean Willis, and Robert Sparks.

16.  References

16.1.  Normative References

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

   [RFC2141]      Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2506]      Holtman, K., Mutz, A., and T. Hardie, "Media Feature
                  Tag Registration Procedure", BCP 31, RFC 2506,
                  March 1999.

Top      Up      ToC       Page 46 
   [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.

   [RFC3263]      Rosenberg, J. and H. Schulzrinne, "Session Initiation
                  Protocol (SIP): Locating SIP Servers", RFC 3263,
                  June 2002.

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

   [RFC3581]      Rosenberg, J. and H. Schulzrinne, "An Extension to the
                  Session Initiation Protocol (SIP) for Symmetric
                  Response Routing", RFC 3581, August 2003.

   [RFC3629]      Yergeau, F., "UTF-8, a transformation format of ISO
                  10646", STD 63, RFC 3629, November 2003.

   [RFC3840]      Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
                  "Indicating User Agent Capabilities in the Session
                  Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC3841]      Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
                  "Caller Preferences for the Session Initiation
                  Protocol (SIP)", RFC 3841, August 2004.

   [RFC3968]      Camarillo, G., "The Internet Assigned Number Authority
                  (IANA) Header Field Parameter Registry for the Session
                  Initiation Protocol (SIP)", BCP 98, RFC 3968,
                  December 2004.

   [RFC3969]      Camarillo, G., "The Internet Assigned Number Authority
                  (IANA) Uniform Resource Identifier (URI) Parameter
                  Registry for the Session Initiation Protocol (SIP)",
                  BCP 99, RFC 3969, December 2004.

   [RFC4122]      Leach, P., Mealling, M., and R. Salz, "A Universally
                  Unique IDentifier (UUID) URN Namespace", RFC 4122,
                  July 2005.

   [RFC5234]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
                  Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5389]      Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
                  "Session Traversal Utilities for NAT (STUN)",
                  RFC 5389, October 2008.

Top      Up      ToC       Page 47 
16.2.  Informative References

   [CONFIG-FMWK]  Petrie, D. and S. Channabasappa, Ed., "A Framework for
                  Session Initiation Protocol User Agent Profile
                  Delivery", Work in Progress, February 2008.

   [NAT-SCEN]     Boulton, C., Rosenberg, J., Camarillo, G., and F.
                  Audet, "Best Current Practices for NAT Traversal for
                  Client-Server SIP", Work in Progress, September 2008.

   [RFC0768]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                  August 1980.

   [RFC0793]      Postel, J., "Transmission Control Protocol", STD 7,
                  RFC 793, September 1981.

   [RFC1035]      Mockapetris, P., "Domain names - implementation and
                  specification", STD 13, RFC 1035, November 1987.

   [RFC2104]      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

   [RFC2131]      Droms, R., "Dynamic Host Configuration Protocol",
                  RFC 2131, March 1997.

   [RFC2782]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
                  for specifying the location of services (DNS SRV)",
                  RFC 2782, February 2000.

   [RFC3320]      Price, R., Bormann, C., Christoffersson, J., Hannu,
                  H., Liu, Z., and J. Rosenberg, "Signaling Compression
                  (SigComp)", RFC 3320, January 2003.

   [RFC3489]      Rosenberg, J., Weinberger, J., Huitema, C., and R.
                  Mahy, "STUN - Simple Traversal of User Datagram
                  Protocol (UDP) Through Network Address Translators
                  (NATs)", RFC 3489, March 2003.

   [RFC3986]      Berners-Lee, T., Fielding, R., and L. Masinter,
                  "Uniform Resource Identifier (URI): Generic Syntax",
                  STD 66, RFC 3986, January 2005.

   [RFC4340]      Kohler, E., Handley, M., and S. Floyd, "Datagram
                  Congestion Control Protocol (DCCP)", RFC 4340,
                  March 2006.

Top      Up      ToC       Page 48 
   [RFC4648]      Josefsson, S., "The Base16, Base32, and Base64 Data
                  Encodings", RFC 4648, October 2006.

   [RFC4960]      Stewart, R., "Stream Control Transmission Protocol",
                  RFC 4960, September 2007.

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

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

Top      Up      ToC       Page 49 
Appendix A.  Default Flow Registration Backoff Times

   The base-time used for the flow re-registration backoff times
   described in Section 4.5 are configurable.  If the base-time-all-fail
   value is set to the default of 30 seconds and the base-time-not-
   failed value is set to the default of 90 seconds, the following table
   shows the resulting amount of time the UA will wait to retry
   registration.

     +-------------------+--------------------+---------------------+
     | # of reg failures | all flows unusable | > 1 non-failed flow |
     +-------------------+--------------------+---------------------+
     | 0                 | 0 s                | 0 s                 |
     | 1                 | 30-60 s            | 90-180 s            |
     | 2                 | 1-2 min            | 3-6 min             |
     | 3                 | 2-4 min            | 6-12 min            |
     | 4                 | 4-8 min            | 12-24 min           |
     | 5                 | 8-16 min           | 15-30 min           |
     | 6 or more         | 15-30 min          | 15-30 min           |
     +-------------------+--------------------+---------------------+

Appendix B.  ABNF

   This appendix contains the ABNF defined earlier in this document.


      CRLF = CR LF
      double-CRLF = CR LF CR LF
      CR = %x0D
      LF = %x0A

      Flow-Timer     = "Flow-Timer" HCOLON 1*DIGIT

      contact-params =/ c-p-reg / c-p-instance

      c-p-reg        = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)

      c-p-instance   =  "+sip.instance" EQUAL
                        DQUOTE "<" instance-val ">" DQUOTE

      instance-val   = 1*uric ; defined in RFC 3261

Top      Up      ToC       Page 50 
Authors' Addresses

   Cullen Jennings (editor)
   Cisco Systems
   170 West Tasman Drive
   Mailstop SJC-21/2
   San Jose, CA  95134
   USA

   Phone: +1 408 902-3341
   EMail: fluffy@cisco.com


   Rohan Mahy (editor)
   Unaffiliated

   EMail: rohan@ekabal.com


   Francois Audet (editor)
   Skype Labs

   EMail: francois.audet@skypelabs.com