Internet DRAFT - draft-izumikawa-sipping-sipbicast
draft-izumikawa-sipping-sipbicast
SIPPING Working Group H. Izumikawa
Internet-Draft KDDI Labs
Intended status: Informational R. Lillie
Expires: August 28, 2008 Motorola Labs
February 25, 2008
SIP-based Bicasting for Seamless Handover between Heterogeneous Networks
draft-izumikawa-sipping-sipbicast-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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
A vertical session handoff occurs in heterogeneous networks when a
session media is moved between access networks within the same
device. During session handoff, bi-casting media streams to both
access networks of the session's device may be desirable to insure a
seamless session handoff. This document describes the general
methods and specifies the signaling and media flows for providing
this service using the Session Initiation Protocol (SIP) [1].
Izumikawa & Lillie Expires August 28, 2008 [Page 1]
Internet-Draft SIP Session Bi-casting February 2008
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Vertical Session handoff with Media Bi-casting . . . . . . . . 6
5.1. Mobile Node controlled Vertical handoff . . . . . . . . . 7
5.2. A B2BUA Mediated Vertical handoff via Session Update . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Izumikawa & Lillie Expires August 28, 2008 [Page 2]
Internet-Draft SIP Session Bi-casting February 2008
1. Overview
A wide variety of access networks have emerged along with the
popularization of fixed/mobile data communications. Nowadays, a user
can access the Internet via several access networks using the same
device. For example, the user may use both cellular and WLAN access
as the situation demands within the same device such as a smartphone
and a laptop, e.g. cellular access on the outside, WLAN access in the
house or on the hotspot. This seems to be the trend for the
foreseeable future, i.e. we'll be surrounded by a heterogeneous
network where several access networks supplement each other. In such
heterogeneous network environments, it is important that users
utilize appropriate access network according to their location and
enjoy their services, especially IP-based multimedia communications,
with the optimal quality. In order to continue multimedia
communications with the optimal quality, a Correspondent Node (CN)
can change a destination and a communication quality by receiving the
SIP re-INVITE or the SIP UPDATE message from a Mobile Node (MN) when
the MN switches its point of attachment between access networks.
However, a real-time service can be interrupted in this case due to
the different characteristics, in the access networks, such as
throughput and latency. As compared with non-realtime services such
as web access and file-downloading, realtime multimedia services such
as voice and video can suffer degradation in a user's experience when
the service is interrupted. Therefore, it is also important to avoid
service interruption during switchover a session media between access
networks, i.e. vertical session handoff (HO). During session HO, bi-
casting media streams to both access networks of the session's device
are desirable to avoid the service disruption and insure a seamless
session handoff. In addition, bi-casting media streams can also help
adjust the service quality of the realtime service according to the
new network of attachment.
Since IP-based multimedia sessions are handled or controlled by
Session Initiation Protocol (SIP) [1], this document introduces the
general methods and specifies the signaling and media flows for
providing this service using SIP.
This document introduces a SIP-capable network element named the
Handovff Assistive Server (HOAS) which becomes a media stream bi-
casting control point and is located between UAs (i.e. MN and CN).
A number of plausible protocol flows are presented to utilize the
services of the HOAS in a heterogeneous vertical handoff. This
document does not describe the HOAS discovery process, which is
beyond the scope of this document and best addressed using various
user agent provisioning or service discovery mechanisms.
In Section 3 the requirements and constraints for media stream bi-
Izumikawa & Lillie Expires August 28, 2008 [Page 3]
Internet-Draft SIP Session Bi-casting February 2008
casting in a vertical handoff are enumerated. Section 4 introduces
the architectural elements involved in a bi-casted vertical handoff.
Section 5 presents two alternative methods for achieving vertical
session handoff with media bi-casting using HOAS assistance.
2. Terminology
This section presents a few terms used throughout the document.
o Vertical handoff: A vertical handoff refers to changing a mobile
node's point of attachment between different types of access
networks, e.g. cellular and WLAN. The feature of a vertical
handoff is that the transmission rate and latency may well differ
significantly before and after handoff, respectively.
o Bi-cast: Bi-cast refers to the splitting of a packet stream
destined to a mobile node into two streams. A mobile node
receives two streams simultaneously if the mobile node attaches
the two systems at the same time. Bi-cast is shown to be
effective in reducing packet loss during handoff.
3. Requirements
This section describes general requirements for media stream bi-
casting in a vertical handoff scenario.
o Media streams bi-casting should be realized to leverage current or
emerging practices in the SIP. In other words, a new method or an
extra header for media streams bi-casting should not be required.
This document introduces some examples leveraging Third-Party Call
Control (3PCC) [3] and SIP's UPDATE [8] methods.
o Correspondent Node (CN) should be an basic User Agent (UA) which
only has basic SIP capabilities to expand the range of application
for the media streams bi-casting.
o If HOAS has the functionality of a transcoding service, the bi-
casted streams can have respective service qualities according to
respective access systems where the MN attaches. Transcoding
combined with media stream bi-casting results in a service quality
adjustment, improving the end-user mobile experience as in [9],
when performing a vertical handoff between the heterogeneous
access networks.
Izumikawa & Lillie Expires August 28, 2008 [Page 4]
Internet-Draft SIP Session Bi-casting February 2008
4. Architecture
The assumed network architecture is illustrated in Figure 1. In this
figure, AN1 and AN2 represent alternate access networks available to
the mobile node. For example, they could represent a cellular access
network and a wireless LAN (WiFi). The HOAS represents the SIP-
enabled Handoff Assistive Server. During a vertical handoff, between
the mobile node's access networks, the preexisting bearer path
between MN and CN is switched to pass through the HOAS during the
duration of the vertical handoff. During this period of the handoff,
the HOAS performs packet replication of the media streams sent by the
CN destined to the MN, and bi-casts the replicated streams across
both access networks available to the MN. In addition, if the HOAS
is capable of performing media transcoding, the service quality of
the bi-casted streams can be adjusted to match the capabilities of
each of the MN's access networks. Traffic sent by the MN, destined
to CN, may also be simultaneously transmitted across each access
network, whereby the HOAS can discard the duplicated packets from the
MN.
Note that the CN could serve as the bi-casting service during a
vertical handoff. However, this forces the CN to have both enhanced
media and SIP signaling capabilities over and above those required by
a basic SIP client. Requiring this added functionality within a
client device would limit the applicability and deployment of
seamless vertical HO techniques employing media bicasting. As such,
the use of the CN to control the seamless handoff is beyond the scope
of this document.
Izumikawa & Lillie Expires August 28, 2008 [Page 5]
Internet-Draft SIP Session Bi-casting February 2008
+-------+
| CN |
+-------+
|
+------------------+ +----+
| Internet |-----|HOAS|
| | +----+
+------------------+
| |
/ \
/ \
+------------------+ +-----------------+
| AN1 | | AN2 |
| | | |
+------------------+ +-----------------+
\ /
\ /
\ /
\ /
+-------+
| MN |--> MH handoff from AN1 to AN2
+-------+
| Service area covered by AN2 |
+------------------------------+
| Service area covered by AN1 |
+---------------------------------------------------------+
Figure 1 - Mobile Node handoff across Heterogeneous Access Networks
Finally, it should be noted that the solutions proposed in this memo
assume that the coverage areas of the access networks AN1 and AN2
have some degree of overlap.
5. Vertical Session handoff with Media Bi-casting
Application layer mobility using SIP was examined in [10] through the
use of both Third-Party Call Control (3PCC) [3] as well as SIP's
REFER [4] method as possible solutions. More recently, [11] has
expanded upon this work and demonstrated the suitability of employing
either 3PCC or SIP's REFER request as suitable mechanisms for session
mobility between mobile devices. Similarly, 3PCC [3] has been
demonstrated in [12] as the protocol mechanism usefull for
establishing media transcoding services in a new or existing session.
Izumikawa & Lillie Expires August 28, 2008 [Page 6]
Internet-Draft SIP Session Bi-casting February 2008
Although SIP mobility [10] and the session mobility [11] can provide
a terminal mobility or a session mobility through the use of 3PCC [3]
or SIP's REFER [4] method, there can be a service interruption during
the hard swithing (handoff). Bi-cast in the uplink direction, i.e.
from an MN to a CN, is studied using SIP [13]. But this scheme does
not take account of the change in the service quality based on the
access networks. Furthermore, it requires both an extra header field
and a new parameter in the Via header field, which cannot satisfy the
first requirement described in Section 3.
As stated above, it is desirable to avoid service interruptions
during a vertical session handoff between access networks with
different service characteristics. Furthermore, it is desirable to
adapt the session's service quality in accordance with the capability
of the target access network of the handoff. Bi-casting media
streams to both access networks with respective service quality
optimization is and effective means to avoid service disruptions
while simultaneously improving the end user's experience. This
document introduces general methods and specifies the signaling and
media flows for providing bi-cast support in vertical handoffs using
the SIP protocol.
5.1. Mobile Node controlled Vertical handoff
The use of the Handoff Assistive Server (HOAS) to perform media
stream bicasting during a vertical handoff is similar to session
mobility support using Third-Party Call Control (3PCC) signaling
conventions as originally proposed in [6], [10] and [12]. Figure 2
illustrates the protocol signaling to enable Bi-casting/Transcoding
support during a vertical handoff.
Izumikawa & Lillie Expires August 28, 2008 [Page 7]
Internet-Draft SIP Session Bi-casting February 2008
MN-AN1 MN-AN2 HOAS CN
| | | |
| | | |
| | | |
|(1) INVITE AN1 params | |
|------------------------------------------->|
|(2) 200 OK CN params | |
|<-------------------------------------------|
|(3) ACK | | |
|------------------------------------------->|
|(4) RTP | | |
|............................................|
| | | |
Handover| | | |
Begins | | | |
| | | |
|(5) INVITE no SDP | |
|------------------------------------------->|
|(6) 200 OK CN params | |
|<-------------------------------------------|
|(7) INVITE no SDP | |
|------------->| | |
|(8) 200 OK MN-AN2 params | |
|<-------------| | |
|(9) INVITE AN1, AN2, CN params |
|---------------------------->| |
|(10) 200 OK HOAS params | |
|<----------------------------| |
|(11) ACK | | |
|---------------------------->| |
|(12) ACK HOAS params | |
|------------->| | |
|(13) ACK HOAS params | |
|------------------------------------------->|
| | |(14) RTP |
| | |..............|
|(15) RTP | | |
|.............................| |
| |(16) RTP . | |
| |............ | |
| | | |
| | | |
Figure 2 - A MN controlled vertical handoff supporting media
bi-casting
The example shown in Figure 2 illustrates the signaling used in a
Izumikawa & Lillie Expires August 28, 2008 [Page 8]
Internet-Draft SIP Session Bi-casting February 2008
typical vertical handoff employing media bi-casting. The signaling
follows that specified in for Third-Party Call Control, with the MN
acting as the session mediator.
In this example, the initial session is established during the first
SIP transaction comprised of messages 1 through 3. Initially,
message 1 is sent from MN to CN as follows:
INVITE sip:CN@example.com SIP/2.0
To: sip:CN@exmaple.com
From: sip:MN@example.com; tag=dc2c13
Call-ID: 858ec@example.com
Contact: sip:MN@an1.example.net
m=video 20002 RTP/AVP 96
c=IN IP4 an1.example.net
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
The bandwidth is specified using bandwidth attribute defined in [2]
and [5] in this example. The returned response, message 2, includes
the following session parameters for CN:
SIP/2.0 200 OK
To: sip:CN@exmaple.com; tag=12aae
From: sip:MN@example.com; tag=dc2c13
Call-ID: 858ec@example.com
Contact: sip:CN@cn.example.net
m=video 40002 RTP/AVP 96
c=IN IP4 cn.example.net
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
To initiate the vertical handover between access networks AN1 and
AN2, the mobile sends a SIP Re-INVITE (5) to the correspondent node,
CN, without a payload to determine the media capabilities of the CN.
This information might be cached by the mobile node from a previous
session establishment with the CN. The CN responds with a SIP
response (6) containing a SDP packet indicating its capabilities.
Izumikawa & Lillie Expires August 28, 2008 [Page 9]
Internet-Draft SIP Session Bi-casting February 2008
For example, the returned response and SDP payload might look as
follows:
SIP/2.0 200 OK
To: sip:CN@example.com;tag=12aae
From: sip:MN@example.com;tag=dc2c13
Call-ID: 858ec@example.com
Contact: sip:CN@cn.example.net
m=video 40002 RTP/AVP 96 97
c=IN IP4 cn.example.net
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
The MN then sends a SIP INVITE (7) to its interface on the access
network to which the vertical handover is directed, to determine the
media capabilities of the MN on this access network. In most
instances, this message dialog will be eliminated, but is included
here for clarity.
In (8) the response and enclosed SDP payload describing the media
capabilities on this access network might look as follows:
SIP/2.0 200 OK
To: sip:MN@example.com;tag=dddf23
From: sip:MN@example.com;tag=1dddef
Call-ID: 18365@example.net
Contact: sip:MN@an2.example.net
m=video 50002 RTP/AVP 97
c=IN IP4 an2.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
Izumikawa & Lillie Expires August 28, 2008 [Page 10]
Internet-Draft SIP Session Bi-casting February 2008
In message 9, the MN establishes the session with the HOAS for media
bi-casting and transcoding as follows:
INVITE sip:HOAS@example.com SIP/2.0
To: sip:HOAS@exmaple.com
From: sip:MN@example.com;tag=dfad122
Call-ID: 32625@example.net
Contact: sip:MN@an1.example.net
m=video 20004 RTP/AVP 96
c=IN IP4 an1.example.net
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
m=video 50002 RTP/AVP 97
c=IN IP4 an2.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
m=video 40004 RTP/AVP 97
c=IN IP4 cn.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
The HOAS returns an SDP packet generated by the HOAS and indicating
its media handling capabilities for MN-AN1, MN-AN2 and CN (10).
Izumikawa & Lillie Expires August 28, 2008 [Page 11]
Internet-Draft SIP Session Bi-casting February 2008
SIP/2.0 200 OK
To: sip:HOAS@example.com;tag=f1234ee
From: sip:MN@example.com;tag=dfad122
Call-ID: 32625@example.com
Contact: sip:HOAS@hoas.example.com
m=video 30000 RTP/AVP 96
c=IN IP4 hoas.example.com
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
m=video 30002 RTP/AVP 97
c=IN IP4 hoas.example.com
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
m=video 30004 RTP/AVP 97
c=IN IP4 hoas.example.com
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
At this point the MN has established an active session with the HOAS
for the purpose of bi-cast and transcoding support during the
vertical handoff. However no media is yet exchanged through the
HOAS. In (12) the MN establishes a session with it's second
interface for the duration of the vertical handoff as follows:
ACK sip:MN@example.net SIP/2.0
To: sip:MN@example.net;tag=dddf23
From: sip:MN@example.net;tag=1dddef
Call-ID: 18365@example.net
Contact: sip:MN@an1.example.net
m=video 30002 RTP/AVP 97
c=IN IP4 hoas.example.com
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
Izumikawa & Lillie Expires August 28, 2008 [Page 12]
Internet-Draft SIP Session Bi-casting February 2008
Finally, MN acknowledges the re-INVITE used to probe the capabilities
of the CN (5) with new session parameters within the body of the ACK
(13) directing CN to direct it's outbound media to the HOAS as
follows:
ACK sip:CN@example.com SIP/2.0
To: sip:CN@example.com;tag=12aae
From: sip:MN@example.com;tag=dc2c13
Call-ID: 858ec@example.com
Contact: sip:MN@an1.example.net
m=video 30004 RTP/AVP 97
c=IN IP4 hoas.example.com
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
At the completion of the handoff event, an INVITE/Replaces to the CN
is required to establish the MN's new access network as the primary
media path. In addition, the resources within the HOAS need to be
released as well as the temporary session resources that exist
between MN IF2 and the HOAS. This protocol sequence is illustrated
in Figure 3.
Izumikawa & Lillie Expires August 28, 2008 [Page 13]
Internet-Draft SIP Session Bi-casting February 2008
MN-AN1 MN-AN2 HOAS CN
| | | |
| | | |
Handoff | | | |
Completed| | | |
| | | |
| |(1) INVITE Replaces AN2 params
| |---------------------------->|
| |(2) 200 OK CN params |
| |<----------------------------|
|(3) BYE | | |
|<-------------------------------------------|
|(4) 200 OK | | |
|------------------------------------------->|
|(5) BYE | | |
|<-------------| | |
|(6) 200 OK | | |
|------------->| | |
|(7) BYE | | |
|---------------------------->| |
|(8) 200 OK | | |
|<----------------------------| |
| |(9) ACK | |
| |---------------------------->|
| |(10) RTP | |
| |.............................|
| | | |
| | | |
Figure 3 - Bi-cast Handoff Completion using 3PCC protocol flows
In Figure 3, the INVITE (1) replaces the preexisting dialog between
MN_AN1 and CN, adjusting the session parameters to remove the HOAS
from the media paths. The INVITE has the following form:
INVITE sip:CN@example.com SIP/2.0
To: sip:CN@example.com
From: sip:MN@example.com;tag=dd14f3
Replaces: 858ec@example.com; to=12aae; from=dc2c13
Call-ID: 18325@example.com
Contact: sip:MN@an2.example.net
m=video 50004 RTP/AVP 97
c=IN IP4 an2.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate: 15
b=AS:600
Izumikawa & Lillie Expires August 28, 2008 [Page 14]
Internet-Draft SIP Session Bi-casting February 2008
with CN responding in message 2 with the following:
SIP/2.0 200 OK
To: sip:CN@example.com;tag=569ff1
From: sip:MN@example.com;tag=dd14f3
Replaces: 858ec@example.com; to=12aae; from=dc2c13
Call-ID: 18325@example.com
Contact: sip:CN@cn.example.net
m=video 40004 RTP/AVP 97
c=IN IP4 cn.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate: 15
b=AS:600
This cause CN to terminate the original session with MN_AN1 through a
BYE request (3) and the corresponding response from MN_AN1 (4)
The BYE requests, in messages 5 and 7 terminate the dialogs
established between the MN and HOAS, as well as the dialog between
the MN's access networks.
5.2. A B2BUA Mediated Vertical handoff via Session Update
In the next example, a vertical handoff is accomplished with the HOAS
functioning as a B2BUA instantiated in the protocol signaling path.
This approach requires that the HOAS is instantiated in the signaling
path's route set. From the MN's perspective, for example, the HOAS
could be configured as the user agent's outbound proxy. This
protocol flow utilizes the SIP UPDATE [8] methods to redirect,
through the HOAS, media streams between the CN and MN. Note that the
SIP re-INVITE request could be utilized instead of the SIP UPDATE,
however with the semantics defined for UPDATE requests, this method
is preferred in a vertical handoff scenario.
Since the HOAS is now acting as a B2BUA, it maintains state
information related to each active session in which it is in the
signaling path. This approach also, optionally, introduces new
attributes to the related Session Description Protocol SDP [2]
payload to assist the HOAS in determining when the underlying media
streams need to be routed through the HOAS bicasting function.
A possible signaling flow for the HOAS B2BUA use case is illustrated
in Figure 4. In the initial INVITE transaction, establishing the
session dialog between the MN and CN, the HOAS adds itself to the
dialog's route set via SIP's Record-Route header, thus insuring that
Izumikawa & Lillie Expires August 28, 2008 [Page 15]
Internet-Draft SIP Session Bi-casting February 2008
all further signaling related to the session traverses the HOAS. In
this sense, the HOAS B2BUA can be viewed as a SIP proxy.
The format for the initial INVITE in message 1 is as follow:
INVITE sip:CN@example.com SIP/2.0
To: sip:CN@example.com
From: sip:MN@example.com;tag=33dfff
Route: <hoas.example.com;lr>
Contact: sip:MN@an1.example.net
Call-ID: 41010@example.com
...
Alternately, the MN UAC can be configured with the HOAS as it's
outbound proxy. In this case, the HOAS processes the INVITE request
by adding a Record-Route header to the forwarded request. This would
appear in message 2 as follows:
INVITE sip:CN@example.com SIP/2.0
To: sip:CN@example.com
From: sip:MN@example.com;tag=33dfff
Record_Route: <sip:hoas.example.com;lf>
Contact: sip:MN@an1.example.net
Call_ID: 41010@example.com
...
Izumikawa & Lillie Expires August 28, 2008 [Page 16]
Internet-Draft SIP Session Bi-casting February 2008
MN-AN1 MN-AN2 HOAS CN
| | | |
| | | |
|(1) INVITE AN1 params |(2) INVITE AN1 parms
|---------------|-------------->|------------->|
|(3) RTP | | |
|<.............................................|
|(5) 200 OK CN params |(4) 200 OK |
|<------------------------------|<-------------|
|(6) RTP | | |
|.............................................>|
|(7) ACK | |(8) ACK |
|------------------------------>|------------->|
| | | |
Handover | | | |
Begins | | | |
|(9)UPDATE bicast AN1,AN2 params|(10)UPDATE HOAS/CN
|------------------------------>|------------->|
|(12) 200 AN1, AN2 params |(11) 200 OK |
|<------------------------------|<-------------|
| | (14) RTP |(13) RTP |
|<.............................>|<............>|
| | (15) RTP . | |
|<............................ | |
| | | |
Handover | | | |
Completed| | | |
| |(16) UPDATE |(17) UPDATE |
| |-------------->|------------->|
| |(19) 200 OK |(18) 200 OK |
| |<--------------|<-------------|
| | | |
Figure 4 - HOAS Mediated handoff
The UPDATE request in message 9 triggers the HOAS to configure the
necessary resources for media bi-casting to the MN's access networks.
This requires the HOAS to modify session parameters established with
CN such that all media sent from CN destined to the MN is now
redirected through the HOAS.
Since the use of media bi-casting is specific to a particular
session, a new session-level attribute, named 'bicast', is applied to
the SDP packet describing the bi-cast flows for the MN. The HOAS
uses the session level identifier as well as this new session level
attribute to determine when bi-casting support is required.
Izumikawa & Lillie Expires August 28, 2008 [Page 17]
Internet-Draft SIP Session Bi-casting February 2008
The format of the UPDATE request used to trigger bi-casting support
within the HOAS is as follows:
UPDATE sip:CN@example.com SIP/2.0
To: sip:CN@example.com;tag=aaab33
From: sip:MN@example.com;tag=111565
Route: <sip:hoas.example.com;lr>
Call-ID: 5c3ee@example.com
Contact: sip:MN@an1.example.net
a=bicast
m=video 30002 RTP/AVP 97
c=IN IP4 an1.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
m=video 30004 RTP/AVP 96
c=IN IP4 an2.example.net
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
where the bicast attribute is parsed by the HOAS and used to control
its media handling behavior.
As an alternative to introducing a new session level attribute to the
SDP payload, the semantics that allows for grouping of media streams
may be applied to the SDP packet (9), as described in [7]. However,
as stated in [7], "...An application that encodes the same media
using different codecs simultaneously MUST NOT use FID to group those
media lines..." In this case, new bicasting semantics are introduced
by introducing a bicast-specific media group tag, BC (Bi-Cast), to
extend [7] as follows:
Izumikawa & Lillie Expires August 28, 2008 [Page 18]
Internet-Draft SIP Session Bi-casting February 2008
UPDATE sip:CN@example.com SIP/2.0
To: sip:CN@example.com;tag=aaab33
From: sip:MN@example.com;tag=111565
Route: <sip:hoas.example.com;lr>
Call-ID: 5c3ee@example.com
Contact: sip:MN@an1.example.net
a=group:BC 1 2
m=video 30002 RTP/AVP 97
c=IN IP4 an1.example.net
a=rtpmap:97 MP4V_ES/90000
a=framerate:15
b=AS:600
a=mid:1
m=video 30004 RTP/AVP 96
c=IN IP4 an2.example.net
a=rtpmap:96 MP4V_ES/90000
a=framerate:5
b=AS:200
a=mid:2
Upon receiving an UPDATE request with a session description
requesting bi-casting support, the HOAS sends a corresponding UPDATE
request (message 10) directing the CN to direct its media flows to
the HOAS.
The corresponding SDP packet simply establishes the HOAS as the
recipient for all CN media:
m=video 30006 RTP/AVP 97
c=IN IP4 hoas.example.net
a=fmtp:97 MP4V_ES/90000
a=framerate:15
b=AS:600
Izumikawa & Lillie Expires August 28, 2008 [Page 19]
Internet-Draft SIP Session Bi-casting February 2008
In message 12, the MN's updated media streams are redirected through
the HOAS:
m=video 40006 RTP/AVP 97
c=IN IP4 hoas.example.net
a=fmtp:97 MP4V_ES/90000
a=framerate:15
b=AS:600
m=video 50006 RTP/AVP 96
a=fmtp:96 MP4V_ES/90000
a=framerate:5
b=AS:200
Upon completion of the handoff, the session streams must again be
adjusted such that the HOAS is no longer part of the media path. In
message 16, the session is again updated by the MN to eliminate bi-
casting within the HOAS.
The corresponding SDP packet describing the new session parameters
again contains a session level attribute used to trigger the HOAS to
stop bi-casting support. The SDP packet takes the following form:
c=IN IP4 an2.example.net
...
The absense of the bicast attribute in this updated session
description now directs the HOAS to pass the UPDATE request directly
to the CN and signals the HOAS that all resources used to support bi-
casting for the session handoff can be released.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
A detailed analysis of the security aspects of the solutions proposed
in this document needs to be performed to insure that no additional
security issues have been introduced. As the solution leverages
current practices for Third Party Call Control (3PCC) [3] as well as
the use of SIP's UPDATE [8] method, the security considerations of
these proposals can be extended to the solutions proposed herein.
Izumikawa & Lillie Expires August 28, 2008 [Page 20]
Internet-Draft SIP Session Bi-casting February 2008
8. Acknowledgements
The authors would kindly like to thank Mr. Phil Roberts of Motorola
Laboratories for his assistance in navigating the draft submission
process as well as helping to coordinate the initial meetings that
resulted in this draft submission.
9. References
9.1. Normative References
[1] 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.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[5] Casner, S., "A Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[6] Camarillo, G., Burger, E., Schulzrinne, H., and A. Wijk,
"Transcoding Services Invocation in the Session Initiation
Protocol (SIP) Using Third Party Call Control (3pcc)",
RFC 4117, June 2005.
[7] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of
Media Lines in the Session Description Protocol (SDP)",
RFC 3388, December 2002.
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
9.2. Informative References
[9] Izumikawa, H., Fukuhara, T., Matsunaka, T., and K. Sugiyama,
"User-centric Seamless Handover Scheme for Realtime
Applications", IEEE Internation Symposium on Personal, Indoor
Izumikawa & Lillie Expires August 28, 2008 [Page 21]
Internet-Draft SIP Session Bi-casting February 2008
and Mobile Radio Communications (PIMRC'07), 2007.
[10] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
Using SIP", ACM Mobile Computing and Communications
Review Vol.4, No.3, July 2000.
[11] Shacham, R., "Session Initiation Protocol (SIP) Session
Mobility", draft-shacham-sipping-session-mobility-05 (work in
progress), November 2007.
[12] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-transc-framework-05 (work in progress),
December 2006.
[13] Salsano, S., Niccolini, N., Veltri, V., and P. Polidoro, "A
solution for vertical handover of multimedia sessions using
SIP", draft-salsano-sipping-siphandover-solution-01 (work in
progress), August 2007.
Authors' Addresses
Haruki Izumikawa
KDDI Labs
2-1-15 Ohara
Fujimino, 356-8502
JP
Phone: +81-49-278-7866
Email: izumikawa@kddilabs.jp
Ross Lillie
Motorola Labs
1301 East Algonquin Road, IL02/2240
Schaumburg, IL 60196
US
Phone: +1 847 576 0012
Email: ross.lillie@motorola.com
Izumikawa & Lillie Expires August 28, 2008 [Page 22]
Internet-Draft SIP Session Bi-casting 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).
Izumikawa & Lillie Expires August 28, 2008 [Page 23]
