rfc3264.txt

RFC 的详细文档！

   Alice accepts the additional media stream, and so generates the
   following answer:

   v=0
   o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 0 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000
   m=audio 53122 RTP/AVP 110
   a=rtpmap:110 telephone-events/8000
   a=sendonly

10.2 One of N Codec Selection

   A common occurrence in embedded phones is that the Digital Signal
   Processor (DSP) used for compression can support multiple codecs at a
   time, but once that codec is selected, it cannot be readily changed
   on the fly.  This example shows how a session can be set up using an
   initial offer/answer exchange, followed immediately by a second one
   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









Rosenberg & Schulzrinne     Standards Track                    [Page 21]

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002


   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.




Rosenberg & Schulzrinne     Standards Track                    [Page 22]

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002


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", RFC 2327, April 1998.

   [2]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Kumar, R. and M. Mostafa, "Conventions For the Use of The
         Session Description Protocol (SDP) for ATM Bearer Connections",
         RFC 3108, May 2001.



Rosenberg & Schulzrinne     Standards Track                    [Page 23]

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002


   [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", RFC 1890, January 1996.

15 Informative References

   [6]   Handley, M., Perkins, C. and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [8]   Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [9]   Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [10]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

16 Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936

   EMail: [e-mail]


   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA

   EMail: [e-mail]







Rosenberg & Schulzrinne     Standards Track                    [Page 24]

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002


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 RFC Editor function is currently provided by the
   Internet Society.



















Rosenberg & Schulzrinne     Standards Track                    [Page 25]