to lock down the set of codecs.
The initial offer from Alice to Bob indicates a single audio stream
with the three audio codecs that are available in the DSP. The
stream is marked as inactive, since media cannot be received until a
codec is locked down:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
Bob can support dynamic switching between PCMU and G.723. So, he
sends the following answer:
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
Alice can then select any one of these two codecs. So, she sends an
updated offer with a sendrecv stream:
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
Bob accepts the single codec:
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
If the answerer (Bob), was only capable of supporting one-of-N
codecs, Bob would select one of the codecs from the offer, and place
that in his answer. In this case, Alice would do a re-INVITE to
activate that stream with that codec.
As an alternative to using "a=inactive" in the first exchange, Alice
can list all codecs, and as soon as she receives media from Bob,
generate an updated offer locking down the codec to the one just
received. Of course, if Bob only supports one-of-N codecs, there
would only be one codec in his answer, and in this case, there is no
need for a re-INVITE to lock down to a single codec.
11 Security Considerations
There are numerous attacks possible if an attacker can modify offers
or answers in transit. Generally, these include diversion of media
streams (enabling eavesdropping), disabling of calls, and injection
of unwanted media streams. If a passive listener can construct fake
offers, and inject those into an exchange, similar attacks are
possible. Even if an attacker can simply observe offers and answers,
they can inject media streams into an existing conversation.
Offer/answer relies on transport within an application signaling
protocol, such as SIP. It also relies on that protocol for security
capabilities. Because of the attacks described above, that protocol
MUST provide a means for end-to-end authentication and integrity
protection of offers and answers. It SHOULD offer encryption of
bodies to prevent eavesdropping. However, media injection attacks
can alternatively be resolved through authenticated media exchange,
and therefore the encryption requirement is a SHOULD instead of a
MUST.
Replay attacks are also problematic. An attacker can replay an old
offer, perhaps one that had put media on hold, and thus disable media
streams in a conversation. Therefore, the application protocol MUST
provide a secure way to sequence offers and answers, and to detect
and reject old offers or answers.
SIP [7] meets all of these requirements.
12 IANA Considerations
There are no IANA considerations with this specification.
13 Acknowledgements
The authors would like to thank Allison Mankin, Rohan Mahy, Joerg
Ott, and Flemming Andreasen for their detailed comments.
14 Normative References
[1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Kumar, R. and M. Mostafa, "Conventions For the Use of The
Session Description Protocol (SDP) for ATM Bearer Connections",
RFC3108, May 2001.
[4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC1890, January 1996.
15 Informative References
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC2974, October 2000.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC3261, June 2002.
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC2326, April 1998.
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC2833, May 2000.
[10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC2543, March 1999.
16 Authors' Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
17. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.