Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5626

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

Pages: 50
Proposed Standard
Updates:  32613327
Part 3 of 3 – Pages 30 to 50
First   Prev   None

Top   ToC   RFC5626 - Page 30   prevText

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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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   ToC   RFC5626 - 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