draft-ietf-sip-outbound-15.txt   draft-ietf-sip-outbound-16.txt 
Network Working Group C. Jennings, Ed. Network Working Group C. Jennings, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 3261,3327 R. Mahy, Ed. Updates: 3261,3327 R. Mahy, Ed.
(if approved) Plantronics (if approved) Plantronics
Intended status: Standards Track June 12, 2008 Intended status: Standards Track October 29, 2008
Expires: December 14, 2008 Expires: May 2, 2009
Managing Client Initiated Connections in the Session Initiation Protocol Managing Client Initiated Connections in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sip-outbound-15 draft-ietf-sip-outbound-16
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2008. This Internet-Draft will expire on May 2, 2009.
Abstract Abstract
The Session Initiation Protocol (SIP) allows proxy servers to The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections or to send asynchronous UDP datagrams to initiate TCP connections or to send asynchronous UDP datagrams to
User Agents in order to deliver requests. However, in a large number User Agents in order to deliver requests. However, in a large number
of real deployments, many practical considerations, such as the of real deployments, many practical considerations, such as the
existence of firewalls and Network Address Translators (NATs) or the existence of firewalls and Network Address Translators (NATs) or the
use of TLS with server-provided certificates, prevent servers from use of TLS with server-provided certificates, prevent servers from
connecting to User Agents in this way. This specification defines connecting to User Agents in this way. This specification defines
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14 4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14
4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 16 4.2.2. Subsequent REGISTER requests . . . . . . . . . . . . . 16
4.2.3. Non Outbound Registrations . . . . . . . . . . . . . . 16 4.2.3. Non Outbound Registrations . . . . . . . . . . . . . . 16
4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 16 4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 16
4.4. Keep-alives and Detecting Flow Failure . . . . . . . . . . 17 4.4. Keep-alives and Detecting Flow Failure . . . . . . . . . . 17
4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 18 4.4.1. Keep alive with CRLF . . . . . . . . . . . . . . . . . 18
4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 19 4.4.2. Keep alive with STUN . . . . . . . . . . . . . . . . . 19
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 20
5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 21 5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 21
5.1. Processing Register Requests . . . . . . . . . . . . . . . 21 5.1. Processing Register Requests . . . . . . . . . . . . . . . 21
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 21 5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 22
5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 22 5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 22
5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 22 5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 22
5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 23 5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 23
5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . . 23 5.4. Edge Proxy Keep alive Handling . . . . . . . . . . . . . . 23
6. Registrar Procedures . . . . . . . . . . . . . . . . . . . . . 24 6. Registrar Procedures . . . . . . . . . . . . . . . . . . . . . 24
7. Authoritative Proxy Procedures: Forwarding Requests . . . . . 26 7. Authoritative Proxy Procedures: Forwarding Requests . . . . . 26
8. STUN Keep alive Processing . . . . . . . . . . . . . . . . . . 26 8. STUN Keep alive Processing . . . . . . . . . . . . . . . . . . 27
8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . . 28 8.1. Use with Sigcomp . . . . . . . . . . . . . . . . . . . . . 28
9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 28 9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 28
9.1. Subscription to configuration package . . . . . . . . . . 28 9.1. Subscription to configuration package . . . . . . . . . . 28
9.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Incoming call and proxy crash . . . . . . . . . . . . . . 33 9.3. Incoming call and proxy crash . . . . . . . . . . . . . . 33
9.4. Re-registration . . . . . . . . . . . . . . . . . . . . . 36 9.4. Re-registration . . . . . . . . . . . . . . . . . . . . . 36
9.5. Outgoing call . . . . . . . . . . . . . . . . . . . . . . 36 9.5. Outgoing call . . . . . . . . . . . . . . . . . . . . . . 36
10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 38 11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 38
skipping to change at page 17, line 7 skipping to change at page 17, line 7
described in [RFC3263]) to find a protocol, IP address, and port. described in [RFC3263]) to find a protocol, IP address, and port.
For protocols that don't use TLS, if the UAC has an existing flow to For protocols that don't use TLS, if the UAC has an existing flow to
this IP address, and port with the correct protocol, then the UAC this IP address, and port with the correct protocol, then the UAC
MUST use the existing connection. For TLS protocols, there MUST also MUST use the existing connection. For TLS protocols, there MUST also
be a match between the host production in the next hop and one of the be a match between the host production in the next hop and one of the
URIs contained in the subjectAltName in the peer certificate. If the URIs contained in the subjectAltName in the peer certificate. If the
UAC cannot use one of the existing flows, then it SHOULD form a new UAC cannot use one of the existing flows, then it SHOULD form a new
flow by sending a datagram or opening a new connection to the next flow by sending a datagram or opening a new connection to the next
hop, as appropriate for the transport protocol. hop, as appropriate for the transport protocol.
If the UAC is sending a dialog-forming request, and wants all Typically, a UAC using the procedures of this document and sending a
subsequent requests in the dialog to arrive over the same flow, the dialog-forming request will want all subsequent requests in the
UAC adds an 'ob' parameter to its Contact header. Typically this is dialog to arrive over the same flow. If the UAC is using a GRUU
desirable, but it is not necessary for example if the Contact is a [I-D.ietf-sip-gruu] that was instantiated using a Contact header
GRUU [I-D.ietf-sip-gruu]. The flow used for the request is typically field value that included an "ob" parameter, the UAC sends the
the same flow the UA registered over, but it could be a new flow, for request over the flow used for registration and susequent requests
example the initial subcription dialog for the configuration will arrive over that same flow. If the UAC is not using such a
framework [I-D.ietf-sipping-config-framework] needs to exist before GRUU, then the UAC adds an "ob" parameter to its Contact header field
registration. value. This will cause all subsequent requests in the dialog to
arrive over the flow instantiated by the dialog-forming request.
This case is typical when the request is sent prior to registration,
such as in the the initial subcription dialog for the configuration
framework [I-D.ietf-sipping-config-framework].
Note that if the UAC wants a UDP flow to work through NATs or Note that if the UAC wants a UDP flow to work through NATs or
firewalls it still needs to put the 'rport' parameter [RFC3581] in firewalls it still needs to put the 'rport' parameter [RFC3581] in
its Via header field value, and send from the port it is prepared its Via header field value, and send from the port it is prepared
to receive on. More general information about NAT traversal in to receive on. More general information about NAT traversal in
SIP is described in [I-D.ietf-sipping-nat-scenarios]. SIP is described in [I-D.ietf-sipping-nat-scenarios].
4.4. Keep-alives and Detecting Flow Failure 4.4. Keep-alives and Detecting Flow Failure
Keep alives are used for refreshing NAT/firewall bindings and Keep alives are used for refreshing NAT/firewall bindings and
skipping to change at page 24, line 28 skipping to change at page 24, line 33
the first URI does not have an ob URI parameter, then outbound the first URI does not have an ob URI parameter, then outbound
processing MUST NOT be applied to the registration. In this case, processing MUST NOT be applied to the registration. In this case,
the following processing applies: if the REGISTER request contains the following processing applies: if the REGISTER request contains
the reg-id and the outbound option tag in a Supported header field, the reg-id and the outbound option tag in a Supported header field,
then the registrar MUST respond to the REGISTER request with a 439 then the registrar MUST respond to the REGISTER request with a 439
(First Hop Lacks Outbound Support) response; otherwise, the registrar (First Hop Lacks Outbound Support) response; otherwise, the registrar
MUST ignore the reg-id parameter of the Contact header. See MUST ignore the reg-id parameter of the Contact header. See
Section 11.6 for more information on the 439 response code. Section 11.6 for more information on the 439 response code.
A Contact header field value with an instance-id media feature tag A Contact header field value with an instance-id media feature tag
but no reg-id header field parameter is valid (this combination can but no reg-id header field parameter is valid (this combination will
be used in the GRUU [I-D.ietf-sip-gruu] specification), but one with result in the creation of a GRUU, as described in GRUU
a reg-id but no instance-id is not. If the registrar processes a [I-D.ietf-sip-gruu] specification), but one with a reg-id but no
Contact header field value with a reg-id but no instance-id, it instance-id is not. If the registrar processes a Contact header
simply ignores the reg-id parameter. field value with a reg-id but no instance-id, it simply ignores the
reg-id parameter.
A registration containing a reg-id header field parameter and a non- A registration containing a reg-id header field parameter and a non-
zero expiration is used to register a single UA instance over a zero expiration is used to register a single UA instance over a
single flow, and can also de-register any Contact header fields with single flow, and can also de-register any Contact header fields with
zero expiration. Therefore if the Contact header field contains more zero expiration. Therefore if the Contact header field contains more
than one header field value with a non-zero expiration and any of than one header field value with a non-zero expiration and any of
these header field values contain a reg-id Contact header field these header field values contain a reg-id Contact header field
parameter, the entire registration SHOULD be rejected with a 400 (Bad parameter, the entire registration SHOULD be rejected with a 400 (Bad
Request) response. The justification for recommending rejection Request) response. The justification for recommending rejection
versus making it mandatory is that the receiver is allowed by versus making it mandatory is that the receiver is allowed by
skipping to change at page 44, line 5 skipping to change at page 44, line 5
Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel, Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel,
Derek MacDonald and Dean Willis. Derek MacDonald and Dean Willis.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress), draft-ietf-behave-rfc3489bis-18 (work in progress),
February 2008. July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 45, line 37 skipping to change at page 45, line 37
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery", Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress), draft-ietf-sipping-config-framework-15 (work in progress),
February 2008. February 2008.
[I-D.ietf-sipping-nat-scenarios] [I-D.ietf-sipping-nat-scenarios]
Boulton, C., Rosenberg, J., and G. Camarillo, "Best Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet,
Current Practices for NAT Traversal for SIP", "Best Current Practices for NAT Traversal for Client-
draft-ietf-sipping-nat-scenarios-08 (work in progress), Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in
April 2008. progress), September 2008.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
 End of changes. 9 change blocks. 
26 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/