SIPPING WG C. Jennings, Ed. Internet-Draft Cisco Systems Expires: August 20, 2005 A. Hawrylyshen Jasomi Networks February 19, 2005 SIP Conventions for UAs with Outbound Only Connections draft-jennings-sipping-outbound-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Often with SIP a request can only be routed over an existing connection or flow, such as when there is a firewall or network address translation (NAT) device in the network path. TLS is also affected when the user agent (UA) does not have a certificate suitable for mutual TLS authentication. This draft addresses how user agents and proxies need to behave to work in these environments. Jennings & Hawrylyshen Expires August 20, 2005 [Page 1] Internet-Draft SIP with Outbound Only Connections February 2005 This work shows how existing SIP mechanisms can be used to allow the UA to register multiple times over different connections or flows and the proxies can use the instance-id in the contact header to identify that the multiple flows go to the same UA. It can then choose which flow to use to route requests to this UA. This work is being discussed on the sipping@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Single Registrar and UA . . . . . . . . . . . . . . . . . 5 4.2 Multiple Connections from a User Agent . . . . . . . . . . 7 4.3 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 9 5. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Receivers of REGISTER Requests . . . . . . . . . . . . . . 12 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Changes from 00 Version . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 11.2 Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 17 Jennings & Hawrylyshen Expires August 20, 2005 [Page 2] Internet-Draft SIP with Outbound Only Connections February 2005 1. Introduction There are many environments for SIP deployments in which the user-agent (UA) can form a connection to the Registrar or Proxy but in which the connections in the reverse sense are not possible. This can happen for several reasons. It is important to understand that most IP phones and and soft-phones get their network configurations via a host-configuration protocol such as DHCP; they typically do not have a useful name in DNS; and they definitely do not have a long-term, stable DNS name that is appropriate for binding to a certificate. It is impractical for them to have a certificate that can be used as a client-side TLS certificate. However, they do support TLS and form TLS connections to a proxy or registrar which the UA authenticates using TLS, and the server authenticates the UA using a digest challenge. Sometimes a firewall device between the UA and proxy or registrar will only allow connections in the "outbound" direction. Similarly there may be a NAT that is only capable of allowing connections in the "outbound" direction. It is worth noting that most UAs in the world are deployed behind a firewall or NAT. This document describes several concepts that are used to solve this problem using a key idea from the connection reuse draft [10]: A proxy that wishes to route a request to a particular AOR, say alice@example.com, may use any connection to Alice's UA which has been previously authenticated at an appropriate level to allow it to change the registration bindings for Alice. Secondly, for high reliability systems, the UA needs to keep a connection to the proxy or registrar that it can use at any time. This is achieved by having the UA keep multiple connections, referred to as "flows", to the proxy or registrar and using a keep alive mechanism on each flow so that the UA can detect when it has failed and establish a new one. The overall approach can be summarized simply: UAs use a keep alive mechanism to keep their flow to the proxy or registrar alive. For TCP, TLS, and other connection oriented protocols this is a burst containing a CRLF payload, and for UDP it is a STUN request over the flow. A UA can create more than one flow using multiple registrations for the same contact and AOR. The instance in the contact is used to identify the UA that a connection is associated with. A new contact parameter called flow-id is used to allow the proxy and registrar to tell the difference between a UA re-registering and registering an additional connection. The proxies keep track of the "flows" or connection mappings for successful registrations. Jennings & Hawrylyshen Expires August 20, 2005 [Page 3] Internet-Draft SIP with Outbound Only Connections February 2005 When a proxy goes to route a message to a UA for which it has a mapping, it can use any one of the flows on which a successful registration has been completed for that contact. A failure on a particular flow can be tried again on an alternate flow. 2. Requirements Must be able to detect that a UA supports these mechanisms. Support UAs behind NATs. Support UAs behind firewalls. Support TLS to a UA without stable DNS name or IP. Detect failure of connection and be able to correct for this. Support many UAs simultaneously rebooting. Support a NAT rebooting or resetting. Support proxy farms with multiple hosts for scaling and reliability purposes. Minimize initial startup load on a proxy. 3. Conventions & Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3.1 Definitions 'Edge Proxy': An Edge Proxy is any proxy that is located topologically between the registering user agent and the registrar. 'Flow': A Flow is a network protocol level connection between two endpoints that is represented by the network address of both ends and the protocol. For TCP and UDP this would include the IP addresses and ports of both ends and the protocol (TCP or UDP). With TCP, a flow would often correspond with a single file descriptor in the OS. 'Outbound Connection': An Outbound Connection is a connection between two network elements that can only be established by one party. Typically this is due to network policy from a firewall or NAT device or to issues with TLS where one end does not have a certificate that can be used as a server certificate so cannot act as a TLS server. Jennings & Hawrylyshen Expires August 20, 2005 [Page 4] Internet-Draft SIP with Outbound Only Connections February 2005 'Third party registration ': A third party registration is defined in section 10.2 of RFC 3261. It is a REGISTER request in which the value of the To header field is not the same as that of the From header field. 4. Overview Several scenarios in which this technique is useful are discussed below, including the simple collocated registrar and proxy, a user agent desiring multiple connections to a resource (for redundancy for example), and an system that uses Edge Proxies. This section explains the details of the approach while section (Section 5) has the exact details of how various elements handle messages. 4.1 Single Registrar and UA The network's topology in this example is that there is single server acting as a registrar and proxy, with which the user agent registers. +---------+ |Registrar| |Proxy | +----+----+ | | +---+--+ |User | |Agent | +------+ User Agents forming only a single connection continue to register in the normal way but include the instance identifier as described in the GRUU [8] and can also add a flow-id parameter to the Contact header field value. The flow-id parameters are used to allow the registrar to detect and avoid using invalid contacts when a UA reboots, as described later in this section. For clarity, here is an example. Alice's UA creates a new TCP flow to the registrar and sends the following register. Jennings & Hawrylyshen Expires August 20, 2005 [Page 5] Internet-Draft SIP with Outbound Only Connections February 2005 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK-bad0ce Max-Forwards: 70 From: Bob ;tag=d879h76 To: Bob Call-ID: 8921348ju72je840.204 CSeq: 1 REGISTER Contact: ; flow-id=1; ;+sip.instance="" Content-Length: 0 The registrar would, as usual, challenge this registration to authenticate the sender. When the registrar adds an entry for this contact under the AOR for Bob, the registrar also needs to form a sublist under this contact that keeps track of the flow that received this registration and the flow-id value. Later when Alice sends a request to Bob at the registrar, it acts as a proxy and follows [2] to select a contact to forward the request to. The proxy then looks and finds the flows that have registrations to this contact. It forwards the request on that flow instead of trying to form a new flow to that contact. This allows the proxy to forward a request to a particular contact down the same flow that did the registration for this AOR. If the proxy had multiple flows that all went to this contact, it could choose any one of them that had registered for this AOR and had the same instance value as the selected contact. In general, if two flows have the same flow-id value, the proxy would favor the most recently registered flow. This is so that if a UA reboots, the proxy will prefer to use the most recent flow that goes to this UA instead of trying one of the old flows which will presumably fail. The keep alive mechanism needs to detect both failure of a connection and changes to the NAT public mapping. When a residential NAT is rebooted, the UA needs to understand that its bindings are no longer valid and it needs to reregister. Simply sending keep alive packets will not detect this failure when using UDP. With connection oriented transports such as TCP or TLS, the keep alive will detect failure after a NAT reboot. Connection oriented transport failures are detected as the UA periodically sends a CRLF over the connection; if the connection has failed, a connection level error will be reported to the UA. A CRLF can be considered the beginning of the next message that will be sent and therefore this approach is backwards compatible with existing standards. The TCP KEEP_ALIVE mechanism is not used because many operating systems do not allow this to be set on a per connection basis. The keep alive mechanism for UDP is quite different. The UA needs to Jennings & Hawrylyshen Expires August 20, 2005 [Page 6] Internet-Draft SIP with Outbound Only Connections February 2005 detect when the connection is working but also when the flow definition has changed. A flow definition could change because a NAT device in the network path reboots and the resulting pubic address mapping for the UA changes. STUN [4] requests are sent over the connection that is being used for the UDP SIP traffic. The proxy or registrar acts as a STUN server on the SIP signaling port. The STUN mechanism is very robust and allows the detection of a changed IP address. It may also be possible to do this with OPTIONS messages and rport; although this approach has the advantage of being backwards compatible, it also significantly increases the load on the proxy or registrar server. If the UA detects that the connection has failed or that the flow definition has changed, it will re-register using a back-off mechanism described in Section 5.1 in order to provide congestion relief when a large number of agents simultaneously reboot. The registrar saves the instance id (as defined in GRUU [8]) and flow-id (as defined in Section 6) along with the rest of the contact Header. If the instance id and flow-id are the same as a previous registration, the proxy or registrar can decide to fork requests to these contacts' registrations in serial and to choose to use the most recently created registration first. This allows a UA that has rebooted to replace its previous registration for each flow with minimal impact on overall system load. If the TCP flow to the registrar is closed, any map entries referring to that flow must be removed. Similarly, if the registration expires, any map entries created by it need to be removed. A note about the UUID: a device like a soft-phone, when first installed, should generate a UUID [6] and then save this in persistent storage for all future use. For a device such as a hard phone, which will only ever have a single SIP UA present, the UUID can be generated at any time because it is guaranteed that no other UUID is being generated at the same time on that physical device. This means the value of the time component of the UUID can be arbitrarily selected to be any time less than the time when the device was manufactured. A time of 0 (as shown in the example) is perfectly legal as long as the device knows no other UUIDs were generated at this time. 4.2 Multiple Connections from a User Agent In this example system, the logical proxy/registrar for the domain is running on two hosts that share appropriate state and can both provide registrar and proxy functionality for the domain. The UA Jennings & Hawrylyshen Expires August 20, 2005 [Page 7] Internet-Draft SIP with Outbound Only Connections February 2005 will form connections to two of the physical hosts for the domain. +-------------------+ | Domain | | Logical Proxy/Reg | | | |+-----+ +-----+| ||Host1| |Host2|| |+-----+ +-----+| +---\------------/--+ \ / \ / \ / \ / +------+ |User | |Agent | +------+ A UA that forms two or more flows has similar behavior to a UA that forms a single connection but has some additional requirements. The UA MAY be configured with a primary and backup outbound proxy or it MAY select two flows to form using the DNS selection mechanism described in this section. The registration on each flow needs to contain the instance identifier from the GRUU mechanisms and also needs to add a different flow-id parameter to the Contact header so that the Registrar can differentiate the flows as being distinct connections from the same instance. For example, the flow-id value might be set to 1 for the primary connection and 2 for the backup connection. A UA that needs to establish multiple flows needs a way to use DNS to select candidate addresses for the formation of flows. The recommended way to do this is to look at the DNS records resulting from the algorithm described in RFC 3263 [3] and select distinct addresses from the target set. Hosts that are multi-homed can avoid complications by ensuring that interfaces that are in separate routing domains have distinct DNS names for each routing domain. Having different SRV records point to the same host record should also be avoided when deploying proxies. Multiple interfaces in a single network should either be absent from DNS or preferably share an address. These guidelines will help prevent a UA from establishing flows that connect to the same resource and thereby unintentionally eliminating the desired redundancy. When a proxy goes to route a call to a particular contact, it can use Jennings & Hawrylyshen Expires August 20, 2005 [Page 8] Internet-Draft SIP with Outbound Only Connections February 2005 the flow for any registration to that contact that has the same instance value of the selected contact. If it detects that a flow has failed, it needs to remove that mapping and use the others. 4.3 Edge Proxies Some SIP deployments use edge proxies such that the UA sends the REGISTER to an edge proxy that then forwards the REGISTER to the Registrar. The edge proxy can include a path header as defined in RFC 3327 [9] so that when the registrar later retargets a request to this UA, the request is routed through the edge proxy. +---------+ |Registrar| |Proxy | +---------+ / \ / \ +-----+ +-----+ |Edge1| |Edge2| +-----+ +-----+ \ / \ / \ / \ / \ / +------+ |User | |Agent | +------+ These systems can use effectively the same mechanism as described in the previous sections but need to use the Path header. When the edge proxy receives a registration, it needs to create an identifier value that is unique to this AOR, contact, flow, and instance-id and put this identifier in the path header. This is done by putting the value in the user portion of a loose route in the path header. If the registration succeeds, the edge proxy needs to map future requests that are routed to the identifier value that was put in the path header to the associated flow. The edge proxy needs to ensure that a 200 response to a register request represents a successful registration and not some spoofed traffic to the edge proxy. One way this can be done is by ensuring that it only pays attention to responses received over a TLS connection from a proxy that is authoritative for the domain of the registration. As an alternative to actually storing the state for the mapping in the edge proxy, the proxy can form an encrypted version of the flow Jennings & Hawrylyshen Expires August 20, 2005 [Page 9] Internet-Draft SIP with Outbound Only Connections February 2005 identifier and put it in the path header so that the edge proxy will get it back from the registrar at the time it needs it. 5. Mechanisms 5.1 User Agent User Agents MUST support the the instance identifier as described in the GRUU [8] mechanism. If the UA detects that the binding on a NAT has changed, it MUST treat this as a connection failure and re-register. When registration fails due to a network problem or the Registrar does not respond, the UA maintains a range value for computing when it should next attempt to register. This range value SHOULD have an initial value of 1 minute and SHOULD double after each consecutive failed registration attempt, up to a maximum of 30 minutes. When a registration fails due to network problems, the UA MUST randomly select a time to re-register that is between 50 and 100 percent of the current range value. User Agents that form two or more connections behave similarly to User Agents that form single connections but also have some additional requirements. All User Agents SHOULD support forming multiple connections. The UA MAY be configured with a primary and backup outbound proxy. It MUST support selecting at least two connections using the mechanism described in Location of SIP Servers [3]. When DNS is used, the UA finds IP addresses used for registration the normal way, but if it discovers more than one possible IP address, it SHOULD connect to two distinct addresses, among the possible IP addresses. If the UA finds multiple records that correspond to different A or AAAA records, it SHOULD select address corresponding to different A or AAAA records. Each connection MUST contain the instance identifier from the GRUU mechanisms but MUST also add a distinct flow-id parameter to the contact header field value so that the Registrar can differentiate the two connections as being from the same instance but different connections. The flow-id MAY be set to 1 for the primary connection and 2 for the backup connection. Each time the UA is rebooted, it SHOULD use the same flow-id values it previously used. On connection oriented transports such as TCP or TLS, if no other traffic has been sent for 600 seconds, then the UA MUST send a CRLF to detect whether the connection has failed. On UDP connections, the UA MUST send a STUN [4] request every 30 seconds over the same flow as the SIP signaling. If the UA detects that the flow has changed, it MUST reregister. The text in this section does not apply to third party registration. Jennings & Hawrylyshen Expires August 20, 2005 [Page 10] Internet-Draft SIP with Outbound Only Connections February 2005 A UA doing third party registration would proceed as described in RFC 3261. User Agents that form flows with stream oriented protocols such as TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection to detect liveness of the flow. It is RECOMMENDED that a CRLF be sent if the flow has not had any data sent or received in the previous 600 seconds. The UA SHOULD not send a CRLF if data has been sent or received in the previous 30 seconds. User Agents that form flows with UDP SHOULD perform STUN requests over the flow every 30 seconds. If the mapped address in the STUN response changes, the UA must treat this as a transport error on the flow. This will cause the UA to form a new registration on a new flow. 5.2 Registrar The registrar MUST check if the registration is a 3rd party registration. If so it would process it normally and none of the other text in this section would apply. When a registrar receives a registration that does not contain a path header, it processes the registration as normal; and if the registration is successful, the registrar MUST store the flow-id, instance value and reference to the flow to a list that is maintained for this particular AOR and contact. The reference to flow is the information it needs to send a message back to the UA over this same flow. Typically it would be something like the file descriptor for TCP or the full source and destination addresses and ports for UDP. This document does not require a registrar to support the path header, but if registrar does there is some special processing based on the path header. Specifically, when a registrar that supports path receives a registration that contains a path header, the registrar still stores the instance value and flow id but does not save the reference information to the flow. When the registrar, acting as a proxy, proxies a request to a particular contact, it selects a contact to use in the normal way. Next the registrar selects a flow to reach this contact. It forms the list of possible flows by looking at the contacts registered for this AOR and selecting the ones that have the same instance value. The registrar MAY decide, when two flows have the same flow-id, to choose the one that registered most recently. Once a flow is selected, the registrar needs to forward to that flow. If a path header was used for the registration of that flow, the registrar populates the request in the normal way and forwards it. If there Jennings & Hawrylyshen Expires August 20, 2005 [Page 11] Internet-Draft SIP with Outbound Only Connections February 2005 was no path header, then the registrar looks at the flow reference information for that flow and forwards the request over the same flow that was used to receive the registration. If the registrar receives a transport level error using this flow, it must remove the flow and any associated registration information. 5.3 Edge Proxy When an edge proxy receives a registration request that does not contain a path header, it MUST form a registration identifier that is unique to this flow and then include that identifier in the path header it adds to the registration. This is done by inserting the unique identifier in the user portion of the path header URI for this edge proxy. If the edge proxy receives a request that is routed to a registration identifier that it has created, then it MUST forward the request on the flow that created the registration. This can be implemented either by storing the mapping from the unique identifier to the flow when the identifier is created or, if the edge proxy does not wish to save this state information, it can take the flow reference information and encrypt it with a secret known only to the edge proxy and put it in the user portion of the path header. Later when the edge proxy receives a request, it can decrypt this information and use it to route the request over the correct flow. The edge proxy MUST ensure that data sent from the edge proxy to the registrar or other edge proxies is integrity protected against attackers. This could be achieved by using TLS between the edge proxy and the registrar. 5.4 Receivers of REGISTER Requests A device that receives register requests directly from a UA needs to behave as specified in this section. Such devices would generally include a Registrar and and an Edge Proxy, as they both receive register requests directly from a UA. If the server receives UDP SIP requests on a given interface and port, it MUST also provide a limited version of the STUN server on the same interface and port. Specifically it MUST support all of STUN with the exception that it does not need to support STUN requests with the changed port or changed address flag set. This allows the STUN server to run with only one port and IP address. It is easy to demux STUN and SIP packets because the first byte of a STUN packet is 0 or 1 while the first byte of a SIP packet is in the Jennings & Hawrylyshen Expires August 20, 2005 [Page 12] Internet-Draft SIP with Outbound Only Connections February 2005 range of 'A' to 'Z'. 6. Grammar This specification defines a new Contact header field parameter, flow-id. The grammar for pvalue and EQUAL is obtained from RFC 3261 [2]. contact-params = c-p-q / c-p-expires / contact-extension c-p-connection c-p-connection = "flow-id" EQUAL pvalue ; defined in RFC3261 7. IANA This specification defines a new Contact header field parameter called flow-id, as per the registry created by [5]. The required information is as follows: Header field in which the parameter can appear: Contact Name of the Parameter: flow-id RFC Reference: RFC AAAA [NOTE TO IANA: Please replace AAAA with the RFC number of this specification.] 8. 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. 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 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 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 value and hijack that user's calls. The more complex case involves one or more edge proxies. The only time an edge proxy will route over a particular flow is when it has received a route header that has the instance information it has Jennings & Hawrylyshen Expires August 20, 2005 [Page 13] Internet-Draft SIP with Outbound Only Connections February 2005 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 would not be misled into contacting the attacker. 9. Changes from 00 Version Changed the behavior of the proxy so that it does not automatically remove registrations with the same instance and flow-id but instead just uses the most recently created registration first. Changed the connection-id to flow-id. Fixed expiry of edge proxies and rewrote mechanism section to be clearer. 10. Acknowledgments Rohan Mahy had the insight key to this draft, that registration can be used to authorize connection reuses. Dave Oran came up with the idea of using the most recent registration first in the proxy. The TCP design team consisting of Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input. Additionally, many of the concepts here originated at a connection reuse meeting at IETF 60 that included Jon Peterson, Jonathan Rosenberg, Paul Kyzivat and Rohan Mahy. 11. References 11.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Jennings & Hawrylyshen Expires August 20, 2005 [Page 14] Internet-Draft SIP with Outbound Only Connections February 2005 Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [5] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", draft-ietf-sip-parameter-registry-02 (work in progress), June 2004. [6] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 (work in progress), March 2004. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. [9] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. 11.2 Informative References [10] Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect-reuse-02 (work in progress), July 2004. [11] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sipping-connect-reuse-reqs-00 (work in progress), October 2002. 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 Jennings & Hawrylyshen Expires August 20, 2005 [Page 15] Internet-Draft SIP with Outbound Only Connections February 2005 Alan Hawrylyshen Jasomi Networks 310, 602 - 11 Ave SW Calgary, Alberta T2R 1J8 Canada Phone: +1 866 617 8647 EMail: alan@jasomi.com Jennings & Hawrylyshen Expires August 20, 2005 [Page 16] Internet-Draft SIP with Outbound Only Connections February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jennings & Hawrylyshen Expires August 20, 2005 [Page 17]