SDP
SDP, short for Session Description Protocol, is a simple protocol that allows clients to share information about a multimedia stream to clients wishing to connect. Further extensions on the protocol also allow clients to share their multimedia abilities with other devices. As its name denotes, it is used primarily to describe a client’s session abilities. It plays an integral part in VoIP communications to share the fact that a communication session is taking place, and to provide information to other clients so that they have the ability to join and interact with the session, such as with a group teleconference.
SDP was first described in RFC 2327 in April 1998, and the original RFC still defines the protocol’s basic abilities today. There are updates, though, to the RFC, such as RFC 3266, which adds IPv6 support to SDP. Other associated RFCs include the RTCP attribute in SDP (RFC 3605), TCP-Based Media Transport in SDP (RFC 4145) and PSTN/Internet Interworking (PINT), a set of extensions to SIP and SDP for IP Access to Telephone Call Services (RFC 2848). A fairly recent RFC, RFC 3407, allowed the clients the ability to share their multimedia abilities to other devices.
SDP Specifications
SDP is used as a specification protocol, not as an actual transport protocol (or even a session negotiation protocol, although higher-level protocols like SIP may add that capability above it). In other words, SDP does not actually transfer data between clients, it just establishes a structure for communicating the attributes for those data streams. The data must be transferred using another transport protocol, such as SAP, SIP, RTSP, or HTTP. The information contained within an SDP packet is in ASCII text, and although it was not designed for human readability, it is easy to decipher. An SDP packet is broken into multiple lines of text, where each line represents a single field and its corresponding value. Common data fields include
- v (Protocol Version)
- s (Session name)
- i (Session description)
- u (URI of subject material)
- e (E-mail address of Session Point of Contact)
- p (Phone number of Session Point of Contact)
- c (Connection information: IP version and CIDR IP address)
- e (Encryption key as clear text, base64, uri, or prompt)
- m (Media type, connection port, transport method, and format list)
- t (Session begin and end times)
- a (Attribute)
The following is an example of SDP data for supplying capabilities:
v=0 o=bsmith 2208988800 2208988800 IN IP4 68.33.152.147 s=- e=bsmith@foo.com c=IN IP4 20.1.25.50 t=0 0 a=recvonly m=audio 0 RTP/AVP 0 1 101 a=rtpmap:0 PCMU/8000 a=rtpmap:1 GSM/8000 a=rtpmap:101 telephone-event/8000
SDP Operation
Once a device has been queried, usually by a client sending an SIP request, it forms an SDP packet to send back. This SDP packet supplies all of the critical information about the session capabilities that the device offers. In its simplest form, this data contains the owner information, the audio and video codecs supported, and which ports connections are accepted on. In queries for particular sessions, the reply contains the session name, the session description, connection ports, and the range of time when the session will be active. All time stamps in SDP data are formed using Network Time Protocol (NTP) values. Additionally, the session ID and session version, which must be unique values, are generally created using NTP values to signify the current date and time.
Much of the current SDP usage is documented in RFC 4317, which describes the SDP Offer/Answer model. In this model, when a client wishes to communicate with another, ittransmits an SDP offer packet. This packet is arranged in a structure similar to the following example, provided by RFC 4317:
v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000
Reading through this packet, you can see that the owner line describes that the packet sender is “alice” who is listening for connections on host.atlanta.example.com. his data is sent to the person with whom she wishes to communicate. Once the other person has received the data and wishes to continue the connection, an answer packet is returned. Here is an example of this answer:
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49174 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49170 RTP/AVP 32 a=rtpmap:32 MPV/90000
In this example, Alice is initiating a connection with Bob. Alice’s Offer packet identifies that she supports three types of audio connections (PCMU, PCMIA, and iLBC), as well as two types of video connections (H.261 and MPV). Once Bob’s client has received the invitation and parsed the values, it chooses a compatible audio and video format and responds back.
Security Implications for SDP
Similar to the security issues of RSVP, much of the security implications for SDP arise due to the fact that a person can easily read session IDs and connection information off of a network segment and then tamper with existing communications. In seeing existing connection offers, and their corresponding SDP replies, an eavesdropper could use the information to determine devices that are allowing VoIP communications, and also spoof his way into an existing communication. An attacker may also be able to collect SDP offers and replay them at a later time, overriding values for ongoing communications, with the potential to disable audio feeds. However, nearly all security issues with SDP can be solved by using protocols to handle user authentication, such as SIP.
1 comment:
thank you for the post , visit us for
best telephone solution for business
Post a Comment