rfc3264.txt

RFC 的详细文档！

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


   no reason to change it, the ordering of codecs in the answer be 8,
   48, and not 48, 8.  This helps assure that the same codec is used in
   both directions.

   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the answer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.

   The answerer MAY include a non-zero ptime attribute for any media
   stream; this indicates the packetization interval that the answerer
   would like to receive.  There is no requirement that the
   packetization interval be the same in each direction for a particular
   stream.

   The answerer MAY include a bandwidth attribute for any media stream;
   this indicates the bandwidth that the answerer would like the offerer
   to use when sending media.  The value of zero is allowed, interpreted
   as described in Section 5.

   If the answerer has no media formats in common for a particular
   offered stream, the answerer MUST reject that media stream by setting
   the port to zero.

   If there are no media formats in common for all streams, the entire
   offered session is rejected.

   Once the answerer has sent the answer, it MUST be prepared to receive
   media for any recvonly streams described by that answer.  It MUST be
   prepared to send and receive media for any sendrecv streams in the
   answer, and it MAY send media immediately.  The answerer MUST be
   prepared to receive media for recvonly or sendrecv streams using any
   media formats listed for those streams in the answer, and it MAY send
   media immediately.  When sending media, it SHOULD use a packetization
   interval equal to the value of the ptime attribute in the offer, if
   any was present.  It SHOULD send media using a bandwidth no higher
   than the value of the bandwidth attribute in the offer, if any was
   present.  The answerer MUST send using a media format in the offer
   that is also listed in the answer, and SHOULD send using the most
   preferred media format in the offer that is also listed in the



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


   answer.  In the case of RTP, it MUST use the payload type numbers
   from the offer, even if they differ from those in the answer.

6.2 Multicast Streams

   Unlike unicast, where there is a two-sided view of the stream, there
   is only a single view of the stream for multicast.  As such,
   generating an answer to a multicast offer generally involves
   modifying a limited set of aspects of the stream.

   If a multicast stream is accepted, the address and port information
   in the answer MUST match that of the offer.  Similarly, the
   directionality information in the answer (sendonly, recvonly, or
   sendrecv) MUST equal that of the offer.  This is because all
   participants in a multicast session need to have equivalent views of
   the parameters of the session, an underlying assumption of the
   multicast bias of RFC 2327.

   The set of media formats in the answer MUST be equal to or be a
   subset of those in the offer.  Removing a format is a way for the
   answerer to indicate that the format is not supported.

   The ptime and bandwidth attributes in the answer MUST equal the ones
   in the offer, if present.  If not present, a non-zero ptime MAY be
   added to the answer.

7 Offerer Processing of the Answer

   When the offerer receives the answer, it MAY send media on the
   accepted stream(s) (assuming it is listed as sendrecv or recvonly in
   the answer).  It MUST send using a media format listed in the answer,
   and it SHOULD use the first media format listed in the answer when it
   does send.

      The reason this is a SHOULD, and not a MUST (its also a SHOULD,
      and not a MUST, for the answerer), is because there will
      oftentimes be a need to change codecs on the fly.  For example,
      during silence periods, an agent might like to switch to a comfort
      noise codec.  Or, if the user presses a number on the keypad, the
      agent might like to send that using RFC 2833 [9].  Congestion
      control might necessitate changing to a lower rate codec based on
      feedback.

   The offerer SHOULD send media according to the value of any ptime and
   bandwidth attribute in the answer.

   The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer.



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


8 Modifying the Session

   At any point during the session, either participant MAY issue a new
   offer to modify characteristics of the session.  It is fundamental to
   the operation of the offer/answer model that the exact same
   offer/answer procedure defined above is used for modifying parameters
   of an existing session.

   The offer MAY be identical to the last SDP provided to the other
   party (which may have been provided in an offer or an answer), or it
   MAY be different.  We refer to the last SDP provided as the "previous
   SDP".  If the offer is the same, the answer MAY be the same as the
   previous SDP from the answerer, or it MAY be different.  If the
   offered SDP is different from the previous SDP, some constraints are
   placed on its construction, discussed below.

   Nearly all aspects of the session can be modified.  New streams can
   be added, existing streams can be deleted, and parameters of existing
   streams can change.  When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP.  If the version in the origin
   line does not increment, the SDP MUST be identical to the SDP with
   that version number.  The answerer MUST be prepared to receive an
   offer that contains SDP with a version that has not changed; this is
   effectively a no-op.  However, the answerer MUST generate a valid
   answer (which MAY be the same as the previous SDP from the answerer,
   or MAY be different), according to the procedures defined in Section
   6.

   If an SDP is offered, which is different from the previous SDP, the
   new SDP MUST have a matching media stream for each media stream in
   the previous SDP.  In other words, if the previous SDP had N "m="
   lines, the new SDP MUST have at least N "m=" lines.  The i-th media
   stream in the previous SDP, counting from the top, matches the i-th
   media stream in the new SDP, counting from the top.  This matching is
   necessary in order for the answerer to determine which stream in the
   new SDP corresponds to a stream in the previous SDP.  Because of
   these requirements, the number of "m=" lines in a stream never
   decreases, but either stays the same or increases.  Deleted media
   streams from a previous SDP MUST NOT be removed in a new SDP;
   however, attributes for these streams need not be present.

