SDP Specification

   An SDP session description is denoted by the media type
   "application/sdp" (See Section 8).

   An SDP session description is entirely textual using the ISO 10646
   character set in UTF-8 encoding.  SDP field names and attribute names
   use only the US-ASCII subset of UTF-8, but textual fields and
   attribute values MAY use the full ISO 10646 character set.  Field and 

   attribute values that use the full UTF-8 character set are never

   directly compared, hence there is no requirement for UTF-8
   normalisation.  The textual form, as opposed to a binary encoding
   such as ASN.1 or XDR, was chosen to enhance portability, to enable a
   variety of transports to be used, and to allow flexible, text-based
   toolkits to be used to generate and process session descriptions.
   However, since SDP may be used in environments where the maximum
   permissible size of a session description is limited, the encoding is
   deliberately compact.  Also, since announcements may be transported
   via very unreliable means or damaged by an intermediate caching
   server, the encoding was designed with strict order and formatting
   rules so that most errors would result in malformed session
   announcements that could be detected easily and discarded.  This also
   allows rapid discarding of encrypted session announcements for which
   a receiver does not have the correct key.

   An SDP session description consists of a number of lines of text of
   the form:

      <type>=<value>

   where <type> MUST be exactly one case-significant character and
   <value> is structured text whose format depends on <type>.  In
   general, <value> is either a number of fields delimited by a single
   space character or a free format string, and is case-significant
   unless a specific field defines otherwise.  Whitespace MUST NOT be
   used on either side of the "=" sign.

   An SDP session description consists of a session-level section
   followed by zero or more media-level sections.  The session-level
   part starts with a "v=" line and continues to the first media-level
   section.  Each media-level section starts with an "m=" line and
   continues to the next media-level section or end of the whole session
   description.  In general, session-level values are the default for
   all media unless overridden by an equivalent media-level value.

   Some lines in each description are REQUIRED and some are OPTIONAL,
   but all MUST appear in exactly the order given here (the fixed order
   greatly enhances error detection and allows for a simple parser).
   OPTIONAL items are marked with a "*".
      Session description
         v=  (protocol version)
         o=  (originator 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=* (zero or more bandwidth information lines)
         One or more time descriptions ("t=" and "r=" lines; see below)
         z=* (time zone adjustments)
         k=* (encryption key)
         a=* (zero or more session attribute lines)
         Zero or more media descriptions

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

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

   The set of type letters is deliberately small and not intended to be
   extensible -- an SDP parser MUST completely ignore any session
   description that contains a type letter that it does not understand.
   The attribute mechanism ("a=" described below) is the primary means
   for extending SDP and tailoring it to particular applications or
   media.  Some attributes (the ones listed in Section 6 of this memo)
   have a defined meaning, but others may be added on an application-,
   media-, or session-specific basis.  An SDP parser MUST ignore any
   attribute it doesn't understand.

   An SDP session description may contain URIs that reference external
   content in the "u=", "k=", and "a=" lines.  These URIs may be
   dereferenced in some cases, making the session description non-self-
   contained.

   The connection ("c=") and attribute ("a=") information in the
   session-level section applies to all the media of that session unless
   overridden by connection information or an attribute of the same name
   in the media description.  For instance, in the example below, each
   media behaves as if it were given a "recvonly" attribute.

   An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=j.doe@example.com (Jane Doe)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

   Text fields such as the session name and information are octet
   strings that may contain any octet with the exceptions of 0x00 (Nul),
   0x0a (ASCII newline), and 0x0d (ASCII carriage return).  The sequence
   CRLF (0x0d0a) is used to end a record, although parsers SHOULD be
   tolerant and also accept records terminated with a single newline
   character.  If the "a=charset" attribute is not present, these octet
   strings MUST be interpreted as containing ISO-10646 characters in
   UTF-8 encoding (the presence of the "a=charset" attribute may force
   some fields to be interpreted differently).

   A session description can contain domain names in the "o=", "u=",
   "e=", "c=", and "a=" lines.  Any domain name used in SDP MUST comply
   with [1], [2].  Internationalised domain names (IDNs) MUST be
   represented using the ASCII Compatible Encoding (ACE) form defined in
   [11] and MUST NOT be directly represented in UTF-8 or any other
   encoding (this requirement is for compatibility with RFC 2327 and
   other SDP-related standards, which predate the development of
   internationalised domain names).
	
   More details please refer to: http://www.ietf.org/rfc/rfc4566.txt