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