RFC 5626
Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
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.
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
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.
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.
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,
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>
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>
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.
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.
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>
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]
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]
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.
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
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.
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.
[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.
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.
[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.
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
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