--- 1/draft-ietf-mmusic-sdp-new-23.txt 2006-02-05 00:28:56.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-24.txt 2006-02-05 00:28:56.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design -Expires: June 10, 2005 C. Perkins +Expires: August 19, 2005 C. Perkins University of Glasgow - December 10, 2004 + February 18, 2005 SDP: Session Description Protocol - draft-ietf-mmusic-sdp-new-23.txt + draft-ietf-mmusic-sdp-new-24.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. @@ -28,25 +28,25 @@ 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 10, 2005. + This Internet-Draft will expire on August 19, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract 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. Table of Contents @@ -72,21 +72,21 @@ 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 13 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 16 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 17 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 18 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 21 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 22 - 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 + 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 12.1 Normative References . . . . . . . . . . . . . . . . . . . 44 @@ -1012,20 +1012,28 @@ is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" field, and on the transport protocol defined in the sub-field of the media field. Other ports used by the media application (such as the RTCP port [18]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example "a=rtcp:" as defined in [21]). + If non-contiguous ports are used or if they don't follow the + parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" + attribute MUST be used. Applications that are requested to send + media to a that is odd and where the "a=rtcp:" is present + MUST NOT substract 1 to the RTP port: i.e, they MUST send the RTP + to the port indicated in and send the RTCP to the port + indicated in the "a=rtcp" attribute. + For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" field: m= / ... In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even numbered ports are used for data with the corresponding one-higher odd ports used for the @@ -2220,18 +2226,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 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. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.