SDP was originally conceived to describe multicast sessions on the MBone. In those scenarios, the SDP session descriptor was distributed among the potential participants using the Session Announcement Protocol [RFC 2974]. The SDP included, among other things, information about the multicast address for the media and the set of codecs used in the session.

SDP is used in many scenarios, including streaming, IP communications, and others. In order to apply SDP to IP communication scenarios, it is necessary to extend its semantics. For example, in a multicast conference, it is necessary only to convey a single multicast address for a particular media stream, whereas, in the case of a two-party communication, two unicast addresses are needed.

Moreover, there is also the need to define the operational details of how to use SDP in communication scenarios. In the case of multicast conferences, the codecs to be used for the session are simply indicated in the SDP sent to the participants, whereas, in the case of IP communications, the parties need to agree on the set of codecs to use; therefore, some negotiation needs to occur.

In the next sections, we will see the SDP syntax and semantics that are applicable to IP communication services, as well as a limited negotiation framework defined by [RFC 3264].

SDP is specified in [RFC 4566]. As has already been mentioned, SDP does not define a true protocol, but rather, a language for representing the key parameters that characterize a multimedia session.

SDP is text based. An SDP message consists of a set of lines of text of the form:

where <type> is a single character, and <value> is a structured text whose format depends on <type>. An example of SDP message is shown next.

An SDP message contains three levels of information:

Tables 9.1, 9.2, and 9.3, taken from [RFC 4566], show the different types of lines for each level, indicating whether the field is required (R) or optional (O).

Next we will focus on those lines that are mandatory or of relevance for realtime communication services. We will explain the meaning of the different parameters in the remit of this kind of services.

The “v=” line gives the version of the Session Description Protocol.

It is set to 0 for the current version of the spec [RFC 4566].

Example:

The “o =” line identifies the originator of the session, and contains the following parameters:

An example would be:

The “s =” line conveys the subject of the session. This makes sense for multicast uses of SDP. In the case of unicast (as is the case in IP communication services), a session has no meaningful name, so the s-line will be set to just a blank space “s =.”

Example:

The “c =” line contains information about the connection address. That is the address at which the SDP sender expects to receive the incoming media packets.

Example:

where IN indicates that the following address is an Internet address, and IP4 indicates the version of the IP protocol.

The c-line can be present at session level—that is, valid for all the sessions—or be present in the m-line, implying it is valid for a particular media, in which case it overrides the session-level value.

The “t=” line conveys the time of the session. This is again meaningful for multicast sessions where the potential receivers need to know beforehand when the session will start, following very much a similar approach to what occurs in TV broadcasting. In the case of unicast sessions, it is set to “0 0.”

Example:

The “m=” line includes information about a particular media.

A session description may contain several m-lines, implying the session may contain several media. Each m-line indicates:

The interpretation of the media format depends on the actual media transport protocol. When RTP/AVP is used, the media format represents the RTP payload type number (see Chapter 10). The RTP payload number can be static or dynamic. If it is static, there exists a well-known id number associated to it, so there is no need to include further information about the payload type in the SDP. However, if it is dynamic, there is no fixed association, so the next line in the SDP should include more information that characterizes the format.

Dynamic payload types are assigned numbers between 96 and 127.

Next follows an example of an m-line with a static payload type (0), which indicates a PCM μ -law^[2] encoding for audio.

The next example shows an m-line with a dynamic type (96).

Note that in this last case, there is an additional a-line, which is used to describe the type of encoding (L8) and the clock rate dynamically assigned to payload type 96.

The optional “b=” line denotes the proposed bandwidth to be used by the session or media.

A b-line contains two elements:

The values of the modifier more frequently used in IP communications are:

The use of the modifier values RS and RR is not defined in the base SDP specification [RFC 4566], but on [RFC 3556].

The following SDP session description offers an audio communication, and requests a total bandwidth of 64 kilobits per second. For RTCP senders, the requested bandwidth is 800 bps; for RTCP receivers, it is 2400 bps.

Attributes are the primary means for extending SDP. They may be defined to be used as “session-level” attributes, “media-level” attributes, or both.

Some important attributes in the case of IP communication services are:

Next follow some examples of SDP session descriptions for different types of media.

