SIPPING Working Group X. Marjou Internet-Draft France Telecom Intended status: Best Current February 08, 2007 Practice Expires: August 12, 2007 Requirements for a Session Initiation Protocol (SIP) Transparent Back- To-Back User-Agent (B2BUA) draft-marjou-sipping-b2bua-00 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 12, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A SIP Back-To-Back User Agent (B2BUA) refers to the concatenation of a SIP User Agent Client (UAC) and a SIP User Agent Server (UAS). A transparent B2BUA is a particular type of B2BUA that forwards SIP messages in a SIP proxy-like way, and that also benefits from some features of a User Agent (UA) element. This document recommends best current practices for the implementation of such a transparent B2BUA. X. Marjou Expires August 12, 2007 [Page 1] Internet-Draft SIP B2BUAs February 2007 Developing transparent B2BUAs that meet this set of requirements will greatly increase the likelihood that SIP applications will function properly. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Features of a transparent B2BUA . . . . . . . . . . . . . . . 4 4. Best Current Practices for a Transparent B2BUA . . . . . . . . 4 4.1. Forwarding SIP Messages . . . . . . . . . . . . . . . . . 4 4.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.3. Recommendations . . . . . . . . . . . . . . . . . . . 5 4.2. Upstream and Downstream Forking . . . . . . . . . . . . . 6 4.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Recommendations . . . . . . . . . . . . . . . . . . . 6 4.3. B2BUA Forking . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.3. Recommendations . . . . . . . . . . . . . . . . . . . 7 4.4. Sending a BYE Request . . . . . . . . . . . . . . . . . . 7 4.4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 7 4.4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 4.4.3. Recommendations . . . . . . . . . . . . . . . . . . . 7 4.5. Third Party Call Control . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 X. Marjou Expires August 12, 2007 [Page 2] Internet-Draft SIP B2BUAs February 2007 1. Introduction SIP intermediaries often need to perform additional tasks that go beyond the scope of routing. Some examples of such tasks are topology hiding and network termination of dialogs, which are often implemented in application servers and session border controllers. Generally, these tasks can not be implemented with a SIP proxy element, as defined in RFC3261 [2], because the responsibility of a SIP proxy is basically limited to routing messages only. To circumvent this, the industry has adopted two different approaches: o The first one is the use of an "extended proxy": its behavior follows the SIP proxy behavior of Section 16 of [2] (i.e. the Call-Id and unknown headers are preserved when routing messages), except that it allows itself to perform additional features (e.g. can send a BYE message, can forward SIP message with a modified body, ...). o The second one is the use of a "transparent B2BUA": by nature, its behavior allows to implement UA features (e.g. can send BYE message, can generate a SIP message with any SIP body, ...). In addition, it also strives to route messages as a SIP proxy, even if many details need to be considered (e.g. when routing message, the Call-Id is modified, unknown headers are likely not to be preserved ...). The difference between the two approaches is very weak. Most of the features of a "transparent B2BUA" are possible features for an "extended proxy". Of course, if possible, a SIP proxy element should be used instead of these two approaches. Indeed, it is the single intermediary that is documented within SIP IETF specifications. This document only discusses the "transparent B2BUA" approach because it leads to a huge number of end-to-end issues, if not implemented carefully. Indeed, RFC3261 [2] only mentions that a B2BUA is a concatenation of a UAC and UAS. This apparent flexibility is also a weakness: without more accurate details, the behavior of a SIP B2BUA is not predictable. When used as a SIP intermediary between two users, a B2BUA can thus potentially stop them using many SIP features. Section 3 describes some cases that explain the proliferation of SIP B2BUA elements instead of a SIP Proxy element. Ideally, these features should be implemented differently with end- to-end mechanisms, so that regular proxies would suffice. X. Marjou Expires August 12, 2007 [Page 3] Internet-Draft SIP B2BUAs February 2007 However, the situation is that the industry has widely adopted such SIP B2BUAs. This specification thus proposes some best current practices in order to mitigate end-to-end SIP issues. They are documented in Section 4. The scope of this document is limited to a specific type of B2BUA: those that basically behave as a proxy element plus the additional features of Section 3. Therefore B2BUAs acting as SIP conferencing elements or SIP relay elements are out-of-scope of this document. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [1] and indicate requirement levels for compliant implementations. 3. Features of a transparent B2BUA A transparent B2BUA element routes SIP messages as a proxy would do. However, it also takes advantage of it User Agent behavior to: o Hide user-identity, for example in the From and To header fields. o Hide topology information, for example in the Call-ID, Via, Route, Record-Route, Contact header fields. o Modify the SIP body, for example the media IP and port addresses in the SDP. o Send a BYE towards one, or even both parties, for example in prepaid applications. o Perform 3rd Party-Call Control, for example when REFER is not supported by one remote party. Note that the document on Session Border Controllers [3] already discusses the first four features more in details. 4. Best Current Practices for a Transparent B2BUA This section gives some recommendations in order that a B2BUA be as transparent as possible within a SIP network. 4.1. Forwarding SIP Messages X. Marjou Expires August 12, 2007 [Page 4] Internet-Draft SIP B2BUAs February 2007 4.1.1. Motivation In order to minimize the impact on the SIP messages exchanged between two users, the B2BUA should forward any SIP message. When forwarding a SIP message, the B2BUA should take care to preserve as many headers as possible, as well as the body. 4.1.2. Examples If a SIP INVITE message sent by Alice indicates some supported extensions (e.g. 100rel), it is important that the B2BUA forward these extensions in the SIP INVITE message sent to Bob. Otherwise, the two users will never be able to use these SIP extensions. If a SIP 200 OK of INVITE with an SDP offer is sent by Bob, it is necessary that the B2BUA forward the SIP 200 to Alice before generating the ACK request towards Alice. Otherwise, Bob's UA will never receive the SDP answer. 4.1.3. Recommendations When the UAS of the B2BUA receives an upstream SIP request, its associated UAC generates a new downstream SIP request with its new Via, Max-Forwards, Call-Id, CSeq, and Contact header fields. Route header fields of the upstream request are copied in the downstream request, except the first Route header if it is under the responsibility of the B2BUA. Record-Route header fields of the upstream request are not copied in the new downstream request, as Record-Route is only meaningful for the upstream dialog. The UAC SHOULD copy other header fields and body from the upstream request into this downstream request before sending it. When the UAC side of the B2BUA receives the downstream SIP response of a forwarded request, its associated UAS creates an upstream response (except for 100 responses). The creation of the Via, Max- Forwards, Call-Id, CSeq, Record-Route and Contact header fields follows the rules of [2]. The Record-Route header fields of the downstream response are not copied in the new upstream response, as Record-Route is meaningful for the downstream dialog. The UAS SHOULD copy other header fields and body from the downstream response into this upstream response before sending it. [[OPEN-ISSUE: which level of details is needed? Is it enough with the current description, or do we need to describe a better relationship with the Section 8 "General User Agent Behavior" of RFC3261 [2], or do we need a section similar to Section 16 "Proxy Behavior" of RFC3261 [2]? What about race conditions as done in [4]?]] X. Marjou Expires August 12, 2007 [Page 5] Internet-Draft SIP B2BUAs February 2007 [[TODO: more text is needed for the Contact header, especially on copying its parameters and the duration of its life within the B2BUA server...]] Maintaining the coherence between the 2 SIP dialogs resulting from the B2BUA traversal is under the responsibility of the B2BUA. For example, let's consider that a B2BUA has received an upstream INVITE (dialog d1) and forwarded it downstream (dialog-d2). If the B2BUA receives an upstream SUBSCRIBE with a KPML Event header field (with the dialog-d1 as parameter [5]), then the B2BUA must adjust the Event header field (with the dialog-d2 in the parameter). 4.2. Upstream and Downstream Forking 4.2.1. Motivation The B2BUA must cope with other SIP elements that may use SIP forking. Thus, a B2BUA must properly forward forked messages. 4.2.2. Examples If an upstream proxy forks a SIP INVITE message, and if some of these forked messages arrive at a server hosting a B2BUA, the server must be ready to receive requests that only differ in the Request-URI and the Via header field, and forward them all downstream. Similarly, if a downstream proxy forks, the B2BUA must be able to receive proxied responses that differ by their to-tag and forward them all upstream with different to-tags. Otherwise, if 2 SDP offer/ answer happen on the downstream side of the B2BUA, this may result by a single SDP offer with 2 SDP answer on the upstream side of the B2BUA. 4.2.3. Recommendations If the B2BUA receives forked SIP requests, it must forward all forked requests downstream. If the B2BUA receives forked SIP responses (i.e. responses with different to-tag for a previously forwarded request), it must forward upstream responses with different to-tag. 4.3. B2BUA Forking [[Note: "B2BUA Forking" may be misleading as forking is only defined for SIP proxies. Can't we find a better name?]] X. Marjou Expires August 12, 2007 [Page 6] Internet-Draft SIP B2BUAs February 2007 4.3.1. Motivation There are some cases where the B2BUA wants to perform a parallel search, which is a similar to the forking feature of a SIP proxy. 4.3.2. Example Upon receiving an INVITE from Alice, the B2BUA forwards the INVITE in parallel towards two destinations: not only to Bob, but also to a Media Server that generates an early announcement. 4.3.3. Recommendations Upon receiving a SIP request that can fork on its UAS side, a B2BUA MAY choose to forward the request in parallel to two destinations by creating two UACs. In case downstream responses with different to- tag come back to the B2BUA, it must also forward upstream responses with different to-tag. 4.4. Sending a BYE Request 4.4.1. Motivation The intermediary needs to terminate a session. 4.4.2. Examples Upon detecting a loss of connectivity with Bob, the B2BUA sends a SIP BYE message towards Alice to properly terminate the session. Implementing a prepaid services, the B2BUA needs to be able to send a SIP BYE message to Alice, and also another one to Bob. 4.4.3. Recommendations When sending a BYE on behalf of a user, the B2BUA must not try to forward associated responses. [[OPEN-POINT: there is an issue if the BYE is challenged with a 407 response.]] 4.5. Third Party Call Control [[OPEN-POINT: Do we want to discuss this feature being implemented by a B2BUA? The proposal is to include it.]] X. Marjou Expires August 12, 2007 [Page 7] Internet-Draft SIP B2BUAs February 2007 5. Security Considerations There is currently no existing mechanism to explicitly authorize a B2BUA to act on behalf of a caller or callee. However, this would be highly desirable. Indeed, acting as a UAS, a B2BUA is in fact answering a call without being the intended recipient of the call. It is largely indistinguishable from a MITM attacker. Working on an identity mechanism could mitigate this: a "good" B2BUA could be authorized to work explicitly on behalf of a user, whereas a "bad" B2BUA could be rejected, being considered as a MITM attack. Appendix A. Acknowledgements The author wishes to thank Jean Claude Le Rouzic, Paul Kyzivat, Thomas Leseney, and Youssef Chadli for their helpful discussions on this topic. 6. 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] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", draft-ietf-sipping-sbc-funcs-00.txt (work in progress), August 2006. [4] Hasebe, M., Koshiko, J., and Y. Suzuki, "Session Initiation Protocol Exceptional Procedure Examples", draft-hasebe-sipping-race-examples-02.txt (work in progress), October 2006. [5] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, Novemberber 2006. X. Marjou Expires August 12, 2007 [Page 8] Internet-Draft SIP B2BUAs February 2007 Author's Address Xavier Marjou France Telecom Rue Pierre Marzin Lannion 22300 France Email: xavier.marjou@orange-ftgroup.com X. Marjou Expires August 12, 2007 [Page 9] Internet-Draft SIP B2BUAs February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). X. Marjou Expires August 12, 2007 [Page 10]