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.

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) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [1].

Table of Contents

1.  Overview
2.  Terminology
3.  Requirements
4.  Architecture
5.  Vertical Session handoff with Media Bi-casting
    5.1.  Mobile Node controlled Vertical handoff
    5.2.  A B2BUA Mediated Vertical handoff via Session Update
6.  IANA Considerations
7.  Security Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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 (Requirements) the requirements and constraints for media stream bi-casting in a vertical handoff are enumerated. Section 4 (Architecture) introduces the architectural elements involved in a bi-casted vertical handoff. Section 5 (Vertical Session handoff with Media Bi-casting) 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.

• 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.
• 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.

• 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) (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [3] and SIP's UPDATE [8] (Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” October 2002.) methods.
• 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.
• 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] (Izumikawa, H., Fukuhara, T., Matsunaka, T., and K. Sugiyama, “User-centric Seamless Handover Scheme for Realtime Applications,” 2007.), when performing a vertical handoff between the heterogeneous access networks.

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.

                  +-------+
                  |  CN   |
                  +-------+
                      |
             +------------------+     +----+
             |    Internet      |-----|HOAS|
             |                  |     +----+
             +------------------+
               |              |
              /                \
             /                  \
 +------------------+       +-----------------+
 | AN1              |       | AN2             |
 |                  |       |                 |
 +------------------+       +-----------------+
              \                  /
               \                /
                \              /
                 \            /
                  +-------+
                  |  MN   |--> MH handoff from AN1 to AN2
                  +-------+


                        |  Service area covered by AN2 |
                        +------------------------------+
|         Service area covered by AN1                     |
+---------------------------------------------------------+

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] (Schulzrinne, H. and E. Wedlund, “Application-Layer Mobility Using SIP,” July 2000.) through the use of both Third-Party Call Control (3PCC) (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [3] as well as SIP's REFER [4] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) method as possible solutions. More recently, [11] (Shacham, R., “Session Initiation Protocol (SIP) Session Mobility,” November 2007.) 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 (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [3] has been demonstrated in [12] (Camarillo, G., “Framework for Transcoding with the Session Initiation Protocol (SIP),” December 2006.) as the protocol mechanism usefull for establishing media transcoding services in a new or existing session.

Although SIP mobility [10] (Schulzrinne, H. and E. Wedlund, “Application-Layer Mobility Using SIP,” July 2000.) and the session mobility [11] (Shacham, R., “Session Initiation Protocol (SIP) Session Mobility,” November 2007.) can provide a terminal mobility or a session mobility through the use of 3PCC [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),” April 2004.) or SIP's REFER [4] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) 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] (Salsano, S., Niccolini, N., Veltri, V., and P. Polidoro, “A solution for vertical handover of multimedia sessions using SIP,” August 2007.). 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 (Requirements).

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] (Camarillo, G., Burger, E., Schulzrinne, H., and A. Wijk, “Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc),” June 2005.), [10] (Schulzrinne, H. and E. Wedlund, “Application-Layer Mobility Using SIP,” July 2000.) and [12] (Camarillo, G., “Framework for Transcoding with the Session Initiation Protocol (SIP),” December 2006.). Figure 2 illustrates the protocol signaling to enable Bi-casting/Transcoding support during a vertical handoff.

        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    . |              |
        |              |............  |              |
        |              |              |              |
        |              |              |              |

The example shown in Figure 2 illustrates the signaling used in a 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] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) and [5] (Casner, S., “A Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth,” July 2003.) 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.

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

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).

            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

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.

       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      |              |
         |              |.............................|
         |              |              |              |
         |              |              |              |

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

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] (Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” October 2002.) 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 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 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

            ...

       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   |
         |               |<--------------|<-------------|
         |               |               |              |

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.

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] (Camarillo, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.). However, as stated in [7] (Camarillo, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.), "...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] (Camarillo, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) 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=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

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) (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [3] as well as the use of SIP's UPDATE [8] (Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” October 2002.) method, the security considerations of these proposals can be extended to the solutions proposed herein.

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

9.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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.