Session control through RTCP D. Haldar An extension to RTCP draft-haldar-rtp-session-control-00.txt November 2002 Expires May 2003 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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 obsolete 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 XX XXXX, 2003. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The main focus of this draft is to incorporate certain level of session control mechanism within a RTP session. One of the high demands of current IP network is to provide high performance for instant messaging, push to talk and other applications along those lines. For all of these kinds of services, it is better not to go through the out-of-band session control path and control the session within RTP session. Here the suggestion is to define an extension of RTCP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. RTCP message format . . . . . . . . . . . . . . . . . . . . . 3 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 Haldar [page 2] 1. Introduction Currently applications requiring real time communications are having out-of-band call control mechanism. So the session setup (signaling) is done by some protocol like SIP and then the actual data is transferred using RTP. RTCP doesn't allow any kind of control mechanism within a session other than "BYE" messages. Other RTCP messages are mainly for exchanging network statistics. Applications like "push-to-talk" (described later) or "Instant Messaging" requires call control within a RTP session for better performance. Also, in an intelligent, next generation, conference call system, a participant may need to change the scope of the conferencing. For example, in a conference call, one participant can choose (by a client action - pressing special key etc.) to mute his/her voice to a subset of the participants. This can be continued for a period of time and then by another client action, the earlier state can be got back. Connecting and switching to another conference for some duration during the conference or any multi-modal switching from the same client instance are other examples. Yet another example is to switch handset devices seamlessly during a call (i.e., press a key to switch the RTP session to another pre-provisioned device). All of the above has to be done while the RTP session(s) are up and running. For this purpose, to get better performance, it is preferable to carry this control job in real time data stream in stead of using an out-of-band session control mechanism like SIP. So far, RTCP is used to carry the control information like "Sender report", "Receiver report", "Source description item", "BYE message", "APP specific functions" etc. Bullet 4 of section 6 in rfc 1889 (RTP) mentioned the use of RTCP in minimal session control information. But it also mentioned that a higher-level session control has to be there. In this approach, user end point is leveraging RTCP mechanism to do "real time" and "within the session" control job by slightly extending RTCP functionality. 2. Motivation The motivations of this draft are those new application requirements, which require session control during a running session. Some of them are described below. a) Push-to-talk: In a multicast voice RTP session any one of the users can push a particular button on the device and start talking (in a word getting control of the floor), while other members of the session will be remain silent in listening only mode. When he/she releases the floor by pressing another or the same key, any other member of that call can get hold of the floor by the same method. There are commercially available services like this in circuit switch world. So, anyone in that session has to push a particular button to talk. In this case, a signal message must be sent to the push-to-talk server to regulate the direction of RTP streams. b) Instant Messaging: In stead of using SIP control mechanism for actual data transfer in case of Instant Messages, use RTCP. Haldar [page 3] c) 'Mute' as a Conference Option: This is an option in a regular conference session by which one party of the conference session can choose to take part as a 'listener only' party and block his/her active participation in the conference as and when required within a conference session. This is now possible with the use of some user agent client, where 'mute' is the option to do that. But in that case network is not controlling that. To control this kind of services from network for better traffic management and other issues, specific in band "control messages" are needed. Proposal is to create an extension of RTCP mechanism to transmit session control information, regulated from user end. RTCP packets are transmitted in a periodic manner. To control session from user end, the control packets need to be created and sent by the user as and when required and not only in periodic manner. The followings are the examples where this mechanism can be used. 3. Definitions: Media Control Unit (MCU): Unit Responsible for the media control. 4. RTCP packet format In RTCP packet format packet type (PT) represents a number for each type of packet, like 202 for RTCP SDES packet. The suggested type of packet does not fall under any of the types already defined in rfc 1889. This packet type is session control specific and the suggested value for PT field in RTCP packet format is 205. These RTCP packets will not be sent in pre-configurable regulated manner, but as and when required by the user and/or handset/device. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| service | PT=CNTR=205 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | control information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP (rfc 1889), which is the same in RTCP packets as in RTP data packets. The version defined by this specification is two (2). subtype: 5 bits May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data. packet type (PT): 8 bits Contains the constant 205 to identify this as an RTCP MC packet. length: 16 bits The length of this RTCP packet in 32-bit words minus one, including the header and any padding.(The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.) SSRC: 32 bits The synchronization source identifier for the originator of this SR packet. Haldar [page 4] 5. Overview of Operation Any user agent or proxy/control box (e.g., Media server for conference service, media server for push-to-talk kind of services) can send an RTCP message of PT=205 to any other user agent in the same session or to any intermediate proxy/control box. The service field in the RTCP frame will specify the name of the service in which the session is on. There will be application layer negotiation between the sender and the receiver. This negotiation includes the media level actions (e.g., hold and store the RTP packets for a particular user agent from the media server, hold only the video part of the RTP stream for some time etc.) to be taken, for the value of service field in the RTCP message . 6. References [1] RFC 1889 Authors' Addresses Debashis Haldar 11196 S Penrose St., Olathe, KS - 66061, USA. Ph # +1 913 568 8157 email: debanu@kcinter.net dhalda01@sprintspectrum.com Internet Engineering Task Force D. Haldar Internet-Draft Expires: Haldar