This corresponds to the most classical use of SDP to describe a session composed of “pure” real-time media components such as audio and video transported over RTP. We can see that the SDP message indicates that the RTP audio/video profile should be used (see Chapter 10 for the definition of the audio/video profile). It also includes a media line for audio with PCM codec (payload type = 0), and a media line for video with the H.261 codec (payload type = 31).

In PSTN (Public Switched Telephony Network) scenarios, it is common to use telephony tones. An example of this is the so-called DTMF (Dual-Tone Multi-Frequency) tones, which are standard signals that are generated by pressing a ordinary telephone’s touch keys. These are typically used in scenarios involving interactive voice response (IVR) machines that prompt the user to introduce some information (e.g., “If you want information in English, press 1; if you want information in Spanish, press 2”).

Multimedia applications in the Internet may need to send or receive these types of signals, especially in (but not limited to) scenarios that involve interworking with the PSTN.^[3] DTMF and telephony tones are considered a particular type of audio media carried over RTP that is separately described using SDP. By using SDP, endpoints in an Internet multimedia communication can signal whether they support or not the generation of telephony tones in case those need to be generated during the conversation.

Next follows an example of SDP that offers support for DTMF (only the relevant lines are shown).

Transport of telephony tones over RTP is described in [RFC 4733] and [RFC 4734].

“Real-time text over IP” sessions can be conveyed using RTP with a specific payload type. An example of SDP for a text session might be:

As we can see, the dynamic payload type 98 is mapped to the T.140 protocol, which is used for describing the content of a text session (see Chapter 10).

Another type of media that can be described by SDP is the exchange of related instant messages between two parties. Such an exchange is also considered to be a media session. This scenario is called session-based instant messaging, and the media transport protocol in this case is the Message Session Relay Protocol (MSRP). At the time of writing, there is not yet an RFC for MSRP. It is specified in an Internet draft [draft-ietf-simple-message-sessions]. Therefore, it is considered work in progress. The status of the draft is quite advanced, and it is expected that very soon it will become a standards track RFC.

In order to describe an MSRP session using SDP, two new mandatory media-level attributes are defined:

In addition to these new attributes, the connection and media line in an SDP message describing an MSRP session have the following requirements:

The media described by SDP can also represent media that is conveyed as a data stream using the TCP protocol between two communicating parties. The protocol identifier in this case has the value “TCP.” It indicates just the transport protocol, so the m-line must further qualify the application-layer protocol using a format identifier. Furthermore, two new attributes must be defined to describe how and when the TCP connection setup procedure is performed:

In the following example, we can see an example of SDP for this type of session. In this case, the media type is “image.” The transport protocol is TCP, and the format indicates a T.38 fax application. The setup attribute is active, so the sender is willing to initiate the TCP connection and the connection attribute is new, which means that a new TCP connection needs to be established.

The SDP usage to describe TCP media transport is defined in [RFC 4145].

Let us assume that John wants to set up a communication with Alice that includes a bidirectional audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32). Therefore, his SDP offer will look like:

Alice does not want to receive or send the first video stream, so she returns the SDP below as the answer:

We can notice that in the answer, the port for the first media stream is set to 0, indicating that Alice does not want to communicate using that particular media. Alice, on the other hand, accepts both the audio and the second video stream, so the communication will start including these two media.

As we can seen from this example, in the case of media types that are conveyed using RTP, the offer/answer model enables the negotiation of the type of codecs.

Let us consider now that John wants to set up an instant messaging session with Alice. John intends to send messages containing text, and also he wants to send an image. This means that he will offer two media types to Alice:

John also includes his MSRP address in the path attribute. His SDP offer would be:

Alice does not support the jpeg format, so she answers with the following SDP, in which she also includes her MSRP address in the path attribute:

At this point, John would set up a TCP connection to the address and port specified by the MSRP URI sent by Alice—that is, host.ocean.com:8651. Once the TCP connection is established, the exchange of just text messages might start.

When using TCP-based transport, it is possible to negotiate how and when the connection setup procedure is performed based on the exchanged values of the “connection” and “setup” attributes.

For instance, the offerer might set setup attribute to passive, and, if the answerer responds with active, it means that the answerer will be the one responsible for initiating the TCP connection. This scenario is seen in the following exchange of SDP messages between John and Alice for a T.38 fax session:

