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=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
   其中:nettype是IN,代表internet,addrtype是IP4或IP6。unicast-address任务创建计算机的地址。
   整个这个属性,是唯一表示一个任务。


e=123@126.com 或 p=+1 616 555-6011
对 于一个任务只能两者之中的一个,表示会议控制者的联系方式。邮件地址可以是[email]j.doe@example.com[/email] (Jane Doe)形式,括号里面的是描述联系人的名称,或者Jane Doe <[email]j.doe@example.com[/email]>,前面的是联系人的名称。


c=<nettype> <addrtype> <connection-address>
这 个连接数据,可以是传话级别的连接数据,或者是单独一个媒体数据的连接数据。在是多播时,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值。还允许象这样的<base multicast address>[/<ttl>]/<number of addresses>格式的connection-address。如:c=IN IP4 224.2.1.1/127/3等同于包含c=IN IP4 224.2.1.1/127, c=IN IP4 224.2.1.2/127, c=IN IP4 224.2.1.3/127三行内容。


b=<bwtype>:<bandwidth> bwtype可以是CT或AS,CT方式是设置整个会议的带宽,AS是设置单个会话的带宽。缺省带宽是千比特每秒。
t=<start-time> <stop-time>,这个可以有行,指定多个不规则时间段,如果是规则的时间段,则r=属性可以使用。start-time和stop- time都遵从NTP(Network Time Protocol),是以秒为单位,自从1900以来的时间。要转换为UNIX时间,减去2208988800。如果stop-time设置为0,则会话 没有时间限制。如果start-time也设置为0,则会话被认为是永久的。


r=<repeat-interval> <active duration> <offsets from start-time>重复次数在时间表示里面可以如下表示:
      d - days (86400 seconds)
      h - hours (3600 seconds)
      m - minutes (60 seconds)
      s - seconds (allowed for completeness)
z=<adjustment time> <offset> <adjustment time> <offset> ....
k=<method>
k=<method>:<encryption key>
a=<attribute>
a=<attribute>:<value>
m=<media> <port> <proto> <fmt> ...
m=<media> <port>/<number of ports> <proto> <fmt> ...
其 中:<media>可以是,"audio","video", "text", "application" and "message"。<port>是媒体传送的端口号,它依赖于c=和<proto>。<proto> 可以是,udp,RTP/AVP和RTP/SAVP。


a=cat:<category>分类,根据分类接收者隔离相应的会话
a=keywds:<keywords>关键字,根据关键字隔离相应的会话
a=tool:<name and version of tool>创建任务描述的工具的名称及版本号
a=ptime:<packet time>在一个包里面的以毫秒为单位的媒体长度
a=maxptime:<maximum packet time>以毫秒为单位,能够压缩进一个包的媒体量。
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding   parameters>]
a=recvonly
a=sendrecv
a=sendonly
a=inactive,
a=orient:<orientation>其可能的值,"portrait", "landscape" and "seascape" 。
a=type:<conference type>,建议值是,"broadcast", "meeting", "moderated", "test" and "H332"。
a=charset:<character set>
a=sdplang:<language tag>指定会话或者是媒体级别使用的语言
a=framerate:<frame rate>设置最大视频帧速率
a=quality:<quality>值是0-10
a=fmtp:<format> <format specific parameters>

在SIP协议的包含的内容是SDP时,应该把Content-Type设置成application/sdp。

  
0PCMUA8,0001PCMU 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.
 
1reservedA  This payload type was assigned to "1016" in RFC1890 but was removed because two interoperable implementations were not found.
 
2reservedA  This payload type was assigned to "G721" in RFC1890 but its use is now deprecated.
 
3GSMA8,0001GSM (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.
 
4G723A8,0001G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s".
 
5DVI4A8,0001DVI4 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.
 
6DVI4A16,0001 
 
7LPCA8,0001LPC 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.
 
8PCMAA8,0001PCMU 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.
 
9G722A8,0001G722 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.
 
10L16A44,1002L16 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).
 
11L16A44,1001 
 
12QCELPA8,0001The 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.
 
13CNA8,0001The 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.
 
14MPAA90,0001MPA 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.
 
15G728A8,0001G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction".
 
16DVI4A11,0251DVI4 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.
 
17DVI4A22,0501 
 
18G729A8,0001G729 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)".
 
19reservedA  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.
 
20unassignedA   
 
21unassignedA   
 
22unassignedA   
 
23unassignedA   
 
24unassignedV   
 
25CelBV90,000 The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The byte stream format is described in RFC 2029.
 
26JPEGV90,000 The encoding is specified in ISO Standards 10918-1 and 10918-2. The RTP payload format is as specified in RFC 2435.
 
27unassignedV   
 
28nvV90,000 The encoding is implemented in the program 'nv', version 4, developed at Xerox PARC by Ron Frederick.
 
29unassignedV   
 
30unassignedV   
 
31H261V90,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.
 
32MPVV90,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.
 
33MP2TAV90,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.
 
34H263V90,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-71unassigned?   
 
72-76reserved   Reserved for RTCP conflict avoidance
 
77-95unassigned?   
 
96-127dynamic?  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.
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SDP(Session Description Protocol)是一种用于描述多媒体会话的协议。它可以用于描述会话参数,如媒体类型、编解码器、传输协议、网络地址等。在 VoIP 和视频会议等实时通信领域中,SDP 被广泛使用。 以下是使用 C 语言解析 SDP 协议的基本步骤: 1. 读取 SDP 协议文本:首先从文件或网络中读取 SDP 协议文本,保存在字符串中。 2. 解析 SDP 协议头部:使用 strtok 函数将文本按行分割,并解析 SDP 协议头部。头部信息包括会话名称、会话描述、会话连接信息等。 3. 解析媒体描述:使用 strtok 函数将文本按行分割,并解析媒体描述信息。媒体描述信息包括媒体类型、传输协议、端口号、编解码器等。 4. 解析媒体格式:使用 strtok 函数将媒体格式描述按空格分割,并解析每个媒体格式。媒体格式包括编码名称、采样率、通道数等。 5. 解析媒体连接信息:使用 strtok 函数将媒体连接信息描述按空格分割,并解析每个连接信息。连接信息包括网络类型、地址类型、连接地址等。 6. 将解析结果保存到数据结构中:将解析出的信息保存到数据结构中,以便后续使用。 7. 释放资源:释放分配的内存空间,关闭文件或网络连接。 需要注意的是,SDP 协议的解析涉及到字符串处理、正则表达式匹配等操作,需要熟练掌握相关知识。此外,SDP 协议版本不同,解析的方式也可能有所差异。因此,在实际应用中需要根据具体情况进行调整。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值