For declarative use of SDP in the Session Announcement Protocol (SAP) [12] and the Real Time Streaming Protocol (RTSP) [13], the following considerations apply:
o Any ’maxptime’ and ’ptime’ values should be selected with care to ensure that the session’s participants can achieve reasonable performance.
o The payload format configuration parameters are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small. For declarative examples, see Section 17.
meet the column width constraints of this document. The backslash ("\") at the end of a line and the carriage return that follows it should be ignored. Note that media subtype names are
insensitive. Parameter names are case-insensitive both in media types and in the mapping to the SDP a=fmtp attribute.
Example usage of EVRCWB:
m=audio 49120 RTP/AVP 97 98 a=rtpmap:97 EVRCWB/16000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4;sendmode=0 a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
Example usage of EVRCWB0:
m=audio 49120 RTP/AVP 97 98 a=rtpmap:97 EVRCWB0/16000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4;sendmode=0 a=fmtp:98 recvmode=0 sendmode=0
Example SDP answer from a media gateway requesting a terminal to limit its encoder operation to EVRC-WB mode 4:
m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRCWB0/16000
a=fmtp:97 mode-set-recv=4;sendmode=4 Example usage of EVRCWB1:
m=audio 49120 RTP/AVP 97 98 a=rtpmap:97 EVRCWB1/16000
a=fmtp:97 mode-set-recv=4;sendmode=4 a=maxptime:100
Example usage of EVRCWB with DTX with silencesupp=1:
m=audio 49120 RTP/AVP 97 98 a=rtpmap:97 EVRCWB/16000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ mode-set-recv=0,4; sendmode=0
a=fmtp:98 recvmode=0 sendmode=0 a=maxptime:120
Example usage of EVRCWB with DTX with silencesupp=0:
m=audio 49120 RTP/AVP 97 98 a=rtpmap:97 EVRCWB/16000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ mode-set-recv=0,4;sendmode=0
Example offer-answer exchange between EVRC-WB and legacy EVRC-B (RFC 4788):
m=audio 55954 RTP/AVP 98 99 a=rtpmap:98 EVRCWB0/16000 a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4; sendmode=0 a=fmtp:99 recvmode=0 sendmode=0
Answer:
m=audio 55954 RTP/AVP 99 a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
In the above example, note that the answerer has chosen to send in mode 4 even though the offerer was willing to receive in mode 0. ’recvmode’ is a receiver’s preference, but the sender can send in a different mode.
Example offer-answer exchanges for interoperability between legacy (RFC 4788) and updated EVRC-B (RFC 5188) implementations:
Offer from an offerer that supports updated EVRC-B (RFC 5188) implementation:
m=audio 55954 RTP/AVP 99 a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
Answer from an answerer that supports only legacy EVRC-B (RFC 4788) implementation:
m=audio 55954 RTP/AVP 99 a=rtpmap:99 EVRCB0/8000
Offer from an offerer that supports only legacy EVRC-B (RFC 4788) implementation:
m=audio 55954 RTP/AVP 99 a=rtpmap:99 EVRCB0/8000
Answer from an answerer that supports updated EVRC-B (RFC 5188) implementation:
m=audio 55954 RTP/AVP 99 a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4 18. Security Considerations
Since compression is applied to the payload formats end-to-end, and the encodings do not exhibit significant non-uniformity,
implementations of this specification are subject to all the security considerations specified in RFC 3558 [2]. Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [2], RFC 3550 [6], and any appropriate profile (for example, RFC 3551 [11]).
19. Changes to RFC 4788
This document updates RFC 4788 [3], and the updates are summarized below:
o Added new media type attribute "sendmode" to media subtypes EVRCB and EVRCB0. This attribute can be used to signal the EVRC-B encoder’s current mode of operation.
o Added new media type attribute "recvmode" to media subtypes EVRCB and EVRCB0. This attribute can be used to signal the EVRC-B decoder’s preferred operating mode to a remote sender.
20. References
20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558,
July 2003.
[3] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for EVRC Family Codecs", RFC 4788, January 2007.
[4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B v1.0 , May 2006.
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, March 1997.
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[9] Casner, S., "Media Type Specifications and Registration Procedures", RFC 4855, February 2007.
[10] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
20.2. Informative References
[11] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[12] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[13] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
Authors’ Addresses Harikishan Desineni Qualcomm
5775 Morehouse Drive San Diego, CA 92126 USA
Phone: +1 858 845 8996 EMail: hd@qualcomm.com
URI: http://www.qualcomm.com
Qiaobing Xie Motorola
1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 USA
Phone: +1-847-372-8481
EMail: Qiaobing.Xie@Gmail.com URI: http://www.motorola.com
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.