Session Description Protocol (SDP: Session Description Protocol)

The Session Description Protocol (SDP) provides multimedia session descriptions for session notifications, session invitations, and other forms of multimedia session initialization.

 

The session directory is used to assist with multimedia conference announcements and send relevant settings for session participants. SDP is used to transmit this information to the receiving end. SDP is completely a session description format-it is not a Transport Protocol-it only uses different appropriate transport protocols, including session notification protocols (SAP) session Initiation Protocol (SIP), real-time stream protocol (RTSP), mime extended protocol email, and Hypertext Transfer Protocol (HTTP ).

 

SDP is designed to be universal. It can be applied to a wide range of network environments and applications, not just multicast session directories, but SDP does not support negotiation of session content or media encoding.

 

In the Internet multicast Backbone Network (mbone), the Session Directory tool is used to notify multimedia meetings and send the meeting address and the meeting-specific tool information required by the participants, which is completed by SDP. After the session is connected, the SDP sends enough information to the session participant. Session notification protocol (SAP) is used to send SDP messages, which periodically multicast notification packets to known multicast addresses and ports. This information is a UDP packet, which contains the sap protocol header and text payload ). Here, the text payload refers to the SDP Session Description. The external information can also be sent by email or WWW (World Wide Web.

 

SDP text information includes:

 

• Session name and intent
• Session duration
• Media that constitutes a session
• Information about the Receiving media (addresses, etc)

SDP information is text information, using the ISO 10646 character set in UTF-8 encoding. The SDP session is described as follows: (optional fields marked with the * symbol ):

 

1. Session Description:

 

V = (Protocol Version)
O = (owner/creator and session identifier)
S = (Session name)
I = * (session information)
U = * (URI description)
E = * (email address)
P = * (phone number)
C = * (connection information-this field is not required if it is included in all media)
B = * (bandwidth information)
One or more time descriptions (as shown below)

 

Z = * (Time Zone adjustment)
K = * (encryption key)
A = * (0 or multiple session attribute rows)
0 or more media descriptions (as shown below)

 

2. Time description

 

T = (Session Activity time)
R = * (0 or repeated times)
3. Media description

 

M = (media name and transfer address)
I = * (media title)
C = * (connection information-this field is optional if it is included in the Session Layer)
B = * (bandwidth information)
K = * (encryption key)
A = * (0 or multiple media attribute rows)

 

Example:

 

V = 0
O = mhandley 2890844526 2890842807 in ip4 126.16.64.4
S = SDP Seminar
I = a Seminar on the Session Description Protocol
U = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
E = mjh@isi.edu (Mark Handley)
C = in ip4 224.2.17.12/127
T = 2873397496 2873404696
A = recvonly
M = audio49170 RTP/AVP 0
M = video 51372 RTP/AVP 31
M = Application 32416 UDP WB
A = Orient: Portrait

 

Protocol version

 

V = 0
"V =" Domain indication Protocol version

 

Origin

 

O = <username> <session ID> <version> <network type> <address type>

 

<Address>

 

"O =" Domain indicates the session Origin

 

<Username> indicates the user ID used to log on to the host where the session originated. If the host where the session originated has no user ID, use. The User ID cannot contain spaces.

 

<Session ID> is a numerical string, <username>, <session ID>, <network type>, <address type>, and <address> are globally unique in a session. The <session ID> allocation method depends on the creation tool. However, we recommend that you use the Network Time Protocol (NTP) timestamp to ensure its uniqueness.

 

<Version> is the version number of the announcement (Announcement. Proxy announcements needs to be used to detect which declarations are recent in the same session. In addition, it depends on the creation tool. You need to add <version> to modify the data of each session. It is recommended (not mandatory) to use the NTP timestamp.

 

<Network type> is a string that describes the network type. "In" indicates "Internet ".

 

<Address type> is a string that describes the address type. Currently, "ip4" and "ip6" are defined ".

 

<Address> is the unique global address of the machine that creates the session. For the ip4 type, it is the IP address separated by the machine name or node number. If you leave the LAN, do not use a local IP address, because this IP address is meaningless.

 

Generally, the "O =" domain is used as the unique representation of a version Session Description. Except for the version subdomain, other subdomains do not change.

 

Session name

 

S = <session Name>

 

"S =" Domain indicates the session name. Each session has only one "s =" domain. ISO 10646 character set.

 

Session and media information

 

I = <Session Description>

 

"I =" Domain indicates session-related information. The Session Description layer can have at most one "I =" domain, and each media can have at most one "I =" domain. The "I =" domain is not mandatory and can be omitted. In Media definition, the "I =" domain is used to identify a media stream. It is very useful for a media type that has multiple media streams. For example, there are two whiteboards, one for display of slides and the other for communication.

 

Uri

 

U = <URI>

 

A URI is the unique resource identifier (Universal Resource Identifier) of a WWW resource. a uri should be an additional information indicator of a meeting. This field is optional, but if it is specified, it should appear before the first media domain; each session description cannot have more than one URI domain.

 

Email address and phone number

 

E = <email address>
P = <phone number>

 

Connect data

 

C = <network type> <address type> <connection address>

 

The "C =" domain contains connection data.

 

Each media session must have a "c =" domain or a "c =" domain at the session level. The "C =" Domain optimization of the media layer is prior to the session layer.

 

The first subdomain indicates the network type and "in" identifies "Internet ".

 

The second subdomain indicates the address type, for example, ip4.

 

The third subdomain indicates the connection address. Different <address type> domain extensions may have different subdomains.

 

For the ip4 address type, the connection address is defined as follows:

 

A typical connection address is a Class d ip multicast address. If this session is not multicast, the connection address is a machine name or a unique IP Unicast address, data sources, data forwarding, and data targets are defined in other attribute domains. Although the use of the machine name or Unicast address in a declared multicast session is not prohibited, the results are unpredictable. If a unicast address uses NAT (network address translator), we recommend that you use a full-meaning machine domain name, instead of a Multi-Homed Host) IP addresses are recommended when a special network interface is used. Therefore, this specification does not set forth how to use it. It is entirely determined by the application, but the application must be able to handle these situations.

 

In addition to the address, a time to live (TTL) is also required for the Conference to use multicast addresses )). TTL and address 1 determine which multicast packets should be sent. The TTL value ranges from 0 to 255.

 