JAIN SDP is a very simple API that just allows us to encode and decode SDP content. Like the JAIN SIP API, it is also based on the factory pattern. It defines a factory class called SdpFactory, and a number of interfaces that represent the key concepts in SDP. By invoking creation methods on SdpFactory, the programmer can obtain objects that implement those key interfaces in the API.

As already stated, JAIN SDP provides a number of interface classes that represent the key concepts in the Session Description Protocol. These interfaces fall into two categories. On one hand, there is the SessionDescription interface, which models the SDP message itself; on the other, there are a myriad of interfaces, each of them representing one or more lines in the SDP message.

Table 9.4 shows some of the main interfaces in the API and their mapping to the SDP concepts that they represent. Table 9.5 shows the methods needed to create them from the SdpFactory.

It is worth noting that in order to create a MediaDescription, we need to pass a vector of integer values for the media formats to the createMediaDescription() method so as to reflect the fact that more than one media format may be included in the same m-line.

So far, we have seen how to create SessionDescription objects as well as objects representing the different lines in an SDP message. We will now see how to actually encode and parse SDP messages.

To encode an SDP message, the following steps need to be followed:

There are setter methods for all the lines in an SDP message. Table 9.6 shows the main ones.

After these steps have been completed, we have SessionDescription object representing our SDP message. In order to include it into a SIP message, we would need to convert it into a String and pass it as an argument of the JAIN SIP setContent() method.

An important aspect to highlight is that in order to include the m-lines in the message, rather than invoking several times a “setter” method to include a MediaDescription, the JAIN SDP API offers only a setMediaDescriptions() method to which we need to pass a Java vector containing all the MediaDescriptions that we want to add to the message. A similar approach is followed for the Time object.

For instance, if we wanted to add the following lines to an SDP message:

Our code should look like:

int[] mf1=new int[1];
mf1[0]=0;
int[] mf2=new int[1];
mf2[0]=31;
MediaDescription media1 = mySdpFactory.
  createMediaDescription("audio," 3401, 1,
 "RTP/AVP," mf1);
MediaDescription media2 = mySdpFactory.
  createMediaDescription("video," 3550, 1,
  "RTP/AVP," mf2);
Vector myMediaDescriptionVector=new Vector();
myMediaDescriptionVector.add(media1);
myMediaDescriptionVector.add(media2);
mySdp.setMediaDescriptions(myMediaDescriptionVector)

To parse an SDP message, the following steps need to be followed:

There are getter methods for all the lines in an SDP message. Table 9.7 shows the main ones.

In order to put into practice the JAIN SDP concepts learned so far, we will now create a simple component that will ease the task of creating and parsing SDP content. This component will be used by the soft-phone application that we will build in Chapter 12. Such application is built only for training purposes and has a limited scope. With regard to SDP handling in our soft-phone application, we take the following assumptions; some of them will help in keeping the code as simple as possible while still allowing us to show the fundamental concepts:

Under all the previous assumptions, our soft-phone application will need only to include or get five pieces of information in or from the SDP message:

The SDP component that we will build now will simplify the task of setting or getting these pieces of information from an SDP message. The component is a Java class called SdpManager. We will also use another Java class called SdpInfo that is a data structure that holds the value of the five parameters we are interested in.

The SdpInfo class is shown next.

public class SdpInfo {
   String IpAddress="" ;
   int aport=0;
   int aformat=0;
   int vport=0;
   int vformat=0;
   public SdpInfo() {}
   public void setIPAddress(String IP) {IpAddress=IP;}
   public void setAudioPort(int AP) {aport=AP;}
   public void setAudioFormat(int VF) {aformat=AF;}
   public void setVideoPort(int VP) {vport=VP;}
   public void setVideoFormat(int VF) {vformat=VF;}
   public String getIpAddress() {return IpAddress;}
   public int getAudioPort() {return aport;}
   public int getAudioFormat() {return aformat;}
   public int getVideoPort() {return vport;}
   public int getVideoFormat() {return vformat;}
 }

The SdpManager class offers two methods:

The first one receives as input an SdpInfo object, and creates as output a byte array representing the SDP content.

The second one gets an SDP message as a byte array, and produces an SdpInfo object with the key info we are interested in.

