Cisco

170 West Tasman Drive San Jose CA 95134 USA +1 408 421-9990 fluffy@cisco.com

Cisco

181 Bay Street Toronto ON M5J 2T3 Canada abegen@cisco.com

Applications such as multi-screen video conferencing systems or advertisement boards often have multiple audio and video streams that are organized to be rendered side by side or in a grid. This specification uses the RFC 5888 Grouping Framework to define new semantics for grouping the media streams to be rendered side by side or in a grid and indicating their relative ordering.

There are many situations where applications create media streams that are meant do be rendered adjacent to each other. A common example is a multi-screen video conferencing system. Other examples are several video monitors placed side by side to display signs, and audio streams from a linear array of microphones, or a grid of display for monitoring security cameras. The Session Description Protocol (SDP) allows negotiation of multiple media streams but does not have a way to describe the ordering information to indicate which media stream is adjacent to which one. This specification introduces new grouping semantics, using the SDP Grouping Framework defined in , that indicate media streams are adjacent, and the adjacency order is defined by the order of the entries in the group.

This specification uses all the terms defined in and will not make sense unless you have read . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This specification defines new grouping semantics of "ADJ" that indicate the media streams in this group are meant to be played or displayed adjacently. Furthermore, the order of media streams in the group indicates the adjacency order. This only indicates the order the device sending the SDP believes is the preferred way to display the media described in this SDP. N media streams could be in a linear horizontal layout, in which case we use a grid size of 1 x N. Alternatively, N media streams could be in a linear vertical layout, in which case we use a grid size of N x 1. In these configurations, the first stream in the group MUST be the one corresponding to the left most and top most output unit, respectively. In a more general grid size of N x M, we can group K (where K <= N x M) media streams starting from the one corresponding to the top-left output unit, and then doing a continuous horizontal scanning of the grid row by row (i.e., scanning first the top row from left to right, and then the second row from left to right, and so on). When we say left most, we mean from the point of view of the person looking at the display. To indicate the dimensions of the layout grid in an SDP description, we define a new session-level attribute. The ABNF syntax for the new attribute is as follows:

The parameters 'rows' and 'columns' indicate the number of rows and columns for this media grid. They both MUST be an integer larger than zero. The gridname indicates a name for this grid. If there are multiple media-grid-dims attribute in the SDP, each MUST have a unique gridname. If the 'media-grid-dims' attribute does not exist in the SDP description, then a 1 x N horizontal linear layout MUST be assumed. Per , there MAY be more than one adjacent media group in a single SDP description. The 'media-grid-dims' attribute MUST come before the group or sssrc-group that it applies to. An group or SSRC-group for an ADJ group MUST use the first 'media-grid-dims' attribute found above it in the SDP.

defines an SDP media-level attribute, called 'ssrc-group', for grouping the RTP streams that are SSRC multiplexed and carried in the same RTP session. The grouping is based on the SSRC identifiers. Since SSRC-multiplexed RTP streams are defined in the same "m" line, the 'group' attribute cannot be used. This section specifies how adjacency is described with SSRC-multiplexed streams using the 'ssrc-group' attribute . The semantics of "ADJ" for the 'ssrc-group' attribute are the same as the one defined for the 'group' attribute except that the SSRC identifiers are used to designate the adjacency grouping associations: a=ssrc-group:ADJ *(SP ssrc-id) . The SSRC identifiers for the RTP streams that are carried in the same RTP session MUST be unique per . However, the SSRC identifiers are not guaranteed to be unique among different RTP sessions. Thus, the 'ssrc-group' attribute MUST only be used at the media level .

When offering adjacent media grouping using SDP in an Offer/Answer model , the following considerations apply. A node that is receiving an offer from a sender may or may not understand line grouping. It is also possible that the node understands line grouping but it does not understand the "ADJ" semantics. From the viewpoint of the sender of the offer, these cases are indistinguishable. When a node is offered a session with the "ADJ" grouping semantics but it does not support line grouping or the adjacent media grouping semantics, as per , the node responds to the offer either (1) with an answer that ignores the grouping attribute or (2) with a refusal to the request (e.g., 488 Not Acceptable Here or 606 Not Acceptable in SIP). In the first case, the original sender of the offer must send a new offer without any grouping. In the second case, if the sender of the offer still wishes to establish the session, it should retry the request with an offer without the adjacent media grouping. This behavior is specified in . The offer contains the sender's suggested layout. The answer MAY contain the suggested layout of the streams that the system sending the answer will be sending to the system that sent the offer.

This section provides SDP examples showing how to use the adjacent media grouping.

A video system with two screens and one audio channels sends a SIP offer. The following figure shows a top-down view of the room with the three screen system that is sending the SIP offer. Screen A is the left most screen for the user in this room but should be displayed as the rightmost screen for the user at the far end that will be viewing the video.

Assume the SDP mid values for the screens are sa and sb, for Screens A and B respectively. The offer contains the following in the SDP:

The complete SDP in the offer could look like:

There might be other media streams, such as presentation video, that are not part of any "ADJ" group. As a note to implementors, consider the case where each screen had two media flows that were in the same FID group. In this case all the media streams are still listed in the ADJ group and the order of two streams in the same FID group can be arbitrarily picked as they will be displayed on the same device.

The following SDP is for a system providing 6 video streams. Four of these streams are arranged as a wall of screens on a 2 by 2 grid while the other 2 streams should be shown separate but still arranged side by side.

The following SDP is for a system providing 2 video streams using SSRC multiplexing. In this example, the SSRC for one stream is 12345 while for the other it is 67890.

Like all SDP, integrity of this information is important. When carrying SDP in SIP, mechanisms such as Transport Layer Security (TLS) can provide hop by hop confidentiality and integrity. The receiver SHOULD do an integrity check on SDP and follow the security considerations of SDP to trust only SDP from trusted sources. End-to-end integrity can be provided by .

Note to RFC Editor: Please replace [RFC-AAAA] with the RFC number for this specification.

This document registers a new attribute name in SDP.

This document, following the Standards Action policy from , registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" registry under SDP Parameters:

This document also registers the following semantics with IANA in "Semantics for the 'ssrc-group' SDP Attribute" registry under SDP Parameters:

The authors would like to thank Flemming Andreasen, Allyn Romanow, Roni Even, Hakon Dahle, Ingemar Johansson, Paul Kyzivat, Peter Musgrave, Christer Holmberg, Magnus Westerlund, Stephen Botzko, and Geir Arne Sandbakken for their review comments.

In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS TRACK] This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK] Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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. Note that the force of these words is modified by the requirement level of the document in which they are used. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK] The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS TRACK] This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS TRACK] The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS TRACK] Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]