TTL is appended to the address using a diagonal line delimiter, for example:

 

C = in ip4 224.2.1.1/127

 

<Base multicast address>/<TTL>/<Number of addresses>

 

C = in ip4 224.2.1.1/127/3

 

Indicates:

 

C = in ip4 224.2.1.1/127
C = in ip4 224.2.1.2/127
C = in ip4 224.2.1.3/127

 

Media announcement

 

M = <media> <port> <transport> <FMT list>

 

A session description can contain multiple media descriptions. Each media description starts with a "m =" domain and ends with the next "m =" domain or session description. A media description domain has the following subdomains:

 

• The first subdomain is a media type domain. Although this subdomain may be extended, there are currently mainly "audio", "video", "application", "data", and "control ".
• The second subdomain is the sending port of the media stream.
  Note: For UDP, the port range should be (1024-65535), and the compatibility with RTP should be an even number.

If the media type is applications, it is possible that its multi-layer (hierarchically) encoded media stream needs multiple ports to be sent to a unicast address, as shown below:

 

M = <media> <port>/<number of ports> <transport> <FMT list>

 

In this case, only the even number of RTP ports is used for the port dependency and protocol, and the port larger than this port is used by RTCP. For example:

 

M = video 49170/2 RTP/AVP 31

 

Port 49170 and 49171 are one RTP/RTCP pair, and port 49172 and 49173 are another RTP/RTCP pair. RTP/AVP is the transmission protocol, and 31 is the media format.

 

• The third subdomain is the media protocol. Currently, there are mainly "RTP/AVP" and "UDP ".
• The fourth subdomain is the media format. For audio and video, it is usually a media load type.

For more information about SDP, see RFC 2327 defined by IETF (www.ietf.org.