type.
Author/Change controller:
alan.duric@telio.no
IETF Audio/Video transport working group
5. Mapping To SDP Parameters
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[5], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the iLBC codec, the mapping is as
follows:
o The MIME type ("audio") goes in SDP "m=" as the media name.
o The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
o The parameter "mode" goes in the SDP "a=fmtp" attribute by copying
it directly from the MIME media type string as "mode=value".
When conveying information by SDP, the encoding name SHALL be "iLBC"
(the same as the MIME subtype).
An example of the media representation in SDP for describing iLBC
might be:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive
"mode" parameter in the SDP "a=fmtp" attribute by copying them
directly from the MIME media type string as a semicolon separated
with parameter=value, where parameter is "mode", and values can be 0
and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame
size). An example of the media representation in SDP for describing
iLBC when 20 ms frame size mode is used might be:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
It is important to emphasize the bi-directional character of the
"mode" parameter - both sides of a bi-directional session MUST use
the same "mode" value.
The offer contains the preferred mode of the offerer. The answerer
may agree to that mode by including the same mode in the answer, or
may include a different mode. The resulting mode used by both
parties SHALL be the lower of the bandwidth modes in the offer and
answer.
That is, an offer of "mode=20" receiving an answer of "mode=30" will
result in "mode=30" being used by both participants. Similarly, an
offer of "mode=30" and an answer of "mode=20" will result in
"mode=30" being used by both participants.
This is important when one end point utilizes a bandwidth constrained
link (e.g., 28.8k modem link or slower), where only the lower frame
size will work.
Parameter ptime can not be used for the purpose of specifying iLBC
operating mode, due to fact that for the certain values it will be
impossible to distinguish which mode is about to be used (e.g., when
ptime=60, it would be impossible to distinguish if packet is carrying
2 frames of 30 ms or 3 frames of 20 ms, etc.).
Note that the payload format (encoding) names are commonly shown in
upper case. MIME subtypes are commonly shown in lower case. These
names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in MIME types and in the default
mapping to the SDP a=fmtp attribute
6. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in [3]
and any appropriate profile (e.g., [4]).
As this format transports encoded speech, the main security issues
include confidentiality and authentication of the speech itself. The
payload format itself does not have any built-in security mechanisms.
Confidentiality of the media streams is achieved by encryption,
therefore external mechanisms, such as SRTP [6], MAY be used for that
purpose. The data compression used with this payload format is
applied end-to-end; hence encryption may be performed after
compression with no conflict between the two operations.
A potential denial-of-service threat exists for data encoding using
compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological datagrams
into the stream which are complex to decode and cause the receiver to
become overloaded. However, the encodings covered in this document
do not exhibit any significant non-uniformity.
7. References
7.1. Normative References
[1] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and
J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951,
December 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol", RFC 3711,
March 2004.
7.2. Informative References
[7] ITU-T Recommendation G.711, available online from the ITU
bookstore at http://www.itu.int.
8. Acknowledgements
Henry Sinnreich, Patrik Faltstrom, Alan Johnston and Jean-Francois
Mule for great support of the iLBC initiative and for valuable
feedback and comments.
Authors’ Addresses
Alan Duric
Telio AS
Stoperigt. 2
Oslo, N-0250
Norway
Phone: +47 21673505
EMail: alan.duric@telio.no
Soren Vang Andersen
Department of Communication Technology
Aalborg University
Fredrik Bajers Vej 7A
9200 Aalborg
Denmark
Phone: ++45 9 6358627
EMail: sva@kom.auc.dk
Full Copyright Statement
Copyright (C) The Internet Society (2004).
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 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 IETF’s procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.