SDP协议学习笔记
SDP:Session Description Protocol
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=* (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)
以上带"*"号的是可选的,其余的是必须的。一般顺序也按照上面的顺序来排列。
a=*是sdp协议扩展属性定义，除上面以外的，分解时其它的都可以扔掉。
a=charset属性指定协议使用的字符集。一般的是ISO-10646。
示例：
v=
其中：nettype是IN,代表internet,addrtype是IP4或IP6。unicast-address任务创建计算机的地址。
整个这个属性，是唯一表示一个任务。
[email protected] 或 p=+1 616 555-6011
对 于一个任务只能两者之中的一个，表示会议控制者的联系方式。邮件地址可以是[email][email protected][/email] (Jane Doe)形式，括号里面的是描述联系人的名称，或者Jane Doe <[email][email protected][/email]>，前面的是联系人的名称。
c=
这 个连接数据，可以是传话级别的连接数据，或者是单独一个媒体数据的连接数据。在是多播时，connection-address就该是一个多播组地址，当 是单播时，connection-address就该是一个单播地址。对于addrtype是IP4的情况下，connection-address不仅 包含IP地址，并且还要包含a time to live value(TTL 0-255)，如：c=IN IP4 224.2.36.42/128，IP6没有这个TTL值。还允许象这样的
b=
t=
r=
d - days (86400 seconds)
h - hours (3600 seconds)
m - minutes (60 seconds)
s - seconds (allowed for completeness)
z=
k=
k=
a=
a=
m=
m=
其 中：
a=cat:
a=keywds:
a=tool:
a=ptime:
a=maxptime:
a=rtpmap:
a=recvonly
a=sendrecv
a=sendonly
a=inactive，
a=orient:
a=type:
a=charset:
a=sdplang:
a=framerate:设置最大视频帧速率
a=quality:
a=fmtp:
在SIP协议的包含的内容是SDP时，应该把Content-Type设置成application/sdp。
| 0 | PCMU | A | 8,000 | 1 | PCMU denotes PCM (pulse code modulation) with mu-law scaling; it is specified in ITU-T G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. |
| 1 | reserved | A | This payload type was assigned to "1016" in RFC1890 but was removed because two interoperable implementations were not found. | ||
| 2 | reserved | A | This payload type was assigned to "G721" in RFC1890 but its use is now deprecated. | ||
| 3 | GSM | A | 8,000 | 1 | GSM (Global System for Mobile Communications) denotes the European GSM 06.10 standard for full-rate speech transcoding, ETS 300 961, which is based on RPE/LTP (residual pulse excitation/long term prediction) coding. Blocks of 160 audio samples are compressed into 33 octets, for an effective data rate of 13,200 b/s. |
| 4 | G723 | A | 8,000 | 1 | G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s". |
| 5 | DVI4 | A | 8,000 | 1 | DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding scheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding defined in RFC3551 as DVI4 differs in three respects from the IMA specification. |
| 6 | DVI4 | A | 16,000 | 1 | |
| 7 | LPC | A | 8,000 | 1 | LPC designates an experimental linear predictive encoding contributed by Ron Frederick, which is based on an implementation written by Ron Zuckerman posted to the Usenet group comp.dsp on June 26, 1992. The codec generates 14 octets for every frame. The framesize is set to 20 ms, resulting in a bit rate of 5,600 b/s. |
| 8 | PCMA | A | 8,000 | 1 | PCMU denotes PCM (pulse code modulation) with A-law scaling; it is specified in ITU-T G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. |
| 9 | G722 | A | 8,000 | 1 | G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding within 64 kbit/s". Even though the actual sampling rate for G.722 audio is 16,000 Hz, the RTP clock rate for the G722 payload format is 8,000 Hz because that value was erroneously assigned in RFC1890 and must remain unchanged for backward compatibility. |
| 10 | L16 | A | 44,100 | 2 | L16 denotes uncompressed audio data samples, using 16-bit signed representation with 65,535 equally divided steps between minimum and maximum signal level, ranging from -32,768 to 32,767. The value is represented in two's complement notation and transmitted in network byte order (most significant byte first). |
| 11 | L16 | A | 44,100 | 1 | |
| 12 | QCELP | A | 8,000 | 1 | The Electronic Industries Association (EIA) & Telecommunications Industry Association (TIA) standard IS-733, "TR45: High Rate Speech Service Option for Wideband Spread Spectrum Communications Systems", defines the QCELP audio compression algorithm for use in wireless CDMA applications. The QCELP CODEC compresses each 20 milliseconds of 8,000 Hz, 16-bit sampled input speech into one of four different size output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits) or Rate 1/8 (20 bits). For typical speech patterns, this results in an average output of 6.8 kb/s for normal mode and 4.7 kb/s for reduced rate mode. The packetization of the QCELP audio codec is described in RFC 2658. |
| 13 | CN | A | 8,000 | 1 | The comfort noise (CN) payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711, G.726, G.727, G.728, and G.722. The payload format is specified in RFC 3389. |
| 14 | MPA | A | 90,000 | 1 | MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary streams. The encoding is defined in ISO standards ISO/IEC 11172-3 and 13818-3. The encapsulation is specified in RFC 2250. |
| 15 | G728 | A | 8,000 | 1 | G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction". |
| 16 | DVI4 | A | 11,025 | 1 | DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding scheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding defined in RFC 3651 as DVI4 differs from the IMA specification. |
| 17 | DVI4 | A | 22,050 | 1 | |
| 18 | G729 | A | 8,000 | 1 | G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 8 kbit/s using conjugate structure-algebraic code excited linear prediction (CS-ACELP)". |
| 19 | reserved | A | Payload type 19 is marked "reserved" because some draft versions of RFC 3651 assigned that number to an earlier version of the comfort noise payload format. | ||
| 20 | unassigned | A | |||
| 21 | unassigned | A | |||
| 22 | unassigned | A | |||
| 23 | unassigned | A | |||
| 24 | unassigned | V | |||
| 25 | CelB | V | 90,000 | The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The byte stream format is described in RFC 2029. | |
| 26 | JPEG | V | 90,000 | The encoding is specified in ISO Standards 10918-1 and 10918-2. The RTP payload format is as specified in RFC 2435. | |
| 27 | unassigned | V | |||
| 28 | nv | V | 90,000 | The encoding is implemented in the program 'nv', version 4, developed at Xerox PARC by Ron Frederick. | |
| 29 | unassigned | V | |||
| 30 | unassigned | V | |||
| 31 | H261 | V | 90,000 | The encoding is specified in ITU-T Recommendation H.261, "Video codec for audiovisual services at p x 64 kbit/s". The packetization and RTP-specific properties are described in RFC 2032. | |
| 32 | MPV | V | 90,000 | MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, respectively. The RTP payload format is as specified in RFC 2250, Section 3. | |
| 33 | MP2T | AV | 90,000 | MP2T designates the use of MPEG-2 transport streams, for either audio or video. The RTP payload format is described in RFC 2250, Section 2. | |
| 34 | H263 | V | 90,000 | The encoding is specified in the 1996 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2190. The H263-1998 payload format is RECOMMENDED over this one for use by new implementations. | |
| 35-71 | unassigned | ? | |||
| 72-76 | reserved | Reserved for RTCP conflict avoidance | |||
| 77-95 | unassigned | ? | |||
| 96-127 | dynamic | ? | RTP A/V profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types. | ||