Internet Engineering Task Force Mahesh Shankar Internet Draft Cisco Systems Document: draft-shankar-sip-forked-media-00.txt Feb 2001 Expires: Aug 2001 SIP Forked Media Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document provides guidelines and examples for initiating "forked" media sessions using multiple media description headers in the session description of a SIP message. The presence of multiple media and address description headers in the SDP implies that multiple media streams are opened for the session in question based on the media description headers. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Shankar Expires: Aug 2001 1 SIP Forked Media Feb 2001 3. The use of media description headers in forking media streams In some application scenarios, a user contacts an application, places a new call in the context of the application, and returns to the application after the new call is finished. Some examples of such scenarios are: Calling card systems, Voicemail or Messaging systems which allows outgoing calls, and Voice Browsers or Voice Portals which allow outgoing calls. Many of these applications employ speech recognition technology to listen for "hotwords" or other audio input from the Originating User, while he or she converses with the Target. For brevity, we will call these application servers "Voice Portals". In addition to receiving media, these applications may also send media in the form of announcements, tones, etc. which should be mixed with media sent by the Target before the media is rendered for the Originating User. Note that while both the Voice Portal and the Target communicate with the Originating User simultaneously, this media relationship is not a conference. The Voice Portal does not receive any media sent by the Target, nor does the Target receive any media sent by the Voice Portal. The Originating UA may choose to send or "fork" its own media to both peers, and locally mix the two forks of the received session locally. This implementation feature of the Originating UA is therefore called "media forking". The author notes that this media relationship happens to be similar to the mixing relationship required for multicast conferences; as a result this forking arrangement is sometimes alternatively referred to as multi-unicast. The Session Description Protocol [3] defines the set of messages that would enable transfer of media through media channels. As such, each session has global attributes that would dictate the attributes of the global session, and apply to the session in general. The SDP message also defines attributes that would apply to a media session in particular. Appendix B of RFC2543 (SIP) [4] implies that multiple instances of media description headers in the SDP message should result in either the opening of multiple media channels to the same location, or it should establish a forked media session. Also, in the case of an end point initiating the forking media session, it should be capable of modifying the SDP message to add itself to the SDP message and moving the global connection information ("c= ") line, to be media specific. Shankar Expires: Aug 2001 2 SIP Forked Media Feb 2001 4. Usage Examples The following diagram illustrates the setup: ---- +--------+ SIP +---------+ / \ | |<-------->| | |Origin+-----+ GW | RTP | Voyager | | UA | | |<========>| | \ / +--------+ +---------+ ---- ^^ ^ || | || | SIP || | || v || +---------+ || RTP | | =============>| Target | | | +---------+ When A places a call to Voice Portal, the call goes through gateway GW, and the ensuing call-flows illustrate this. Origin Portal Target | | | | INVITE A1 | | |---------------------------->| | | | | | 180 Ringing A2 | | |<----------------------------| | | | | | 200 OK A3 | | |<----------------------------| | | | | | ACK A4 | | |---------------------------->| | | | | | 2-way media A5 | | |<===========================>| | | | | Shankar Expires: Aug 2001 3 SIP Forked Media Feb 2001 The Voice Portal initiates the forking media session. | | INVITE without SDP B1 | | |---------------------------->| | | | | | | | | 200 OK B2 | | |<----------------------------| The Voice Portal modifies the SDP message, and sends it as part of the INVITE message to the GW. | | | | | | | INVITE with media headers | | | from both Voice Portal and | | | Target C1 | | |<----------------------------+ | | | | | 200 OK with multiple media | | | headers for Voice Portal and| | | Target C2 | | |---------------------------->| | | ACK C3 | | |<----------------------------+ | The Voice Portal modifies the SDP message to remove the media header that pertains to itÆs media channel, and sends the modified SDP message as part of the ACK for the initial INVITE without SDP. | | | | | ACK with single media header| | | meant for Target. B3 | | +---------------------------->| | | | | 2-way media | | |<=========================================================>| | | | | | | | | | | | | | | | | | | The pertinent messages that are involved in the call-flow described above are shown below. Headers, SDP lines, tags, and other elements not directly applicable to the discusion are ommitted for brevity. Shankar Expires: Aug 2001 4 SIP Forked Media Feb 2001 Messages A1-A5 and B1-B3 are standard [SIP] messages that are involved in any call setup scenario. Following are the relevant parts of the messages. B1 INVITE without SDP Voice Portal -> Target INVITE sip:Target@voice.com SIP/2.0 Via: SIP/2.0/UDP voice.com:5060 From: VoicePortal <sip:VoicePortal@voice.com> To: Target <sip:Target@voice.com> ... B2 200 OK Target -> Voice Portal SIP/2.0 200 OK ... From: VoicePortal <sip:VoicePortal@voice.com> To: Target <sip:Target@voice.com> ... Content-Type: application/sdp Content-Length: .... ... c=IN IP4 10.0.0.3 ... m=audio 16980 rtp/avt 0 101 a=rtpmap:0 PCMU/8000 ... C1 INVITE Voice Portal -> GW INVITE sip:GW@voice.com SIP/2.0 Via: SIP/2.0/UDP voice.com:5060 From: VoicePortal <sip:VoicePortal@voice.com> To: GW <sip:GW@voice.com> ... Require: forked-media ... m=audio 16980 rtp/avt 0 101 c=IN IP4 10.0.0.3 a=rtpmap:0 PCMU/8000 ... m=audio 19030 rtp/avt 0 101 c=IN IP4 10.0.0.2 a=... Shankar Expires: Aug 2001 5 SIP Forked Media Feb 2001 C2 200 OK GW -> Voice Portal SIP/2.0 200 OK ... From: VoicePortal <sip:VoicePortal@voice.com> To: GW <sip:GW@voice.com>] ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... B3 ACK Voice Portal -> Target ACK sip:Target@voice.com SIP/2.0 ... From: VoicePortal <sip:VoicePortal@voice.com> To: Target <sip:Target@voice.com> ... Content-Type: application/sdp Content-Length: .... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... 5. GW responses and use of Require: For the purpose of establishing a successful forked-media session, it may be necessary to ensure that GW supports forked media sessions. Hence, Voyager may send a "Require:" header as part of its INVITE message to GW. The Require header for forked media may be defined as illustrated above, and simply as: Require: forked-media In cases where end-points or gateways do not support forked media, an appropriate response for an unsupported "Require: " header (420 Bad Extension) may be sent as: SIP/2.0 420 Bad Extension Unsupported: forked-media Shankar Expires: Aug 2001 6 SIP Forked Media Feb 2001 With respect to the response of GW, which responds with multiple media description headers for the same port, it is worth noting that this would be indication of the ability of GW to support incoming RTP streams from two different sources on a single port (possibly through RTP mixing). Following this, the media description headers in the SDP message would act as an indication of the capability of the sender. 6. Example involving more than two forked media streams For a more complete and complex forked media scenario, following is an illustration involving more than two forked media streams, with two Voice Portals and a Target. ---- +--------+ SIP +---------+ / \ | |<-------->| | |Origin+-----+ GW | RTP | Portal 1| | UA | | |<========>| | \ / +--------+ +---------+ ---- ^^ ^^ ^ || || | || || | SIP || || | || || | || || v || || RTP +---------+ || ============ >| | || | Portal 2| || >| | || +---------+ || ^ || | || | || v || +---------+ || RTP | | ==================>| Target | | | +---------+ Shankar Expires: Aug 2001 7 SIP Forked Media Feb 2001 In the scenario shown above, the call-flow would like: GW Portal1 Portal2 Target | | | | | INVITE A1 | | | |--------------->| | | | | | | | 180 Ringing A2 | | | |<---------------| | | | | | | | 200 OK A3 | | | |<---------------| | | | | | | | ACK A4 | | | |--------------->| | | | | | | | 2-way media A5 | | | |<==============>| | | Portal1 initiates a forked media session with Portal2. | | INVITE without| | | | SDP B1 | | | |--------------->| | | | | | | | 200 OK B2 | | | |<---------------| | | | | | | | | | | | | | | | | | |INVITE with | | | |multiple media | | | |headers C1| | | |<---------------| | | | | | | |200 OK with C2| | | |multiple media | | | |--------------->| | | | ACK C3| | | |<---------------| | | | | ACK with single| | | | media header B3| | | |--------------->| | | | | | | 2-way media | | | |<===============================>| | | | | | Shankar Expires: Aug 2001 8 SIP Forked Media Feb 2001 Portal2 now initiates a forked media session with Target. | | | INVITE without| | | | SDP D1| | | |--------------->| | | | | | | | 200 OK D2| | | |<---------------| | | | | | |INVITE with | | | |multiple media | | | |headers E1| | | |<---------------| | | | | | | | | | | | | | |INVITE with | | | |multiple media | | | |headers F1| | | |<---------------| | | | | | | |200 OK with F2| | | |multiple media | | | |--------------->| | | | ACK F3| 200 OK with E2| | |<---------------| multiple media | | | |--------------->| | | ACK | E3| | |<---------------|----------------| ACK with single| | | | media header D3| | | |--------------->| | | | | | | | | | 2-way media | | | |<================================================>| | | | | | | | | | | | | Messages A1-B3 have been covered in the previous example. Relevant parts of the rest of the messages are given below: D1 INVITE without SDP Voice Portal2 -> Target INVITE sip:Target@voice.com SIP/2.0 Via: SIP/2.0/UDP voice.com:5060 From: VoicePortal2 <sip:VoicePortal2@voice.com> To: Target <sip:Target@voice.com> ... Shankar Expires: Aug 2001 9 SIP Forked Media Feb 2001 D2 200 OK Target -> Voice Portal SIP/2.0 200 OK ... From: VoicePortal2 <sip:VoicePortal2@voice.com> To: Target <sip:Target@voice.com> ... Content-Type: application/sdp Content-Length: .... ... c=IN IP4 10.0.0.4 ... m=audio 19000 rtp/avt 0 101 a=rtpmap:0 PCMU/8000 ... E1 INVITE Voice Portal2 -> Voice Portal1 INVITE sip:VoicePortal1@voice.com SIP/2.0 Via: SIP/2.0/UDP voice.com:5060 From: VoicePortal2 <sip:VoicePortal2@voice.com> To: VoicePortal1 <sip:VoicePortal1@voice.com> ... Require: forked-media ... m=audio 19000 rtp/avt 0 101 c=IN IP4 10.0.0.4 a=rtpmap:0 PCMU/8000 ... m=audio 19030 rtp/avt 0 101 c=IN IP4 10.0.0.3 a=... F1 INVITE Voice Portal1 -> GW INVITE sip:GW@voice.com SIP/2.0 Via: SIP/2.0/UDP voice.com:5060 From: VoicePortal1 <sip:VoicePortal1@voice.com> To: GW <sip:GW@voice.com> ... Require: forked-media ... m=audio 19000 rtp/avt 0 101 c=IN IP4 10.0.0.4 a=rtpmap:0 PCMU/8000 Shankar Expires: Aug 2001 10 SIP Forked Media Feb 2001 ... m=audio 19030 rtp/avt 0 101 c=IN IP4 10.0.0.3 a=... ... m=audio 16980 rtp/avt 0 101 c=IN IP4 10.0.0.2 a=... F2 200 OK GW -> Voice Portal SIP/2.0 200 OK ... From: VoicePortal1 <sip:VoicePortal1@voice.com> To: GW <sip:GW@voice.com>] ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... E2 200 OK Voice Portal1 -> Voice Portal2 SIP/2.0 200 OK ... From: VoicePortal2 <sip:VoicePortal2@voice.com> To: VoicePortal1 <sip:VoicePortal1@voice.com> ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... D3 ACK Voice Portal2 -> Target ACK sip:Target@voice.com SIP/2.0 ... From: VoicePortal2 <sip:VoicePortal2@voice.com> To: Target <sip:Target@voice.com> ... Content-Type: application/sdp Content-Length: .... Shankar Expires: Aug 2001 11 SIP Forked Media Feb 2001 m=audio 17000 rtp/avt 0 101 c=IN IP4 10.0.0.1 a= ... 7. Security Considerations This draft demonstrates examples of SIP and 3rd Party Call Control [5] call flows. The security implications of these documents are explained in the respective documents. 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [3] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments 2327, Internet Engineering Task Force, April 1998 [4] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, Nov 1998. [5] J. Rosenberg, J. Peterson, H. Schulzrinne, "Third Party Call Control in SIP", Internet Draft <draft-rosenberg-sip-3pcc-01.txt>, IETF; Nov. 2000. Work in progress 10. Acknowledgments Thanks to Rohan Mahy for original ideas regarding this draft. 11. Author's Addresses Mahesh Shankar Cisco Systems Inc. 170 W Tasman Drive MS: SJC21/3/3 San Jose, CA 95134 Phone: +1 408 527 6966 Email: mshankar@cisco.com Shankar Expires: Aug 2001 12 SIP Forked Media Feb 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Shankar Expires: Aug 2001 13