RFC 3388 (rfc3388) - Page 2 of 21
Grouping of Media Lines in the Session Description Protocol (SDP)
Alternative Format: Original Text Document
RFC 3388 Grouping of Media Lines in SDP December 2002 7.5.1 Parallel Encoding Using Different Codecs........... 11 7.5.2 Layered Encoding................................... 12 7.5.3 Same IP Address and Port Number.................... 12 8. Usage of the "group" Attribute in SIP........................ 13 8.1 Mid Value in Answers..................................... 13 8.1.1 Example............................................ 14 8.2 Group Value in Answers................................... 15 8.2.1 Example............................................ 15 8.3 Capability Negotiation................................... 16 8.3.1 Example............................................ 17 8.4 Backward Compatibility................................... 17 8.4.1 Offerer does not Support "group"................... 17 8.4.2 Answerer does not Support "group".................. 17 9. Security Considerations................................... 18 10. IANA Considerations....................................... 18 11. Acknowledgements.......................................... 19 12. References................................................ 19 13. Authors' Addresses........................................ 20 14. Full Copyright Statement.................................. 21 1. Introduction An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams. While in some environments this information can be carried out of band, it would be desirable to have extensions to SDP that allow the expression of how different media streams within a session description relate to each other. This document defines such extensions. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. Camarillo et. al. Standards Track



