One document matched: draft-marjou-sipping-b2bua-01.txt
Differences from draft-marjou-sipping-b2bua-00.txt
SIPPING Working Group X. Marjou
Internet-Draft France Telecom
Intended status: Best Current I. Elz
Practice Ericsson
Expires: January 10, 2008 P. Musgrave
CounterPath
July 9, 2007
Best Current Practices for a Session Initiation Protocol (SIP)
Transparent Back-To-Back User-Agent (B2BUA)
draft-marjou-sipping-b2bua-01
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 January 10, 2008.
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
Marjou, et al. Expires January 10, 2008 [Page 1]
Internet-Draft SIP B2BUAs July 2007
features of a User Agent (UA) element. This document recommends best
current practices for the implementation of such a transparent B2BUA.
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 . . . . . . . . 5
4.1. Forwarding SIP Messages . . . . . . . . . . . . . . . . . 5
4.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.3. Recommendations . . . . . . . . . . . . . . . . . . . 5
4.2. Forwarding SIP Messages Referencing External Dialog . . . 6
4.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Recommendations . . . . . . . . . . . . . . . . . . . 7
4.3. Upstream and Downstream Forking . . . . . . . . . . . . . 9
4.3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.3. Recommendations . . . . . . . . . . . . . . . . . . . 9
4.4. B2BUA Forking . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Example . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.3. Recommendations . . . . . . . . . . . . . . . . . . . 10
4.5. Sending a BYE Request . . . . . . . . . . . . . . . . . . 10
4.5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 10
4.5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.3. Recommendations . . . . . . . . . . . . . . . . . . . 10
4.6. Third Party Call Control . . . . . . . . . . . . . . . . . 10
4.6.1. SIP and TLS . . . . . . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Transparent B2BUA . . . . . . . . . . . . . . . . . . . . 11
5.2. B2BUA and Conferencing, mapping . . . . . . . . . . . . . 18
5.3. B2BUA and Conferencing, no mapping . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Summary of the actions done by the B2BUA . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Marjou, et al. Expires January 10, 2008 [Page 2]
Internet-Draft SIP B2BUAs July 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 so-called 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 prevent them from 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.
Marjou, et al. Expires January 10, 2008 [Page 3]
Internet-Draft SIP B2BUAs July 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
By its nature a B2BUA inserts itself into the call flow and modifies
the Call-ID. Indeed, the B2BUA is made of two User Agents: its first
UA terminates all SIP messages coming from the calling UA, and its
second UA originates all SIP messages towards the called UA.
A transparent B2BUA element is one type of B2BUA that routes SIP
messages as a proxy would do. However, being a B2BUA enables the
transparent B2BUA 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 Perform 3rd Party-Call Control, for example when REFER is not
supported by one remote party.
o Relay an out-of-dialog request towards multiple destinations at
the same time.
o Send a BYE request towards one, or even both parties, for example
in prepaid applications.
Note that the document on Session Border Controllers [3] already
discusses the first four features in more detail.
[[OPEN-POINT: The last 3 features are not transparent in the sense
that the intermediary does not only relay a SIP message, but the
intermediary also generates new messages on its own, which will
Marjou, et al. Expires January 10, 2008 [Page 4]
Internet-Draft SIP B2BUAs July 2007
seriously increase the complexity of this work. Should we keep
them?]]
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
4.1.1. Motivation
In order to minimize the impact on the SIP messages exchanged between
two users, the B2BUA should forward all SIP messages. 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, 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. Section 5.1 shows such an
example.
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 Bob. Otherwise, Bob's UA will
never receive the SDP answer.
4.1.3. Recommendations
When the UAS of the B2BUA receives a SIP request from an upstream
proxy or UA, it must check whether it supports the extensions
required that the UAC advertises in the Allow, Required, Supported,
and any other additional headers. In practice, many extensions can
be accepted transparently based on a local policy, however there
definitely are some extensions that do require some implementation
work within the B2BUA itself. For example, if a Require header field
contains the option tag 100rel, the B2BUA needs to support the PRACK
message.
If the B2BUA decides to relay the received request, its associated
UAC generates a new downstream SIP request with its new Via, Max-
Forwards, Call-ID, CSeq, and Contact header fields, as described in
RFC3261. Route header fields of the upstream request MAY be copied
in the downstream request, except the topmost Route header if it is
Marjou, et al. Expires January 10, 2008 [Page 5]
Internet-Draft SIP B2BUAs July 2007
under the responsibility of the B2BUA. Additional Route header
fields MAY also be added to the downstream request. 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.
[[TODO: discuss about OPTIONS and REGISTER messages.]]
[[[TODO: add a discussion of Path (RFC3327) in the REGISTER section]]
Some SIP messages may contain information related to other SIP
dialogs. In this case, it is important to also apply the
recommendations of Section 4.2
[[TODO: more work is needed for the Contact header: duration of its
life within the B2BUA server, GRUUs, event packages containing
contacts...]]
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 only 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]?]]
A summary of the transparency on these headers is also described in
Appendix A.
4.2. Forwarding SIP Messages Referencing External Dialog
4.2.1. Motivation
As seen in the previous section, if a B2BUA is involved in a dialog
on one side, there is another associated dialog on its other side.
This can be considered as a first level of mapping, made of two
dialogs.
Marjou, et al. Expires January 10, 2008 [Page 6]
Internet-Draft SIP B2BUAs July 2007
There is also a second level of mapping to take into account. This
happens when a SIP message contains a reference to a another B2BUA
dialog. There are two cases:
o The Request-URI of an out-of-dialog request contains a B2BUA's
contact from another dialog.
o An header field or a body of a message references another B2BUA
dialog.
* The current list of such header fields is:
+ In-Reply-To (Call-ID) [2]
+ Replaces (Call-ID, to-tag, from-tag) [5]
+ Join (Call-ID, to-tag, from-tag) [6]
+ Target-Dialog (Call-ID, local-tag, remote-tag) [7]
* The current list of such bodies is:
+ Event Package for INVITE-Initiated Dialog[8]
+ Event Package for Conference State[9]
+ Event Package for Key Press Stimulus[10]
In both cases, it is again important that the B2BUA supports these
extensions, and be able to update this dialog information.
4.2.2. Examples
Section 5.2 shows a transfer of a Point-to-Point Session into a
Conference Call Control. In this example, the B2BUA is acting on the
behalf of Alice and is systematically in the path of all SIP messages
for Alice. In this case, the B2BUA is able to update the Replaces
and the Target-Dialog header field.
Section 5.3 is the same example as the previous one except that the
B2BUA is not always in the path of Alice's messages. In this case,
Carol's UA receives a Replaces header with an unknown Call-ID. This
is eventually fixed thanks to the B2BUA involved later in the call
flow that updates the Replaces header field of the last INVITE to
Bob.
4.2.3. Recommendations
4.2.3.1. In-Reply-To header field
The In-Reply-To header field [2] does not require that the referenced
dialog still exist. This creates a specific problem for B2BUA
functionality as the use of the In-Reply-To header would require that
each B2BUA maintains a record of previous dialogs which have occurred
so that the appropriate mapping of the Call-ID in the In-Reply-To
header can occur when a new dialog using this header is received.
The issue is how long must the Call-ID mapping be maintained to
achieve this purpose, hours, days, weeks... ?
Marjou, et al. Expires January 10, 2008 [Page 7]
Internet-Draft SIP B2BUAs July 2007
Two alternatives exist for the handling of the In-Reply-To header:
o If the In-Reply-To does not match an existing dialog the B2B can
strip the In-Reply-To header.
o The B2BUA can reject the INVITE containing the In-Reply-To header
which does not match an existing dialog.
It is recommended not to use the In-Reply-To header field in networks
in which B2BUAs are deployed. If the B2BUA receives a request
containing an In-Reply-To header field value that does not match an
existing dialog, it is recommended that the B2BUA strip the
In-Reply-To header and pass on the request.
[[OPEN-POINT: From a terminal point of view, it is quite difficult
for a UA to be aware of whether or not there is a B2BUA in the
signalling path due to fact that it a man-in-the-middle device.]]
4.2.3.2. B2BUA Handling of Messages with Reference Headers
When a B2BUA receives a request creating a dialog and relays this
request, it should record the mapping information between the dialog
created on one side and the dialog created on the other side. This
information is made of the two dialogs, which include the their
different pieces (Call-ID, local tag, remote tag, local CSeq, remote
CSeq, Route-set, local contact, remote target, and secure flag).
This mapping information must be recorded until the end of the
dialog.
When the B2BUA later receives an out-of-dialog request with a
Request-URI targeting a local contact of the B2BUA, the B2BUA should
insert the remote target of the associated dialog within the Request-
URI of the outgoing request. This is done thanks to the recorded
mapping information. (c.f. example flows labeled F13 and F14 of
Section 5.3.)
When the B2BUA receives an out-of-dialog REFER request with a
Refer-To header field containing a URI related to the B2BUA, the
B2BUA should not modify the Refer-To URI, as this will be done in the
resulting referred request. (c.f. example Section 5.3).
When a B2BUA receives a message with a header field or a body
referencing a dialog related to the B2BUA, it should update the
referenced dialog (Call-ID and tags) thanks to the recorded mapping
information.
The same basic handling is used for all three reference headers with
care having to be taken with Target-Dialog as it is defined as
Call-ID, local-tag, remote-tag. This makes Target-Dialog different
from Replaces and Join (Call-ID, from-tag, to-tag) as the values used
Marjou, et al. Expires January 10, 2008 [Page 8]
Internet-Draft SIP B2BUAs July 2007
in local and remote tags may be either the to or from tags from the
original dialog. T his depends upon the direction of the new request
relative to the original request of the referenced dialog.
4.3. Upstream and Downstream Forking
4.3.1. Motivation
The B2BUA must cope with other SIP elements that may use SIP forking.
Thus, a B2BUA must properly forward forked messages.
4.3.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 a different to-tag. Otherwise, if two SDP
offer/answer happen on the downstream side of the B2BUA, this may
result in a single SDP offer with two SDP answers on the upstream
side of the B2BUA.
4.3.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 a
different to-tag for a previously forwarded request), it must forward
upstream responses with a different to-tag.
4.4. B2BUA Forking
[[Note: "B2BUA Forking" may be misleading as forking is only defined
for SIP proxies. Can't we find a better name?]]
4.4.1. Motivation
There are some cases where the B2BUA wants to perform a parallel
search, which is a feature similar to the forking feature of a SIP
proxy.
Marjou, et al. Expires January 10, 2008 [Page 9]
Internet-Draft SIP B2BUAs July 2007
4.4.2. Example
Upon receiving an INVITE from Alice to Bob, 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.4.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 multiple UACs. In case downstream responses with a
different to-tag come back to the B2BUA, it must also forward
upstream responses with a different to-tag.
4.5. Sending a BYE Request
4.5.1. Motivation
The intermediary needs to terminate a session.
4.5.2. Examples
Upon detecting a loss of connectivity with Bob, the B2BUA sends a SIP
BYE message towards Alice to properly terminate the session.
When implementing a prepaid service, the B2BUA needs to be able to
send a SIP BYE message to Alice, and also another one to Bob.
4.5.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.6. Third Party Call Control
[[OPEN-POINT: Do we want to discuss this feature being implemented by
a B2BUA? The proposal is to include it.]]
4.6.1. SIP and TLS
[[TODO: How will credentials be established? Can a call be sips on
one side of a B2B and sip on the other? ]]
Marjou, et al. Expires January 10, 2008 [Page 10]
Internet-Draft SIP B2BUAs July 2007
5. Examples
For the sake of clarity, the values chosen for the following SIP
header fields and parameters are simplified:
o branch parameter of Via
o tag parameter of From
o tag parameter of To
o sequence number of CSeq
o Call-ID
5.1. Transparent B2BUA
Marjou, et al. Expires January 10, 2008 [Page 11]
Internet-Draft SIP B2BUAs July 2007
Alice Alice's Tr. B2BUA Bob's Proxy Bob
| || | |
| F1 INVITE || | |
|--------------->|| | |
| F2 100 || | |
|<---------------|| | |
| || F3 INVITE | |
| ||--------------->| |
| || F4 100 | |
| ||<---------------| |
| || | F5 INVITE |
| || |--------------->|
| || | F6 100 |
| || |<---------------|
| || | F7 180 |
| || |<---------------|
| || F8 180 | |
| ||<---------------| |
| F9 180 || | |
|<---------------|| | |
| || | F10 200 |
| || |<---------------|
| || F11 200 | |
| ||<---------------| |
| F12 200 || | |
|<---------------|| | |
| F13 ACK || | |
|--------------->|| | |
| || F14 ACK | |
| ||--------------->| |
| || | F15 ACK |
| || |--------------->|
| || | |
| RTP flows |
|<=================================================>|
| || | |
| || | F16 BYE |
| || |<---------------|
| || F17 BYE | |
| ||<---------------| |
| F18 BYE || | |
|<---------------|| | |
| F19 200 || | |
|--------------->|| | |
| || F20 200 | |
| ||--------------->| |
| || | F21 200 |
| || |--------------->|
Marjou, et al. Expires January 10, 2008 [Page 12]
Internet-Draft SIP B2BUAs July 2007
In this example, there is a B2BUA in the path between Alice and Bob.
There is a first SIP dialog between Alice and the B2BUA. There is a
second SIP dialog between the B2BUA and Bob.
Besides the minimum required header fields, INVITE labeled F1 also
transports the Allow, Supported, and P-Visited-Network-ID header
fields. Because the B2BUA supports them, they are all transparently
copied in INVITE labeled F3.
[[OPEN-POINT: Is SDP "o=" field changed in F3 and F8?]]
F1 INVITE Alice -> B2BUA
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
Max-Forwards: 70
Route: <sip:b2bua.example.org;lr>
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>
Call-ID: 11111111
CSeq: 11 INVITE
Contact: <sip:alice@pc1.example.org>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: timer
P-Visited-Network-ID: "Visited network number 1"
Content-Type: application/sdp
Content-Length: 144
v=0
o=alice 2890844526 2890844526 IN IP4 pc1.example.org
s=-
c=IN IP4 pc1.example.org
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 100 Trying B2BUA -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>
Call-ID: 11111111
CSeq: 11 INVITE
Content-Length: 0
Marjou, et al. Expires January 10, 2008 [Page 13]
Internet-Draft SIP B2BUAs July 2007
F3 INVITE B2BUA -> Bob
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>
Call-ID: 22222222
CSeq: 22 INVITE
Contact: <sip:alice@b2bua.example.org>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: timer
P-Visited-Network-ID: "Visited network number 1"
Content-Type: application/sdp
Content-Length: 144
v=0
o=alice 2890844526 2890844526 IN IP4 pc1.example.org
s=-
c=IN IP4 pc1.example.org
t=0 0
m=audio 49202 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 100 Proxy -> B2BUA
SIP/2.0 100 Trying
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>
Call-ID: 22222222
CSeq: 22 INVITE
Content-Length: 0
F8 180 Bob -> B2BUA
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>;tag=222y
Call-ID: 22222222
Contact: <sip:bob@pc2.example.org>
Record-Route: <sip:example.org;lr>
Require: timer
Supported: timer
CSeq: 22 INVITE
Marjou, et al. Expires January 10, 2008 [Page 14]
Internet-Draft SIP B2BUAs July 2007
Content-Length: 0
F9 180 B2BUA -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>;tag=111y
Call-ID: 11111111
Contact: <sip:bob@pc1.com>
Require: timer
Supported: timer
CSeq: 11 INVITE
Content-Length: 0
F11 200 Proxy -> B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc2.example.org:5060;branch=z9hG4bK2222
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>;tag=222y
Call-ID: 22222222
CSeq: 22 INVITE
Contact: <sip:bob@pc2.example.org>
Record-Route: <sip:example.org;lr>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Require: timer
Supported: timer
Session-Expires: 4000;refresher=uac
Content-Type: application/sdp
Content-Length: 142
v=0
o=bob 1390844527 1390844527 IN IP4 pc2.example.org
s=-
c=IN IP4 pc2.example.org
t=0 0
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F12 200 B2BUA -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK1111
From: Alice <sip:alice@example.org>;tag=111x
Marjou, et al. Expires January 10, 2008 [Page 15]
Internet-Draft SIP B2BUAs July 2007
To: Bob <sip:bob@example.org>;tag=111y
Call-ID: 11111111
CSeq: 11 INVITE
Contact: <sip:bob@b2bua.example.org>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Require: timer
Supported: timer
Session-Expires: 4000;refresher=uac
Content-Type: application/sdp
Content-Length: 142
v=0
o=bob 1390844527 1390844527 IN IP4 pc2.example.org
s=-
c=IN IP4 pc2.example.org
t=0 0
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F13 ACK Alice -> B2BUA
ACK sip:bob@b2bua.example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1112
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>;tag=111y
Call-ID: 11111111
CSeq: 1 ACK
Content-Length: 0
F14 ACK B2BUA -> Proxy
ACK sip:bob@pc2.example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2223
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>;tag=222y
Call-ID: 22222222
Route: <sip:example.org;lr>
CSeq: 22 ACK
Content-Length: 0
F17 BYE Proxy -> B2BUA
BYE sip:alice@b2bua.example.org SIP/2.0
Marjou, et al. Expires January 10, 2008 [Page 16]
Internet-Draft SIP B2BUAs July 2007
Via: SIP/2.0/UDP pc2.example.org:5060;branch=z9hG4bK2224
Max-Forwards: 70
From: Bob <sip:bob@example.org>;tag=222y
To: Alice <sip:alice@example.org>;tag=222x
Call-ID: 22222222
CSeq: 222 BYE
Content-Length: 0
F18 BYE B2BUA -> Alice
BYE sip:alice@pc1.example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK1114
Max-Forwards: 70
From: Bob <sip:bob@example.org>;tag=111y
To: Alice <sip:alice@example.org>;tag=111x
Call-ID: 11111111
CSeq: 111 BYE
Content-Length: 0
F19 200 Alice -> B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1114
From: Bob <sip:bob@example.org>;tag=111y
To: Alice <sip:alice@example.org>;tag=111x
Call-ID: 11111111
CSeq: 111 BYE
Content-Length: 0
F20 200 B2BUA -> Proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK1114
From: Bob <sip:bob@example.org>;tag=222y
To: Alice <sip:alice@example.org>;tag=222x
Call-ID: 22222222
CSeq: 222 BYE
Content-Length: 0
Marjou, et al. Expires January 10, 2008 [Page 17]
Internet-Draft SIP B2BUAs July 2007
5.2. B2BUA and Conferencing, mapping
Alice Alice's Tr B2BUA Bob Carol
| || | |
| F1 INVITE (d1) || | |
|--------------->|| | |
| || F2 INVITE (d2) | |
| ||--------------->| |
| || F3 200 | |
| ||<---------------| |
| F4 200 || | |
|<---------------|| | |
| F5 ACK || | |
|--------------->|| | |
| || F6 ACK | |
| ||--------------->| |
| || | |
| F7 INVITE (d3) || | |
|--------------->|| | |
| || F8 INVITE (d4) | |
| ||-------------------------------->|
| || F9 200 |
| ||<--------------------------------|
| F10 200 || |
|<---------------|| |
| F11 ACK || |
|--------------->|| |
| || F12 ACK |
| ||-------------------------------->|
| || |
| F13 REFER (d5) || |
| Refer-To: ...?Replaces:d1 |
| Target-D:d3 || |
|--------------->|| |
| || F14 REFER (d6) |
| || Refer-To: ...?Replaces:d2 |
| || Target-D:d4 |
| ||-------------------------------->|
| || |F15 INVITE (d7) |
| || |Replaces=d2 |
| || |<---------------|
This call flow is similar to the transfer of a Point-to-Point Session
into a Conference Call Control as described in [11] (Section 5.10),
Marjou, et al. Expires January 10, 2008 [Page 18]
Internet-Draft SIP B2BUAs July 2007
where 3 dialogs exist without any B2BUA.
This example introduces a B2BUA in the path of SIP messages between
Alice, Bob and Carol, which induces three additional dialogs, namely
d2, d4, and d6. It is important to note that if the B2BUA is not
able to replace the reference to dialog d2 by a reference on dialog
d3 in the Replaces header field, F7 INVITE will fail, as dialog d2
will be unknown to Carol.
In the flow below the AOR has been used as the Request-URI when
establishing the communication between Alice and Bob and between
Alice and Carol, F1, F2, F7 & F8. When the REFER request, F13 & F14,
is sent however the Contact from the communication with Carol is used
as the Request-URI as the use of the Target-Dialog header requires
that the REFER request is directed to the terminal where the
referenced dialog exists. This is similar to sending a subsequent
request on an existing dialog. As there is a Replaces header
parameter included in the Refer-To header of the REFER the Contact
URI from the communication with Bob is used as the Refer-To URI.
This is to ensure that the subsequent INVITE, F15, generated as a
result of the REFER is directed to the UE on which the dialog to be
replaced is terminated.
For the sake of brevity, the proxy-registrar of Bob and Alice is not
described.
F1 INVITE Alice -> Alice's B2BUA
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>
Call-ID: 11111111
CSeq: 11 INVITE
Contact: <sip:alice@pc1.example.org>
Route: <sip:b2bua.example.org;lr>
Content-Type: application/sdp
Content-Length: ...
F2 INVITE Alice's B2BUA -> Bob
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
Marjou, et al. Expires January 10, 2008 [Page 19]
Internet-Draft SIP B2BUAs July 2007
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>
Call-ID: 22222222
CSeq: 22 INVITE
Contact: <sip:alice@b2bua.example.org>
Content-Type: application/sdp
Content-Length: ...
F3 200 OK Bob -> Alice's B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
From: Alice <sip:alice@pc1.example.org>;tag=222x
To: Bob <sip:bob@example.org>;tag=222y
Call-ID: 22222222
CSeq: 22 INVITE
Contact: <sip:bob@pc2.example.org>
Content-Type: application/sdp
Content-Length: ...
F4 200 OK Alice's B2BUA -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
From: Alice <sip:alice@pc1.example.org>;tag=111x
To: Bob <sip:bob@example.org>;tag=111y
Call-ID: 11111111
CSeq: 11 INVITE
Contact: <sip:bob@b2bua.example.org>
Content-Type: application/sdp
Content-Length: ...
F7 INVITE Alice -> Alice's B2BUA
INVITE sip:carol@example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK3333
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=333x
To: Carol <sip:carol@example.org>
Call-ID: 33333333
CSeq: 11 INVITE
Contact: <sip:alice@pc1.example.org>
Route: <sip:b2bua.example.org;lr>
Content-Type: application/sdp
Content-Length: ...
Marjou, et al. Expires January 10, 2008 [Page 20]
Internet-Draft SIP B2BUAs July 2007
F8 INVITE Alice's B2BUA -> Carol
INVITE sip:carol@example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK4444
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=444x
To: Carol <sip:carol@example.org>
Call-ID: 44444444
CSeq: 44 INVITE
Contact: <sip:alice@b2bua.example.org>
Content-Type: application/sdp
Content-Length: ...
F9 200 OK Carol -> Alice's B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK4444
From: Alice <sip:alice@example.org>;tag=444x
To: Carol <sip:carol@example.org>tag=444y
Call-ID: 44444444
CSeq: 44 INVITE
Contact: <sip:carol@pc3.example.org>
Content-Type: application/sdp
Content-Length: ...
F10 200 OK Alice's B2BUA -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK3333
From: Alice <sip:alice@example.org>;tag=333x
To: Carol <sip:carol@example.org>;tag=333y
Call-ID: 33333333
CSeq: 11 INVITE
Contact: <sip:carol@b2bua.example.org>
Content-Type: application/sdp
Content-Length: ...
F13 REFER Alice -> Alice's B2BUA
REFER sip:carol@b2bua.example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK5555
Max-Forwards: 70
From: Alice <alice@example.org>;tag=555x
To: Carol <sip:carol@b2bua.example.org>
Call-ID: 55555555
Marjou, et al. Expires January 10, 2008 [Page 21]
Internet-Draft SIP B2BUAs July 2007
CSeq: 2 REFER
Refer-To: <sip:bob@b2bua.example.org?Replaces=11111111
;to-tag=111y;from-tag=111x>
Target-Dialog: 33333333;local-tag=333x;remote-tag=333y
Contact: <sip:alice@pc1.example.org>
Content-Length: 0
F14 REFER Alice's B2BUA -> Carol
REFER sip:carol@pc3.example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK6666
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=666x
To: Carol <sip:carol@pc3.example.org>
Call-ID: 66666666
CSeq: 2 REFER
Refer-To: <sip:bob@pc2.example.org?Replaces=22222222
;to-tag=222y;from-tag=222x>
Target-Dialog=44444444;local-tag=444x;remote-tag=444y>
Contact: <sip:alice@b2bua.example.org>
Content-Length: 0
F15 INVITE Carol -> Bob
INVITE sip:bob@pc2.example.org SIP/2.0
Via: SIP/2.0/UDP pc3.example.org:5060;branch=z9hG4bK7777
Max-Forwards: 70
From: Carol <sip:carol@example.org>;tag=777x
To: Bob <sip:bob@pc2.example.org>
Call-ID: 77777777
CSeq: 77 INVITE
Contact: <sip:alice@b2bua.example.org>
Replaces=22222222;to-tag=222y;from-tag=222x
Content-Type: application/sdp
Content-Length: ...
5.3. B2BUA and Conferencing, no mapping
Marjou, et al. Expires January 10, 2008 [Page 22]
Internet-Draft SIP B2BUAs July 2007
Alice Alice's Tr B2BUA Bob Carol
| || | |
| F1 INVITE (d1) || | |
|--------------->|| | |
| || F2 INVITE (d2) | |
| ||--------------->| |
| || F3 200 | |
| ||<---------------| |
| F4 200 || | |
|<---------------|| | |
| F5 ACK || | |
|--------------->|| | |
| || F6 ACK | |
| ||--------------->| |
| || | |
| F7 INVITE (d3) |
|-------------------------------------------------->|
| F8 200 |
|<--------------------------------------------------|
| F9 ACK |
|-------------------------------------------------->|
| |
| F13 REFER (d4) |
| Refer-To:<bob@b2bua.example.org?Replaces:d1> |
| Target-D:d3 |
|-------------------------------------------------> |
| || F14 INVITE sip:bob@b2bua.example.org
| || Replaces: d1 |
| ||<--------------------------------|
| || F15 INVITE sip:bob@example.org |
| || Replaces: d2 | |
| ||--------------->| |
This call flow is similar to the transfer of a Point-to-Point Session
into a Conference Call Control as described in [11] (Section 5.10),
where 3 dialogs exist without any B2BUA.
This example shows a B2BUA that does not systematically receive all
SIP messages on the behalf of Alice. Indeed, INVITE labeled F7 is
not received by the B2BUA. In this case, the Refer-To and Replaces
header fields received by Carol will contain information referencing
a Contact URI and a dialog that are only known by Alice and its
B2BUA.
Nevertheless, the B2BUA later in the flow will receive the F14 INVITE
Marjou, et al. Expires January 10, 2008 [Page 23]
Internet-Draft SIP B2BUAs July 2007
and thus has the opportunity to update the F15 INVITE message.
A similar situation may also happen in case Alice's UA load-balance
SIP messages towards multiple B2BUAs that do not share the contextual
information related to the mapping of Alice's UA.
In the flow below the AOR has been used as the Request-URI when
establishing the communication between Alice and Bob and between
Alice and Carol, F1, F2, & F7. When the REFER request, F13, is sent
however the Contact from the communication with Carol is used as the
Request-URI as the use of the Target-Dialog header requires that the
REFER request is directed to the terminal where the referenced dialog
exists. This is similar to sending a subsequent request on an
existing dialog. As there is a Replaces header parameter included in
the Refer-To header of the REFER the Contact URI from the
communication with Bob is used as the Refer-To URI. This is to
ensure that the subsequent INVITE, F14 & F15, generated as a result
of the REFER is directed to the UE on which the dialog to be replaced
is terminated.
F1 INVITE Alice -> Alice's B2BUA
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>
Call-ID: 11111111
CSeq: 11 INVITE
Contact: <sip:alice@pc1.example.org>
Route: <sip:b2bua.example.org;lr>
Content-Type: application/sdp
Content-Length: ...
F2 INVITE Alice's B2BUA -> Bob
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>
Call-ID: 22222222
CSeq: 22 INVITE
Contact: <sip:alice@b2bua.example.org>
Marjou, et al. Expires January 10, 2008 [Page 24]
Internet-Draft SIP B2BUAs July 2007
Content-Type: application/sdp
Content-Length: ...
F3 200 OK Bob -> Alice's B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK2222
From: Alice <sip:alice@example.org>;tag=222x
To: Bob <sip:bob@example.org>;tag=222y
Call-ID: 22222222
CSeq: 22 INVITE
Contact: <sip:bob@pc2.example.org>
Content-Type: application/sdp
Content-Length: ...
F4 200 OK Alice's B2BUA -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK1111
From: Alice <sip:alice@example.org>;tag=111x
To: Bob <sip:bob@example.org>;tag=111y
Call-ID: 11111111
CSeq: 11 INVITE
Contact: <sip:bob@b2bua.example.org>
Content-Type: application/sdp
Content-Length: ...
F7 INVITE Alice -> Alice's B2BUA
INVITE sip:carol@example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK3333
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=333x
To: Carol <sip:carol@example.org>
Call-ID: 33333333
CSeq: 11 INVITE
Contact: <sip:alice@pc1.example.org>
Content-Type: application/sdp
Content-Length: ...
F8 200 OK Bob -> Alice's B2BUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP b2bua.example.org:5060;branch=z9hG4bK4444
Marjou, et al. Expires January 10, 2008 [Page 25]
Internet-Draft SIP B2BUAs July 2007
From: Alice <sip:alice@example.org>;tag=333x
To: Carol <sip:carol@example.org>;tag=333y
Call-ID: 33333333
CSeq: 11 INVITE
Contact: <sip:carol@pc3.example.org>
Content-Type: application/sdp
Content-Length: ...
F13 REFER Alice -> Carol
REFER sip:carol@pc3.example.org SIP/2.0
Via: SIP/2.0/UDP pc1.example.org:5060;branch=z9hG4bK5555
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=555x
To: Carol <sip:carol@pc3.example.org>
Call-ID: 55555555
CSeq: 2 REFER
Refer-To: <sip:bob@b2bua.example.org?Replaces=11111111
;to-tag=111y;from-tag=111x>
Target-Dialog: 33333333;local-tag=333x;remote-tag=333y
Contact: <sip:alice@pc1.example.org>
Content-Length: 0
F14 INVITE Carol -> Alice's B2BUA
INVITE sip:bob@b2bua.example.org SIP/2.0
Via: SIP/2.0/UDP pc3.example.org:5060;branch=z9hG4bK6666
Max-Forwards: 70
From: Carol <sip:carol@example.org>;tag=666x
To: Bob <sip:bob@b2bua.example.org>
Call-ID: 66666666
CSeq: 33 INVITE
Contact: <sip:carol@pc3.example.org>
Replaces=11111111;to-tag=111y;from-tag=111x>
Content-Type: application/sdp
Content-Length: ...
F15 INVITE Alice's B2BUA -> Bob
INVITE sip:bob@example.org SIP/2.0
Via: SIP/2.0/UDP pc3.example.org:5060;branch=z9hG4bK7777
Max-Forwards: 70
From: Carol <sip:carol@example.org>;tag=777x
To: Bob <sip:bob@example.org>
Marjou, et al. Expires January 10, 2008 [Page 26]
Internet-Draft SIP B2BUAs July 2007
Call-ID: 77777777
CSeq: 44 INVITE
Contact: <sip:carol@b2bua.example.org>
Replaces=22222222;to-tag=222y;from-tag=222x>
Content-Type: application/sdp
Content-Length: ...
6. Acknowledgements
The author wishes to thank Fan Hu, Jean Claude Le Rouzic, Paul
Kyzivat, Thomas Leseney, and Youssef Chadli for their helpful
discussions on this topic.
7. 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-03.txt (work in progress),
April 2007.
[4] Hasebe, M., Koshiko, J., Suzuki, Y., and P. Kyzivat, "Session
Initiation Protocol Exceptional Procedure Examples",
draft-ietf-sipping-race-examples-01.txt (work in progress),
March 2007.
[5] Mahy, R., Billy, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
[7] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
[8] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Marjou, et al. Expires January 10, 2008 [Page 27]
Internet-Draft SIP B2BUAs July 2007
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[9] Rosenberg, J., Schulzrinne, H., and O. Orit, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[10] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[11] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", RFC 4579,
August 2006.
Appendix A. Summary of the actions done by the B2BUA
This appendix makes a summary of the different actions that are
performed by the B2BUA upon receipt of an out-of-dialog request and
upon receipt of the associated response.
Note that the B2BUA acts as a UAS on one side and as a UAC on the
other, as defined in RFC3261 [2], but that additional details are
added in order to copy as many information from the incoming request
to the outgoing request in order to minimize the impact of the B2BUA.
Marjou, et al. Expires January 10, 2008 [Page 28]
Internet-Draft SIP B2BUAs July 2007
Header field where comments
________________________________________________________________________
Allow R,r If the B2BUA supports the allowed method, copy it
else remove the method
Call-Id R Create a new Call-Id for outgoing request
Call-Id r Map Call-Id to corresponding incoming request
Contact R Create a new local contact for outgoing request[1]
r Create a new local contact for incoming request[1]
Content-Type R,r If the body contains references to a mapped dialog
then map dialog referenced within the body [4]
CSeq R,r May be copied
From R Shoud copy name-addr,
may change name-addr if privacy is required,
generate a new tag [2].
From r Copy name-addr, and map tag
In-Reply-To R If possible Map its Call-Id, else remove it
Join R Map Call-id and tags [6]
Max-Forwards R Reset Max-Forwards when creating requests [3]
To R Copy name-addr [2]
To r Copy name-addr, generate new tag.
Record-Route R Remove headers
Route r May copy [see 4.1.3]
RequestURI R hostname and uri-parameters may require action [5]
Replaces R Map Call-Id and tags. [6]
Required R If the B2BUA support the extension, copy it
else remove the extension
Server r Replace the value with the B2BUA's value
Supported R,r If the B2BUA supports the extension, copy it
else remove the extension
Target-Dialog R Map Call-Id and tags [6]
User-Agent R Replace the value with the B2BUA's value
Via R Create a new Via header field for outgoing request
Via r Use Via from incoming request as per RFC3261
others R,r Should by default copy them
Table 1: Header modifications required by for out-of-dialog messages
R=request received by the B2BUA
r=response received by the B2BUA
Marjou, et al. Expires January 10, 2008 [Page 29]
Internet-Draft SIP B2BUAs July 2007
[1] Contact header URI parameters may require mapping.
[2] URI parameters may require mapping. (?)
[3] If the request loops back to the B2BUA with the same target there
is the potential for undetected loops. TODO: Can this be averted?
[4] Contents for event packages which reference dialogs include KPML,
INVITE initiated Dialog, Conference State.
[5] References to the B2BUA hostname are mapped to the appropriate
contact hostname. GRUU parameters require mapping. Others?
[6] Presence of these headers may require that the Request URI is
also mapped to the Contact used in the referenced dialog.
Authors' Addresses
Xavier Marjou
France Telecom
Rue Pierre Marzin
Lannion 22307
France
Email: xavier.marjou@orange-ftgroup.com
Ian Elz
Ericsson
New Century Park
Coventry CV3 1JG
United Kingdom
Email: ian.elz@ericsson.com
Peter Musgrave
CounterPath
350 Legget Drive
Ottawa K2K 2W7
Canada
Email: PMusgrave@newheights.com
Marjou, et al. Expires January 10, 2008 [Page 30]
Internet-Draft SIP B2BUAs July 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).
Marjou, et al. Expires January 10, 2008 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-24 03:17:31 |