The constructor method for SdpManager just obtains the instance of SdpFactory that will be used in the two main methods.

mySdpFactory = SdpFactory.getInstance();

The code for the createSdp () method is shown next. It is quite straightforward.

Version myVersion = mySdpFactory.createVersion(0);
long ss=mySdpFactory.getNtpTime(new Date());
Origin myOrigin = mySdpFactory.createOrigin("-
   ",ss,ss,"IN","IP4",sdpinfo.getIpAddress());
SessionName mySessionName = mySdpFactory.createSessionName("-");
Connection myConnection=mySdpFactory.createConnection("IN,""IP4,"
   sdpinfo.getIpAddress());
//Time description lines
Time myTime=mySdpFactory.createTime();
Vector myTimeVector=new Vector();
myTimeVector.add(myTime);
//Media description lines
int[] aaf=new int[1];
aaf[0]=sdpinfo.getAudioFormat();
MediaDescription myAudioDescription=mySdpFactory.
  createMediaDescription("audio",
   sdpinfo.getAudioport(), 1, "RTP/AVP",aaf);
Vector myMediaDescriptionVector=new Vector();
myMediaDescriptionVector.add(myAudioDescription);
if (sdpinfo.getVideoPort()!=-1) {
   int[] avf=new int[1];
   avf[0]=sdpinfo.getVideoFormat();
   MediaDescription myVideoDescription =
      mySdpFactory.createMediaDescription("video" sdpinfo.
        getVideoPort(), 1,
      "RTP/AVP",
   avf);
   myMediaDescriptionVector.add(myVideoDescription);
}
SessionDescription mySdp = mySdpFactory.createSessionDescription();
mySdp.setVersion(myVersion);
mySdp.setOrigin(myOrigin);
mySdp.setSessionName(mySessionName);
mySdp.setConnection(myConnection);
mySdp.setTimeDescriptions(myTimeVector);
mySdp.setMediaDescriptions(myMediaDescriptionVector);
mySdpContent=mySdp.toString().getBytes();
return mySdpContent;

It is worth mentioning that we have followed the recommendation in [RFC 4566] to create the session id based on NTP timestamps. The JAIN SDP API offers a convenience method to create NTP timestamps from a Java Date object:

static long getNtpTime(Date d)

The third parameter in the o-line—that is, the version of the session information—has been initialized to the same value as the session id.

Next we show the code for the getSdp() method:

String s = new String(content);
SessionDescription recSdp=mySdpFactory.createSessionDescription(s);
String myPeerIp=recSdp.getConnection().getAddress();
String myPeerName=recSdp.getOrigin().getUsername();
Vector recMediaDescriptionVector=recSdp.
  getMediaDescriptions(false);
//We assume first media line is audio
MediaDescription myAudioDescription = (MediaDescription)
recMediaDescriptionVector.elementAt(0);
Media myAudio = myAudioDescription.getMedia();
int myAudioPort = myAudio.getMediaPort();
Vector audioFormats=myAudio.getMediaFormats(false);
Integer myAudioMediaFormat=(Integer) audioFormats.elementAt(0);
int myVideoPort =-1;
Integer myVideoMediaFormat = new Integer(-1);
//We assume second media line, if it exists, is video
if (recMediaDescriptionVector.capacity()>1) {
   MediaDescription myVideoDescription =
      (MediaDescription) recMediaDescriptionVector.elementAt(1);
   Media myVideo = myVideoDescription.getMedia();
   myVideoPort = myVideo.getMediaPort();
   Vector videoFormats = myVideo.getMediaFormats(false);
   myVideoMediaFormat = (Integer) videoFormats.elementAt(0);
}
mySdpInfo=new SdpInfo();
mySdpInfo.setIpAddress(myPeerIp);
mySdpInfo.setAudioPort(myAudioPort);
mySdpInfo.setAudioFormat(myAudioMediaFormat.intValue());
mySdpInfo.setVideoPort(myVideoPort);
mySdpInfo.setVideoFormat(myVideoMediaFormat.intValue());
return mySdpInfo;

It is worth highlighting that the port and the media format parameters are obtained through a Media object, not directly through the MediaDescription object. So, in order to get these parameters, we had to: