Internet Engineering Task Force

INTERNET-DRAFT  Schulzrinne/Rosenberg
draft-schulzrinne-mmusic-cname.ps  Columbia U./dynamicsoft

May 28, 2002

Expires: November 2002

Associating RTP Streams with SIP Sessions

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (c) The Internet Society (2002). All Rights Reserved.

Contents

1 Introduction 1

2 Attribute Description 2

3 Alternate Solutions 2

4 Limitations 3

5 Authors’ Addresses 3

Abstract

For conferencing, dealing with multiple call legs, side bars and other applications, it is desirable to unambiguously associate media streams with SIP sessions. We describe how a new SDP attribute, “cname”, can be used to carry the RTCP CNAME SDES attribte across the signaling association.

1 Introduction

INTERNET-DRAFT  draft-schulzrinne-mmusic-cname.ps  May 28, 2002

There are a number of scenarios where a SIP user agent needs to know which RTP packets belong to which SIP session. One such scenario is a conference bridge terminating multiple SIP sessions. In most cases, the bridge can direct streams to different transport ports and thus unambiguously identify the source. (Indeed, this is probably preferable as two sources sending to the bridge would not see each others transmissions and thus could collide in their SSRC values without either of them noticing.) However, in some circumstances, the number of destination ports may be limited by firewall constraints, forcing multiple media streams to share the same port. In those cases, it is desirable to be able to unambiguously associate an RTP stream with a SIP session.

A more realistic case is SIP INVITE forking. Here, the UAC gets back multiple 200 OK (or multiple 18x), with all the media being sent to the same port that was specified in the session description of the INVITE request. Thus, there is no way to correlate the media with the SIP dialogs. This can be fixed by performing a re-INVITE (or UPDATE) to put the media on a different port. Having a correlation identifier would avoid the need for the re-INVITE, and also provide correlation right away.

Another application is the initiation of side bar conversations during a multicast session. If two participants want to converse, they need to acquire each other’s SIP address, with RTCP as the only common means. For H.323, the H323-CADDR RTCP SDES option supports this, but for SIP, there is no direct equivalent. However, unlike the other uses, this identifier should not identify a particular host, but likely a generic SIP address-of-record. This contradicts the other uses; thus, it is likely that this requires a separate mechanism.

2 Attribute Description

This document describes a new SDP [1] value attribute, namely “a=cname:”. The syntax of the parameter follows that in [2], i.e., it is a user name followed by either a fully-qualified domain name or an IPv4 or IPv6 address.

The “cname” attribute can be either session-level or media-level. Media-level should only be necessary if the media agents for a single SIP session are located on different hosts.

An example is “alice@for.example.com”.

The parameter is not likely to be useful for multi-source multicast sessions, but can be used to identify the primary source in a multicast session.

3 Alternate Solutions

As an alternative to the SDP attribute, one could add a new SDES parameter, say, SIP-CADDR, that identifies the SIP address of the application controlling the media agent. This is similar to the H323-CADDR parameter [where is this standardized? There is an IANA registration, but that seems to be it.]. The drawback of that approach is that it requires modifying media applications. A more serious problem is that this does not work well if there are multiple participants with the same SIP address-of-record. All of these would likely have different host names, so that their RTCP CNAMEs will differ, but the RTP sessions could not be clearly mapped to a particular SIP session with the SIP-CADDR approach.

A minor advantage of the proposed approach is that RTCP is designed to be bandwidth-frugal, so that adding parameters should not be done lightly. If the SIP-CADDR parameters were to transmitted only occasionally, it might take a significant amount of time before a newly established SIP session can be associated with RTP packets. The CNAME SDES parameter, on the other hand, is mandatory for every RTCP packet.

It has also been proposed to include the SSRC in the session description. This approach has practical problems, in that SSRC collisions can change the SSRC in mid-session. Thus, RTP media agent would need to be able to notify the SIP user agent that the SSRC value has changed and trigger a re-INVITE. Some existing user agents can only be configured at start-up and do not have the ability to communicate back to the SIP user agent. Unlike the CNAME, which is the same for all media sessions, the SSRC will differ between media sessions, further complicating the implementation. However, the SSRC does have the advantage that it is contained in every RTP packet, thus leading to faster stream association. The waiting time should be very small, on the order of a few seconds.

Alternatively, one could include the packet source address as part of the SDP description. However, the source address may not be known precisely (e.g., with multi-homed hosts), may be changed by NATs or may change during a session, e.g., when a DHCP lease lapses after a period of inactivity or when the host moves into a new subnet. Like the SSRC approach, it is clearly faster than waiting for the RTCP packet.

4 Limitations

It is conceivable that over-eager NAT ALGs would rewrite the CNAME portion of an RTCP packet. Such action is neither advisable nor necessary, since CNAMEs are only meant for unique identification.

5 Authors’ Addresses

Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu

References

[1] M. Handley, V. Jacobson, and C. Perkins, “SDP: Session description protocol,” Internet Draft, Internet Engineering Task Force, Apr. 2002. Work in progress.

[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A transport protocol for real-time applications,” Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.

Full Copyright Statement

Copyright (c) The Internet Society (2002). 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 IN-TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-RANTIES, 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.