Network Working Group T. Froment Internet-Draft C. Lebel Intended status: Best Current Alcatel-Lucent Practice February 22, 2008 Expires: August 25, 2008 Addressing Record-Route issues in the Session Initiation Protocol (SIP) draft-ietf-sip-record-route-fix-02 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Froment & Lebel Expires August 25, 2008 [Page 1] Internet-Draft SIP Record-Route fix February 2008 Abstract A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and URI parameters that could influence the routing like different transport parameters (UDP, TCP, SCTP...), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, sip to sips or IPV4 to IPV6 scenarios...), the question arises on what should be put in Record- Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. Froment & Lebel Expires August 25, 2008 [Page 2] Internet-Draft SIP Record-Route fix February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Background: multi-homed proxies . . . . . . . . . . . . . 7 3.2. Identified problems . . . . . . . . . . . . . . . . . . . 8 4. Record-Route rewriting . . . . . . . . . . . . . . . . . . . . 9 5. Double Record-Routing . . . . . . . . . . . . . . . . . . . . 10 6. Usage of Transport protocol parameter . . . . . . . . . . . . 14 6.1. UA implementations problems and recommendations . . . . . 14 6.2. Proxy implementations problems and recommendations . . . . 18 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Froment & Lebel Expires August 25, 2008 [Page 3] Internet-Draft SIP Record-Route fix February 2008 1. Introduction Over the years, it has been noticed in interoperability events like SIPIT, that many implementations had interoperability problems due to various Record-Routing issues or misinterpretations of [RFC3261], in particular when a change occurs between the incoming and outgoing sides of a proxy: transport protocol switching, "multi-homed" proxies (including IPV4 to IPV6 interface changes), sip to sips... Multiple documents have addressed the question, each of them generally providing an adequate recommendation for its specific use case, but none of them gives a general solution or provides a coherent set of clarifications: - [RFC3486], section 6, describes the double Record-Routing as an alternative to the Record-Route rewriting in responses. This document is limited in scope to the "comp=sigcomp" parameter when doing compression with SIGCOMP. - [RFC3608], section 6.2, recommends the usage of double Record- Routing instead of the rewriting solution described in [RFC3261] for "Dual-homed" proxies. Those are defined as "proxies connected to two (or more) different networks such that requests are received on one interface and proxied out through another network interface". - ID [I-D.ietf-sipping-v6-transition], section 3.1.1, mandates double Record-Routing for multi-homed proxies doing IPV4/IPV6 transitions, when the proxy inserts IP addresses. - ID [I-D.ietf-sip-sips], section 3.2.2, recommends to apply the double Record-Routing technique when a proxy has to change the scheme from sip to sips; again, the scope is limited to this use case. The observed interoperability problems can be explained by the fact that, despite these multiple documents, the RFC3261 description has not been changed, and many implementors don't support extensions like Service-Route ([RFC3608]) or SIGCOMP([RFC3486]). Indeed, why do so just for implementing a multi-home proxy or transport protocol switching basic function? This document also aims to clarify identified bugs referenced in [BUG664], [BUG734] and [BUG735]. In particular, it takes into account [BUG664] recommendation, which says that "the language that describes this, needs to clearly capture that this applies to all types of different interface on each side issues, including IPV4 on one side and IPV6 on the other". Froment & Lebel Expires August 25, 2008 [Page 4] Internet-Draft SIP Record-Route fix February 2008 This document is also following recommendations of [I-D.drage-sip-essential-correction], which describes the process for handling essential corrections to the Session Initiation Protocol. Froment & Lebel Expires August 25, 2008 [Page 5] Internet-Draft SIP Record-Route fix February 2008 2. 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 [RFC2119]. Froment & Lebel Expires August 25, 2008 [Page 6] Internet-Draft SIP Record-Route fix February 2008 3. Problem statement 3.1. Background: multi-homed proxies A multi-homed proxy is a proxy connected, like a router, to two or more different networks, with an interface into each network, such that traffic comes "in" one network and goes "out" a different one. A simple example is shown here: +-----+ | UA1 | +--+--+ | .2 10.1.1.0/25 | ----------------+---+-... | | .1 +-+-+ | P | +-+-+ | .1 | 192.0.2.1/24 ...---+------+------------------ | | .2 +--+--+ | UA2 | +--+--+ UA1 has one interface with IP address 10.1.1.2. P has two interfaces and two addresses: -- 10.1.1.1 -- 192.0.2.1 UA2 has one interface with address, 192.0.2.2. There is potentially no IP level route between UA1 and UA2; no ping; no traceroute. They live in entirely different networks. But they can still exchange SIP messages, because P is a SIP Proxy. This works in SIP because P can "record-route". Most of the time, there is still some IP connectivity between UA1 and UA2, but SIP proxy has to manage the traffic between the two different "sides", e.g. with two different IP adresses; or one side using SIGCOMP and another side not using it, etc... Froment & Lebel Expires August 25, 2008 [Page 7] Internet-Draft SIP Record-Route fix February 2008 3.2. Identified problems Handling of Record-Route header in SIP Proxies is specified by following sections of [RFC3261]: On the request processing side, [RFC3261], item 4 of section 16.6 states that: "The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. [...] The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge(such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport". Following this statement, it is not clear to decide when the proxy should really put the transport protocol parameter on the Record- Route URI. Then, this section speaks about record-route requirements when transiting from sips to non-sips. It's not clear that the section doesn't apply to TLS to non-TLS transitions where SIPS is not involved (see [BUG734]). On response processing side, [RFC3261] recommends in step 8 of section 16.7 that: "If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts. If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record- Route header field to be a SIPS URI". Indeed, [RFC3261] suggests rewriting the Record-Route header in responses, and mandates it if the request indicated "SIP:". The current text indicates that the Record-Route value MUST be modified to contain a SIPS URI when routing a response from non-TLS to TLS transports. This makes sense only if the request indicated SIPS. Hop-by-hop TLS needs to be covered separately, see [BUG735]). This list enlights the utility of rewriting and double Record-Routing techniques which apply for any multi-homed proxy use case, whenever the proxy changes its IP address, the transport parameter or the URI scheme between incoming and outgoing interfaces. This is why, these techniques are described, compared and discussed in sections 4 and 5; the specific question to put or not the transport parameter on Record-Route is then discussed in Section 6. Froment & Lebel Expires August 25, 2008 [Page 8] Internet-Draft SIP Record-Route fix February 2008 4. Record-Route rewriting As frequently outlined in IETF mailing list discussions, Record-Route rewriting in responses is not the most optimal way of handling multi- homed and transport protocol switching situations. Additionally, the consequence of doing rewriting is that the route set seen by the caller is different from the route set seen by the callee, and this has at least two negative implications: 1) Callee cannot sign the route set, because it gets edited by the proxy in the response. Consequently, end-to-end protection of the route set can not be supported by the protocol. The openness and end-to-end principles are broken... 2) Proxy must implement special "multi-homed" stateful logic. On the request phase, it goes through output interface calculation and writes the output interface into the route. It must then inspect all responses, grep for an input interface, and selectively edit them to reference the correct output interface: this is a CPU drag. Therefore this document recommends not re-writing the Record-Route. Instead, proxies SHOULD use the Double Record-Route approach as described in this document.This recommendation is not limited to scheme changing (the sip-to-sips use case), but applies to all uses of Record-Route rewriting by proxies, including transport protocol switching and multi-homed proxies. Froment & Lebel Expires August 25, 2008 [Page 9] Internet-Draft SIP Record-Route fix February 2008 5. Double Record-Routing The serious drawbacks of rewriting technique probably explain why double Record-Routing solution has consequently always been recommended in SIP extensions like [RFC3486] or [RFC3608]. This technique consists in putting as the first value, the URI of receiving interface, including schemes and/or URI parameters, and, as second value, the URI of the sending interface. When processing the response, no modification of the recorded route is required. This is completely backwards compatible with [RFC3261]. Generally speaking, the time complexity will be less in double Record-Routing since on the response, the proxy does not have to do any re-writes (and thus, no searching). When double Record-Routing, the proxy will have to handle the subsequent in-dialog request(s) as a spiral, and consequently devote some space to maintaining a transaction. In order to avoid a spiral, the proxy has to be smart and scan an extra route ahead to determine whether the request will spiral through it. If it does, it can optimize the second spiral through itself. Even though this is an implementation decision, it is much more efficient to avoid spiraling. So, it means in section 16.4, "Route Information Preprocessing" f[RFC3261], implementors can choose that proxy MAY remove two routes instead of one when using the double Record- Routing. The following example is an extension of the example given in [I-D.ietf-sipping-v6-transition]. It illustrates a basic call flow using double Record-Routing in a multi-homed IPV4 to IPV6 proxy, and annotates the dialog state on each UA. In this example, proxy P1, responsible for the domain biloxy.com, receives a request from an IPv4-only upstream client. It proxies this request to an IPv6-only downstream server. Proxy P1 is running on a dual-stack host; on the IPv4 interface, it has an address of 192.0.2.1 and on the IPv6 interface, it is configured with an address of 2001:db8::1. Froment & Lebel Expires August 25, 2008 [Page 10] Internet-Draft SIP Record-Route fix February 2008 UA1 Proxy "P1" UA2 (IPv4) (IPv4/IPv6) (IPv6) | | | | F1 INVITE | | |------------------->| F2 INVITE | | |------------------->| | 100 Trying | | |<-------------------| | | | F3 200 OK | | F4 200 OK |<-------------------| |<-------------------| | | | | | F5 ACK | | |------------------->| F6 ACK | | |------------------->| | | | | | F7 BYE | | F8 BYE |<-------------------| |<-------------------| | | F9 200 OK | | |------------------->| F10 200 OK | | |------------------->| IPV4 to IPV6 multi-homed proxy illustration UA1 P1 UA2 F1 INVITE UA1 -> P1 INVITE sip:bob@biloxi.com SIP/2.0 Route: From: Alice ;tag=1234 To: Bob Contact: F2 INVITE P1 -> UA2 INVITE sip:bob@biloxi.com SIP/2.0 Record-Route: Record-Route: From: Alice ;tag=1234 To: Bob Contact: Dialog State at UA2: Local URI = sip:bob@biloxi.com Froment & Lebel Expires August 25, 2008 [Page 11] Internet-Draft SIP Record-Route fix February 2008 Remote URI = sip:alice@atlanta.com Remote target = sip:alice@192.0.2.1 Route Set = sip:2001:db8::1;lr sip:192.0.2.254:5060:lr F3 200 OK UA2 -> P1 SIP/2.0 200 OK Record-Route: Record-Route: From: Alice ;tag=1234 To: Bob ;tag=4567 Contact: F4 200 OK P1 -> UA1 SIP/2.0 200 OK Record-Route: Record-Route: From: Alice ;tag=1234 To: Bob ;tag=4567 Contact: Dialog State at UA1: Local URI = sip:alice@atlanta.com Remote URI = sip:bob@biloxi.com Remote target = sip:bob@2001:db8::33 Route Set = sip:192.0.2.254:5060:lr sip:2001:db8::1;lr F5 ACK UA1 -> P1 ACK sip:bob@2001:db8::33 SIP/2.0 Route: Route: From: Alice ;tag=1234 To: Bob ;tag=4567 F6 ACK P1 -> UA2 ACK sip:bob@2001:db8::33 SIP/2.0 From: Alice ;tag=1234 To: Bob ;tag=4567 (both routes have been removed by the proxy) F7 BYE UA2 -> P1 BYE sip:alice@192.0.2.1 SIP/2.0 Froment & Lebel Expires August 25, 2008 [Page 12] Internet-Draft SIP Record-Route fix February 2008 Route: Route: From: Bob ;tag=4567 To: Alice ;tag=1234 F8 BYE P1 -> UA1 BYE sip:alice@192.0.2.1 SIP/2.0 From: Bob ;tag=4567 To: Alice ;tag=1234 F9 SIP/2.0 200 OK UA1 -> P1 From: Bob ;tag=4567 To: Alice ;tag=1234 F10 SIP/2.0 200 OK P1 -> UA2 From: Bob ;tag=4567 To: Alice ;tag=1234 Figure 3: Multi-homed IPV4 to IPV6 double Record-Routing illustration Froment & Lebel Expires August 25, 2008 [Page 13] Internet-Draft SIP Record-Route fix February 2008 6. Usage of Transport protocol parameter This section describes a set of problems that are related to the usage of transport protocol parameter on the Record-Route header. In some circumstances interoperability problems occur because it is not clear whether or not to include the transport parameter on the URI of the Record-Route header. This was identified as a frequent problem in past SIPIT events. [RFC3261], step 8 of section 16.7 says: "The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport." The preceding seems to confusing implementers, resulting in proxies that insert a single Record-Route without a transport parameter, resulting in the problems described in this section. 6.1. UA implementations problems and recommendations Consider the following scenario: a SIP proxy, doing TCP to UDP transport protocol switching. In this example, proxy P1, responsible for the domain biloxy.com, receives a request from Alice UA which uses TCP. It proxies this request to Bob UA which registered with a Contact specifying UDP as transport protocol. P1 thus receives an initial request from Alice in TCP and forwards it in UDP to Bob. For subsequent requests, it is expected that TCP could continue to be used between Alice and P1, and UDP between P1 and Bob, but it can not happen if numeric IP address is used and no transport parameter is set on Record-Route URI. Froment & Lebel Expires August 25, 2008 [Page 14] Internet-Draft SIP Record-Route fix February 2008 Alice ===== TCP ===== Proxy ===== UDP ===== Bob | | | | F1 INVITE | | |------------------->| F2 INVITE | | |------------------->| | 100 Trying | | |<-------------------| | | | F3 200 OK | | F4 200 OK |<-------------------| |<-------------------| | | | | | F5 ACK | | |--(sent in UDP) X-> | ACK | | |------------------->| | | | | | F6 BYE | | BYE |<-------------------| |<-------------------| | Simplified TCP to UDP proxy scenario description UA1 P1 UA2 F1 INVITE UA1 -> P1 INVITE sip:bob@biloxi.com SIP/2.0 Route: From: Alice ;tag=1234 To: Bob Contact: F2 INVITE P1 -> UA2 INVITE sip:bob@biloxi.com SIP/2.0 Record-Route: (NO transport param) From: Alice ;tag=1234 To: Bob Contact: Dialog State at UA2: Local URI = sip:bob@biloxi.com Remote URI = sip:alice@atlanta.com Remote target = sip:alice@ua1.atlanta.com;transport=tcp Route Set = sip:192.0.2.1;lr F3 200 OK UA2 -> P1 Froment & Lebel Expires August 25, 2008 [Page 15] Internet-Draft SIP Record-Route fix February 2008 SIP/2.0 200 OK Record-Route: From: Alice ;tag=1234 To: Bob ;tag=4567 Contact: F4 200 OK P1 -> UA1 SIP/2.0 200 OK Record-Route: From: Alice ;tag=1234 To: Bob ;tag=4567 Contact: Dialog State at UA1: Local URI = sip:alice@atlanta.com Remote URI = sip:bob@biloxi.com Remote target = sip:bob@ua2.biloxi.com Route Set = sip:192.0.2.1;lr F5 ACK UA1 -> P1 ACK sip:bob@ua2.biloxi.com SIP/2.0 Route: From: Alice ;tag=1234 To: Bob ;tag=4567 F6 BYE UA2 -> P1 BYE sip:alice@ua1.atlanta.com;transport=tcp SIP/2.0 Route: From: Bob ;tag=4567 To: Alice ;tag=1234 Figure 5: TCP to UDP problem illustration Since P1 Proxy does not put any transport parameter on Record-Route URI, subsequent requests of UA1, like the ACK sent in F5, will be sent according to the behaviour specified in section 12.2 (requests within a Dialog) of RFC 3261. That means that the Route set is used, and then, applying [RFC3263], the Route "sip:192.0.2.1" will resolve to a UDP transport by default (since no transport parameter is available here), and no NAPTR request will be performed since this is a numeric IP Address. In general, the interoperability problems arises when UA is trying to send the ACK: it is not ready to change its transport protocol for a mid-dialog request and just fail to do it, requiring the proxy implementor to put the transport protocol on Froment & Lebel Expires August 25, 2008 [Page 16] Internet-Draft SIP Record-Route fix February 2008 the Record-Route URI. What happen if the proxy had record-routed its logical name (e.g. p1.example.com)? if UA1 and UA2 use the same DNS server, [RFC3263] procedure would resolve to the same transport on both sides and scenario should work. However, if one of the UA sends an initial request using a different transport than the one configured in DNS, this scenario is still problematic. In practice, there are multiple situations where UAs implementations don't use logical names and NAPTR records when sending an initial request to a proxy. This happen, for instance, when: 1) UAs offer the ability to "choose" the transport to be used for initial requests, even if they support [RFC3263]. This is a frequent UA functionnality which is justified by the following use cases: - when it is not possible to change DNS server configuration and implementation don't support all the transport protocols that could be configured by default in DNS (e.g.: TLS). - when tester or user wants to choose his transport protocol for whatever reason. e.g: need to force TCP, avoiding UDP / congestion, retransmissions or fragmentation... This usage SHOULD be avoided, because forcing the transport protocol in the configuration of an outbound proxy means that [RFC3263] procedure is bypassed for initial requests, but if the proxy Record- Routed with no transport parameter as recommended in [RFC3261], then, the UA will anyway be forced to use the [RFC3263]-preferred transport for subsequent requests. 2) UAs decide to always keep the same transport for a given Dialog. This choice is erratic, since if the proxy is not record-routing, the callee MAY receive the subsequent request through a transport that is not the one put in its Contact. If a UA really wants to avoid transport protocol switching between initial and subsequent request, it SHOULD rely on DNS records for that, and thus it SHOULD avoid configuring statically the outbound proxy with a numeric IP address: a logical name, with no transport parameter SHOULD be used instead. 3) UAs don't support [RFC3263] at all, or don't have any DNS server available. In that case, as illustrated previously, forcing UA1 to switch from TCP to UDP between initial request and subsequent request(s) is clearly not the desired default behaviour, and it typically leads to interoperability problems. UA implementations SHOULD then be ready to change the transport protocol between initial and subsequent requests. Froment & Lebel Expires August 25, 2008 [Page 17] Internet-Draft SIP Record-Route fix February 2008 6.2. Proxy implementations problems and recommendations In order to prevent UA implementation problems, and to maintain a reasonnable level of interoperability, situation can be improved on proxy side. The proxy MAY then put a transport parameter on Record- Route URIs, and MAY use either rewriting or double record-route techniques if transport protocol changed between its incoming and outgoing sides. As an illustration on previous example, it means one of the following processing will be performed: - Record-Route rewriting on responses: proxy puts the transport parameter on the Record-Route of INVITE request sent in F2. Doing so, UA2 will correctly send its BYE request in F6 using the same transport protocol as previous messages of the same dialog. Proxy rewrites the Record-Route when processing the 200 OK response, changing "on the fly" the transport parameter to "transport=tcp", so that the Route set will appear to be for UA1 and for UA2. - Double Record-Routing: the proxy puts two Record-Route headers. The first one is set, in this example, to Record-Route: , the second one to Record-Route: with no transport, or with transport=udp, which means basically the same thing. This is a common practice in proxy implementations to support double Record-Route AND put the transport parameters on Record-Route URI. This practice is acceptable as long as all SIP elements that MAY be in the path of subsequent requests support that transport. This restriction needs an explanation: let's imagine you have two proxies "P1" and "P2" on the path of an initial request. P1 is record-route and changes the transport from UDP to SCTP because P2 URI resolves to SCTP transport applying [RFC3263], and consequently decides to put two Record-Route, one with P1;transport=udp, another one with P1;transport=sctp. The problem arises if P2 is not record-route, because the next SIP element after P2 will be asked to reach P1 using SCTP transport protocol for any subsequent request from callee, and this SIP element MAY NOT support that transport. In order to handle this situation, this document recommends that a proxy SHOULD put a Record-Route header as soon as it changes the transport protocol parameter between its incoming and outgoing sides. By extension, a proxy SHOULD also put a Record-Route header for any multi-homed situation (as the ones described in this document; scheme changes, sigcomp, IPv4/IPv6...) that MAY impact the processing of proxies being on the path of subsequent requests. Froment & Lebel Expires August 25, 2008 [Page 18] Internet-Draft SIP Record-Route fix February 2008 7. Conclusion As a conclusion of this document, it is to notice that: - Record-Route rewriting is presented as a technique that MAY be used, with the drawbacks outlined in section 4. - Double record-routing is presented as the technique that SHOULD be used, and documented in section 5. - Record-Route header interoperability problems on transport protocol switching scenarios have been outlined and described in section 6. This last section gives some recommendations to UA and proxy implementations to improve the situation. Froment & Lebel Expires August 25, 2008 [Page 19] Internet-Draft SIP Record-Route fix February 2008 8. IANA Considerations This document does not require any actions by IANA. Froment & Lebel Expires August 25, 2008 [Page 20] Internet-Draft SIP Record-Route fix February 2008 9. Security Considerations The double Record-Routing technique reveals some level of network topology and proxy server capabilities: IPv4 and IPv6 support, SCTP support, sigcomp support, etc. to a malicious attacker. This is a bit more than the normal IP address, naming scheme information that is usually part and parcel of every SIP request sent out in the clear. It MAY have an impact on services involving topology hidding or privacy, as specified in [RFC3323]. Froment & Lebel Expires August 25, 2008 [Page 21] Internet-Draft SIP Record-Route fix February 2008 10. Acknowledgments Dean Willis who contributed, through the mailing lists, to most of the problem statement elements and helped a lot to fix the nits in the document. Vijay K. Gurbani who provided important references and substantial modifications, also raising security considerations. Robert Sparks and Juha Heinanen for mailing list contributions. Tom Batsele who helped to clarify the transport protocol switching issues. Ben Bonnaerens for a very attentive review of text and examples, as well as good suggestions. Joel Repiquet, Jonathan Rosenberg and Cullen Jennings for their reviews and comments. Froment & Lebel Expires August 25, 2008 [Page 22] Internet-Draft SIP Record-Route fix February 2008 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 11.2. Informative References [BUG664] Sparks, RS., "Bug 664: Double record routing, http://bugs.sipit.net/show_bug.cgi?id=664", October 2002. [BUG734] Sparks, RS., "Bug 734: Record-route manipulation rules for requests wrt SIPS vs single-hop TLS are unclear, http://bugs.sipit.net/show_bug.cgi?id=734", September 2003. [BUG735] Sparks, RS., "Bug 735: Record-route manipulation rules for responses wrt SIPS vs hop-hop TLS are incorrect, http://bugs.sipit.net/show_bug.cgi?id=735", September 2003. [I-D.drage-sip-essential-correction] Drage, K., "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", draft-drage-sip-essential-correction-02 (work in progress), November 2007. [I-D.ietf-sip-sips] Audet, F., "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", draft-ietf-sip-sips-07 (work in progress), November 2007. [I-D.ietf-sipping-v6-transition] Camarillo, G., "IPv6 Transition in the Session Initiation Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work in progress), August 2007. [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. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Froment & Lebel Expires August 25, 2008 [Page 23] Internet-Draft SIP Record-Route fix February 2008 Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003. [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. Froment & Lebel Expires August 25, 2008 [Page 24] Internet-Draft SIP Record-Route fix February 2008 Authors' Addresses Thomas Froment Alcatel-Lucent Centre de Villarceaux, Route de Villejust Nozay, Paris 91620 France Email: Thomas.Froment@alcatel-lucent.fr Christophe Lebel Alcatel-Lucent Lieu dit Le Mail Orvault, 44708 France Email: Christophe.Lebel@alcatel-lucent.fr Froment & Lebel Expires August 25, 2008 [Page 25] Internet-Draft SIP Record-Route fix February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Froment & Lebel Expires August 25, 2008 [Page 26]