SDP

RFC 2327解释了SDP里各项域的意义，而RFC 3264则解释了SDP的Offer/Answer模型。在本文中，只针对unicast单播情况下的SDP进行描述。

SDP包括以下基本内容：
o Session name and purpose
o Time(s) the session is active
o The media comprising the session
o Information to receive those media (addresses, ports, formats and so on)

SDP的媒体信息包括：
o The type of media (video, audio, etc)
o The transport protocol (RTP/UDP/IP, H.320, etc)
o The format of the media (H.261 video, MPEG video, etc)
对于unicast而言，还包括：
o Remote address for media
o Transport port for contact address

具体而言，SDP可以包括以下的域（*表示可选）：
Session description：
        v=  (protocol version)
        o=  (owner/creator and session identifier).
        s=  (session name)
        i=* (session information)
        u=* (URI of description)
        e=* (email address)
        p=* (phone number)
        c=* (connection information - not required if included in all media)
        b=* (bandwidth information)
        One or more time descriptions (see below)
        z=* (time zone adjustments)
        k=* (encryption key)
        a=* (zero or more session attribute lines)
        Zero or more media descriptions (see below)

Time description
        t=  (time the session is active)
        r=* (zero or more repeat times)

Media description
        m=  (media name and transport address)
        i=* (media title)
        c=* (connection information - optional if included at session-level)
        b=* (bandwidth information)
        k=* (encryption key)
        a=* (zero or more media attribute lines)

以上各行的细则：

   o=    

   

the tuple of , , , 
 and 
 form a 
globally unique identifier for the session.
除了version的其他域的元组标识了一个唯一的session。
The method of  allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) timestamp be 
used to ensure uniqueness.
建议使用NTP来确保session id的唯一性。
标识了一个session中SDP的版本，同样建议使用NTP。

   s=
The "s=" field is the session name.  There must be one and only one "s=" field per session 
description.

   c= 
 

   t=  
The first and second sub-fields give the start and stop times for the conference respectively.
These values are the decimal representation of Network Time Protocol (NTP) time values in
seconds.

   m=   

The general form of an rtpmap attribute is:
   a=rtpmap: /[/]

还有其他需要添加的attribute，例如sendrecv等。

SDP的交互流程：
1.Generating the Initial Offer
   The numeric value of the session id
   and version in the o line MUST be representable with a 64 bit signed
   integer.  The initial value of the version MUST be less than
   (2**62)-1, to avoid rollovers.
"o="的version和session id必须能被64位的有符号整数代表。换成10进制数的范围是。。。

   The SDP "s=" line conveys the subject of the session, which is
   reasonably defined for multicast, but ill defined for unicast.  For
   unicast sessions, it is RECOMMENDED that it consist of a single space
   character (0x20) or a dash (-).

   The SDP "t=" line conveys the time of the session.  Generally,
   streams for unicast sessions are created and destroyed through
   external signaling means, such as SIP.  In that case, the "t=" line
   SHOULD have a value of "0 0".

   In the case of RTP streams, all media descriptions SHOULD contain
   "a=rtpmap" mappings from RTP payload types to encodings. 

   In all cases, the formats in the "m=" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.

多种格式的媒体按照顺序排列，具有优先级的差别。

2.Generating the Answer
   The answer to an offered session description is based on the offered
   session description.  If the answer is different from the offer in
   any way (different IP addresses, ports, etc.), the origin line MUST
   be different in the answer, since the answer is generated by a
   different entity.  In that case, the version number in the "o=" line
   of the answer is unrelated to the version number in the o line of the
   offer.
如果answer和offer有任何的不同，那么origin line必须不同。在这种情况下，"o="的version
和Offer里的没有联系，因为它们产生于不同实体。


   For each "m=" line in the offer, there MUST be a corresponding "m="
   line in the answer.  The answer MUST contain exactly the same number
   of "m=" lines as the offer.  This allows for streams to be matched up
   based on their order.  This implies that if the offer contained zero
   "m=" lines, the answer MUST contain zero "m=" lines.

   The "t=" line in the answer MUST equal that of the offer.  The time
   of the session cannot be negotiated.

   An offered stream MAY be rejected in the answer, for any reason.  If
   a stream is rejected, the offerer and answerer MUST NOT generate
   media (or RTCP packets) for that stream.  To reject an offered
   stream, the port number in the corresponding stream in the answer
   MUST be set to zero.  Any media formats listed are ignored.  At least
   one MUST be present, as specified by SDP.

   Once the answerer has sent the answer, it MUST be prepared to receive
   media for any recvonly streams described by that 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). 

   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.
当发生了修改session的offer的时候，"o="必须和前面的SDP一样，除了version number需要加1。

   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.
"m="的数目必须和前面的SDP一致。

   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.

   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.