SDP protocol study notes

Source: Internet
Author: User

SDP: Session Description Protocol

SDP format:
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 already ded 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 already ded
Session-level)
B = * (zero or more bandwidth information lines)
K = * (encryption key)
A = * (zero or more media attribute lines)

The preceding "*" is optional, and the rest is required. The general order is also arranged in the above Order.

A = * is the extension attribute definition of the SDP protocol. Except for the above, all other attributes can be discarded during decomposition.
A = charset attribute specifies the character set used by the Protocol. The general is the ISO-10646.

Example:
V = <username> <sess-ID> <sess-version> <nettype> <addrtype> <unicast-address>
Here, nettype is in, which indicates Internet, and addrtype is ip4 or ip6. The address where the unicast-address task creates a computer.
This attribute uniquely identifies a task.

E = 123@126.comOr P = + 1 616 555-6011
For a single task, only one of the two represents the contact information of the Conference controller. The email address can be in the form of [email] j.doe@example.com [/Email] (Jane Doe), which contains the name that describes the contact, or Jane Doe <[email] j.doe@example.com [/Email]>, with the contact name prefixed.

C = <nettype> <addrtype> <connection-address>
This connection data can be session-level connection data or connection data of a single media data. When multicast is enabled, connection-address should be a multicast group address. When unicast is enabled, connection-address should be a unicast address. When addrtype is ip4, connection-address not only contains the IP address but also a time to live value (TTL 0-255), for example, C = in ip4 224.2.36.42/128, ip6 does not have the TTL value. Connection-address in the format of <base multicast address> [/<TTL>]/<Number of addresses> is also allowed. For example, c = in ip4 224.2.1.1/127/3 is equivalent to three lines containing c = in ip4 224.2.1.1/127, c = in ip4 224.2.1.2/127, and c = in ip4 224.2.1.3/127.

B = <bwtype>: <bandwidth> bwtype can be CT or as. CT is used to set the bandwidth of the entire meeting, and as is used to set the bandwidth of a single session. The default bandwidth is kilobytes per second.
T = <start-time> <stop-time>. This can have rows that specify multiple irregular time periods. If it is a rule time period, the R = attribute can be used. Both start-time and stop-time comply with NTP (Network Time Protocol), in seconds, since 1900. To convert to Unix time, minus 2208988800. If stop-time is set to 0, there is no time limit for the session. If start-time is set to 0, the session is considered permanent.

R = <repeat-interval> <active duration> <offsets from start-time> repeated times can be expressed in the time representation as follows:
D-days (86400 seconds)
H-hours (3600 seconds)
M-minutes (60 seconds)
S-seconds (allowed for completeness)
Z = <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> can be, "audio", "video", "text", "application" and "message ". <Port> is the port number for media transmission. It depends on c = and <proto>. <Proto> It Can Be UDP, RTP/AVP, and RTP/savp.

A = Cat: <Category> category. sessions are isolated based on the specified receiver.
A = keywds: <keywords> keyword, which isolates the corresponding session based on the keyword
A = tool: <name and version of tool> name and version number of the tool used to create the task description
A = ptime: <packet time> the media length in milliseconds in a package
A = maxptime: <Maximum packet time> the volume of media that can be compressed into a package in milliseconds.
A = rtpmap: <payload type> <encoding name>/<clock rate> [/<encoding parameters>]
A = recvonly
A = sendrecv
A = sendonly
A = inactive,
A = Orient: <orientation> its possible values: "portrait", "Landscape" and "seascape ".
A = type: <Conference type>. The recommended value is "broadcast", "meeting", "moderated", "test" and "h332 ".
A = charset: <Character Set>
A = sdplang: <language tag> specifies the language used at the session or media level.
A = framerate: <frame rate> sets the maximum video frame rate.
A = Quality: <quality> the value is 0-10.
A = fmtp: <format> <format specific parameters>

When the content of the SIP protocol is SDP, set Content-Type to 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 powerpath/LTP (residual pulse excitation/long term prediction) coding. blocks of 160 audio samples are compressed into 33 ETS, for an aggressive 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,199 2. 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,000Hz, the RTP clock rate for the g722 payload format is 8,000Hz 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 Industrial Association (EIA) & Telecommunications Industrial 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,000Hz, 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 shoshould 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.
 

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.