One document matched: draft-marjou-sipping-b2bua-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 21:23:14 |