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