The primary purpose of an SDP body is to always ensure that the participants are provided sufficient information to join a communication session. ■ Value attributes: These attributes are in the format a=. A property attribute conveys a simple Boolean meaning for media or the session. ■ Property attributes: These attributes are in the format a=. (At the time of this writing, there are a few new SDP attributes in the process of being standardized by the IETF.) Attributes can be of two types: Over time, to enable several application use cases and to enable smooth interoperability between communicating entities, many SDP attributes were defined and standardized. The format of each field is as follows: =Īttributes are the primary means of extending SDP. A field is separated from the next one by a carriage return/line feed (CRLF) sequence. SDP bodies contain a number of textual lines that are each either classified as fields or as attributes. The formatting of SDP bodies is mostly in UTF-8. This choice was made deliberately so that SDP could be leveraged by several protocols and to ensure that malformed SDP bodies could be easily identified and discarded. Unlike H.323, it does not use binary encoding, such as ASN.1. SDP is completely textual and rigid in terms of formatting. SDP is strictly a description protocol and it is leveraged by higher-level protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), Real Time Streaming Protocol (RTSP), Multipurpose Internet Mail Extensions (MIME), and Hypertext Transfer Protocol (HTTP). Session Description Protocol (SDP), originally defined in RFC 2327 (and later updated in RFC 4566), was designed to provide session details (such as the media types, media codec, and IP/port pair for media) and session metadata (such as the purpose of the session and the originator of the session) to participants. As a result, SIP relies on a peer protocol to facilitate advertisement and negotiation of media capabilities. However, it does not provide participants any information about the details of the communication session (for example, the media types supported and the IP/port pair for media).
SIP, as a call control protocol, is adept at setting up and tearing down communication sessions. Protocols were needed to set up, modify, and tear down communication sessions, and these protocols needed to provide enough information to allow participation within the communication session. While this process was acceptable for the occasional calls made over packet networks for the purpose of research and demonstration, it clearly would not find acceptance if Internet telephony were to scale. The callee would fire up a local audio or video application and inform the caller of the IP address and port number on their end. The caller would inform the callee of the details of the port number and IP address over a PSTN line. The caller would bootstrap an audio or video application at a specific port number and IP address. To set up a communication session in the early days, participants had to do the following: In the earlier days of Internet telephony, the process of setting up a call was very cumbersome and drawn out-very unlike the seamless call setup we experience today.