rfc3264.txt

RFC 的详细文档！

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002


      The mappings need to remain fixed for the duration of the session
      because of the loose synchronization between signaling exchanges
      of SDP and the media stream.

   The corresponding media stream in the answer is formulated as
   described in Section 6, and may result in a change in media formats
   as well.  Similarly, as described in Section 6, as soon as it sends
   its answer, the answerer MUST begin sending media using any formats
   in the offer that were also present in the answer, and SHOULD use the
   most preferred format in the offer that was also listed in the answer
   (assuming the stream allows for sending), and MUST NOT send using any
   formats that are not in the offer, even if they were present in a
   previous SDP from the peer.  Similarly, when the offerer receives the
   answer, it MUST begin sending media using any formats in the answer,
   and SHOULD use the most preferred one (assuming the stream allows for
   sending), and MUST NOT send using any formats that are not in the
   answer, even if they were present in a previous SDP from the peer.

   When an agent ceases using a media format (by not listing that format
   in an offer or answer, even though it was in a previous SDP) the
   agent will still need to be prepared to receive media with that
   format for a brief time.  How does it know when it can be prepared to
   stop receiving with that format? If it needs to know, there are three
   techniques that can be applied.  First, the agent can change ports in
   addition to changing formats.  When media arrives on the new port, it
   knows that the peer has ceased sending with the old format, and it
   can cease being prepared to receive with it.  This approach has the
   benefit of being media format independent.  However, changes in ports
   may require changes in resource reservation or rekeying of security
   protocols.  The second approach is to use a totally new set of
   dynamic payload types for all codecs when one is discarded.  When
   media is received with one of the new payload types, the agent knows
   that the peer has ceased sending with the old format.  This approach
   doesn't affect reservations or security contexts, but it is RTP
   specific and wasteful of a very small payload type space.  A third
   approach is to use a timer.  When the SDP from the peer is received,
   the timer is set.  When it fires, the agent can cease being prepared
   to receive with the old format.  A value of one minute would
   typically be more than sufficient.  In some cases, an agent may not
   care, and thus continually be prepared to receive with the old
   formats.  Nothing need be done in this case.

   Of course, if the offered stream is rejected, the offer can cease
   being prepared to receive using any new formats as soon as the
   rejection is received.






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


8.3.3 Changing Media Types

   The media type (audio, video, etc.) for a stream MAY be changed.  It
   is RECOMMENDED that the media type be changed (as opposed to adding a
   new stream), when the same logical data is being conveyed, but just
   in a different media format.  This is particularly useful for
   changing between voiceband fax and fax in a single stream, which are
   both separate media types.  To do this, the offerer creates a new
   media description, with a new media type, in place of the description
   in the previous SDP which is to be changed.

   The corresponding media stream in the answer is formulated as
   described in Section 6.  Assuming the stream is acceptable, the
   answerer SHOULD begin sending with the new media type and formats as
   soon as it receives the offer. The offerer MUST be prepared to
   receive media with both the old and new types until the answer is
   received, and media with the new type is received and reaches the top
   of the playout buffer.

8.3.4 Changing Attributes

   Any other attributes in a media description MAY be updated in an
   offer or answer.  Generally, an agent MUST send media (if the
   directionality of the stream allows) using the new parameters once
   the SDP with the change is received.

8.4 Putting a Unicast Media Stream on Hold

   If a party in a call wants to put the other party "on hold", i.e.,
   request that it temporarily stops sending one or more unicast media
   streams, a party offers the other an updated SDP.

   If the stream to be placed on hold was previously a sendrecv media
   stream, it is placed on hold by marking it as sendonly.  If the
   stream to be placed on hold was previously a recvonly media stream,
   it is placed on hold by marking it inactive.

   This means that a stream is placed "on hold" separately in each
   direction.  Each stream is placed "on hold" independently.  The
   recipient of an offer for a stream on-hold SHOULD NOT automatically
   return an answer with the corresponding stream on hold.  An SDP with
   all streams "on hold" is referred to as held SDP.

      Certain third party call control scenarios do not work when an
      answerer responds to held SDP with held SDP.






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


   Typically, when a user "presses" hold, the agent will generate an
   offer with all streams in the SDP indicating a direction of sendonly,
   and it will also locally mute, so that no media is sent to the far
   end, and no media is played out.

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer.