8.1 Adding a Media Stream

   New media streams are created by new additional media descriptions
   below the existing ones, or by reusing the "slot" used by an old
   media stream which had been disabled by setting its port to zero.



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


   Reusing its slot means that the new media description replaces the
   old one, but retains its positioning relative to other media
   descriptions in  the SDP.  New media descriptions MUST appear below
   any existing media sections.  The rules for formatting these media
   descriptions are identical to those described in Section 5.

   When the answerer receives an SDP with more media descriptions than
   the previous SDP from the offerer, or it receives an SDP with a media
   stream in a slot where the port was previously zero, the answerer
   knows that new media streams are being added.  These can be rejected
   or accepted by placing an appropriately structured media description
   in the answer.  The procedures for constructing the new media
   description in the answer are described in Section 6.

8.2 Removing a Media Stream

   Existing media streams are removed by creating a new SDP with the
   port number for that stream set to zero.  The stream description MAY
   omit all attributes present previously, and MAY list just a single
   media format.

   A stream that is offered with a port of zero MUST be marked with port
   zero in the answer.  Like the offer, the answer MAY omit all
   attributes present previously, and MAY list just a single media
   format from amongst those in the offer.

   Removal of a media stream implies that media is no longer sent for
   that stream, and any media that is received is discarded.  In the
   case of RTP, RTCP transmission also ceases, as does processing of any
   received RTCP packets.  Any resources associated with it can be
   released.  The user interface might indicate that the stream has
   terminated, by closing the associated window on a PC, for example.

8.3 Modifying a Media Stream

   Nearly all characteristics of a media stream can be modified.

8.3.1 Modifying Address, Port or Transport

   The port number for a stream MAY be changed.  To do this, the offerer
   creates a new media description, with the port number in the m line
   different from the corresponding stream in the previous SDP.  If only
   the port number is to be changed, the rest of the media stream
   description SHOULD remain unchanged.  The offerer MUST be prepared to
   receive media on both the old and new ports as soon as the offer is
   sent.  The offerer SHOULD NOT cease listening for media on the old
   port until the answer is received and media arrives on the new port.
   Doing so could result in loss of media during the transition.



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


   Received, in this case, means that the media is passed to a media
   sink.  This means that if there is a playout buffer, the agent would
   continue to listen on the old port until the media on the new port
   reached the top of the playout buffer.  At that time, it MAY cease
   listening for media on the old port.

   The corresponding media stream in the answer MAY be the same as the
   stream in the previous SDP from the answerer, or it MAY be different.
   If the updated stream is accepted by the answerer, the answerer
   SHOULD begin sending traffic for that stream to the new port
   immediately.  If the answerer changes the port from the previous SDP,
   it MUST be prepared to receive media on both the old and new ports as
   soon as the answer is sent.  The answerer MUST NOT cease listening
   for media on the old port until media arrives on the new port.  At
   that time, it MAY cease listening for media on the old port.  The
   same is true for an offerer that sends an updated offer with a new
   port; it MUST NOT cease listening for media on the old port until
   media arrives on the new port.

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

   To change the IP address where media is sent to, the same procedure
   is followed for changing the port number.  The only difference is
   that the connection line is updated, not the port number.

   The transport for a stream MAY be changed.  The process for doing
   this is identical to changing the port, except the transport is
   updated, not the port.

8.3.2 Changing the Set of Media Formats

   The list of media formats used in the session MAY be changed.  To do
   this, the offerer creates a new media description, with the list of
   media formats in the "m=" line different from the corresponding media
   stream in the previous SDP.  This list MAY include new formats, and
   MAY remove formats present from the previous SDP.  However, in the
   case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session.  However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.




Rosenberg & Schulzrinne     Standards Track                    [Page 15]