9 Indicating Capabilities

   Before an agent sends an offer, it is helpful to know if the media
   formats in that offer would be acceptable to the answerer.  Certain
   protocols, like SIP, provide a means to query for such capabilities.
   SDP can be used in responses to such queries to indicate
   capabilities.  This section describes how such an SDP message is
   formatted.  Since SDP has no way to indicate that the message is for
   the purpose of capability indication, this is determined from the
   context of the higher layer protocol.  The ability of baseline SDP to
   indicate capabilities is very limited.  It cannot express allowed
   parameter ranges or values, and can not be done in parallel with an
   offer/answer itself.  Extensions might address such limitations in
   the future.

   An SDP constructed to indicate media capabilities is structured as
   follows.  It MUST be a valid SDP, except that it MAY omit both "e="
   and "p=" lines.  The "t=" line MUST be equal to "0 0".  For each
   media type supported by the agent, there MUST be a corresponding
   media description of that type.  The session ID in the origin field
   MUST be unique for each SDP constructed to indicate media
   capabilities.  The port MUST be set to zero, but the connection
   address is arbitrary.  The usage of port zero makes sure that an SDP
   formatted for capabilities does not cause media streams to be
   established if it is interpreted as an offer or answer.

   The transport component of the "m=" line indicates the transport for
   that media type.  For each media format of that type supported by the
   agent, there SHOULD be a media format listed in the "m=" line.  In
   the case of RTP, if dynamic payload types are used, an rtpmap



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


   attribute MUST be present to bind the type to a specific format.
   There is no way to indicate constraints, such as how many
   simultaneous streams can be supported for a particular codec, and so
   on.

   v=0
   o=carol 28908764872 28908764872 IN IP4 100.3.6.6
   s=-
   t=0 0
   c=IN IP4 192.0.2.4
   m=audio 0 RTP/AVP 0 1 3
   a=rtpmap:0 PCMU/8000
   a=rtpmap:1 1016/8000
   a=rtpmap:3 GSM/8000
   m=video 0 RTP/AVP 31 34
   a=rtpmap:31 H261/90000
   a=rtpmap:34 H263/90000

   Figure 1: SDP Indicating Capabilities

   The SDP of Figure 1 indicates that the agent can support three audio
   codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263).

10 Example Offer/Answer Exchanges

   This section provides example offer/answer exchanges.

10.1 Basic Exchange

   Assume that the caller, Alice, has included the following description
   in her offer.  It includes a bidirectional audio stream and two
   bidirectional video streams, using H.261 (payload type 31) and MPEG
   (payload type 32).  The offered SDP is:

   v=0
   o=alice 2890844526 2890844526 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 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000






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


   The callee, Bob, does not want to receive or send the first video
   stream, so he returns the SDP below as the answer:

   v=0
   o=bob 2890844730 2890844730 IN IP4 host.example.com
   s=
   c=IN IP4 host.example.com
   t=0 0
   m=audio 49920 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 0 RTP/AVP 31
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

   At some point later, Bob decides to change the port where he will
   receive the audio stream (from 49920 to 65422), and at the same time,
   add an additional audio stream as receive only, using the RTP payload
   format for events [9].  Bob offers the following SDP in the offer:

   v=0
   o=bob 2890844730 2890844731 IN IP4 host.example.com
   s=
   c=IN IP4 host.example.com
   t=0 0
   m=audio 65422 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 0 RTP/AVP 31
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000
   m=audio 51434 RTP/AVP 110
   a=rtpmap:110 telephone-events/8000
   a=recvonly



















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