Introduction to SDP
SDP was originally conceived as a way to describe multicast sessions carried on the Mbone. The Session announcement protocol (SAP) was devices as a mechanism to carry the SDP messages. Although the SDP specification allows for unicast operation, it is not complete. Unlike multicast, where there is a global view of the session that is used by all the participants, unicast sessions require information from both participants, and agreement on parameters between them.
As an example, a multicast session requires conveying a single multicast address for a particular media stream. However, for a unicast session, two addresses are needed- one for each participant As another example, multicast session requires and indication of which codecs will be used in the session. However, for unicast the set of codecs needs to be determined by finding an overlap in the set supported by each participant.
As a result even though the SDP has the expressiveness to describe unicast sessions, it is missing the semantics and operational details of how it is actually done. This is remedied by defining offer/answer model based on SDP. In this model, one participant in the session generates an SDP that constitutes the offer - the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offered would like to use to receive the media. The offer is conveyed to the other participant called answerer. The answerer generates the SDP answer.
Using the offer answer, it is also possible to update the session after the initial offer/answer is done.
Protocol Operation
The offer answer exchange assumes existence of a high level protocol such as SIP which is capable of exchange the SDP for establishment of sessions.
The agent receiving the offer may reject the offer, for which a higher level protocol is required. Some of the rules that may be imposed are
At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which is not yet accepted or rejected. Further more, it should not generate an offer if another one it has generated is not yet accepted or rejected. If an agent receives an offer after it has sent an offer for which no answer has been recived, it should be treated as a glare condition.
The term glare was originally used in circuit switched telecommunications networks to describe the condition where two switches both attempts to seize the same available circuit on the same trunk at the same time. Here it means both agents have attempted to send an updated offer at the same time. The higher level protocols must provide facility to overcome such situations.
Generating Initial Offer
The offer must be a valid SDP message as defined by the RFC 2327 with one exemption that e or p line is not mandatory. The numeric value of session id must be and version in the o line field MUST be represented with a 64 bit signed integer. The initial value must be less than (2**62) - 1.Even though SDP specification allows multiple SDP messages to be concatenated into one large message, the offer answer model restricts that and mandates that to be only ONE.
The SDP "s=" conveys subject of the session, which is reasonably defined for multi cast, but ill defined for unicast. For unicast sessions, It is recommended that it contains a single space character or - (dash)
The "t=" specifies the time of the session. Generally for unicast streams for unicast sessions are created and destroyed through external signalling means such as SIP. In that case "t=" line should have a value of "0 0".
The offer will contain 0 or more media streams and each media stream is described by an "m=" line and its associated attributes. Zero or media stream indicates that offerer wishes to communicate, but the stream for the session will be added at a later point of time through a modified offer.
The stream MAY be for a mix of unicast and multicast; the latter obviously implies a multicast address in the relevant "c=" line(s).
Construction of each offered stream depends on whether the stream is unicast or multicast.
Offer Answer Model
Unicast Streams
If the offerer wishes to only receive media from its peer, it MUST mark the stream as receiveonly. Similarly if the offerer wishes to only send the media, then mark the a attribute as send only by using a=sendonly . This is commonly known as direction attribute. IF the offerer wishes to communicate, but wishes to neither send or receive at this point, then the stream should be marked as a=inactive. Note that if the offer answer is for RTP, the RTCP should be always sent and received irrespective of the direction attribute, i.e. whether it is sendonly, recevonly or inactive. In other words, directionality of the stream has no impact on RTCP usage.
For sendonly and recvonly streams, the port number in the and address in the offer indicate where the offerer would like to receive the media stream. For send only RTP streams, the address and port number indirectly indicates where the offerer want to receive the RTCP reports. Unless indicated explicitly, the RTCP reports are sent to the port number one higher than indicated in the SDP. The IP address and port number present in the offer indicate nothing about the source IP address and port number of RTP and RTCP packets that will be sent by the offerer. A port number zero indicates the stream is offered but must not be used. The answer with zero port number can indicate a rejected stream. Further more, existing streams can be terminated by setting the port to zero. In general port number zero indicates that the stream is not wanted.
The list of media formats for each stream conveys two pieces of information, namely the set of formats that the offer is capable of sending and / or receiving. The format can mention the codec and any parameter for the codec such as in case of RTP. In case of RTP, RTP payload type numbers indicate the payload format. For sendrecv streams, the the offer should indicate the codecs that the offerer is willing to send and receive with. For sendrecv and send only streams, the answerer may send back the response with the payload type different from the one in the offer. In this case, the offerer should send the RTP with the payload type that the answerer responded with.
as per RFC 2327, fmtp parameters may be present to provide additional parameters of the media format. In case of RTP streams, all media descriptions SHOULD contains a=rtpmap mappings from RTP payload types to encodings. If there is no a=rtpmap, then the default payload mapping as defined by RFC 1890 should be used. The new RFC was introduced to move away from the static payload mapping.
In all the cases, the m line must be listed in the order of preferences, with the first format being the most preferred.
If the ptime attribute is present in the offer for a stream, it indicates that desired packetization interval that the offerer would like to receive. A value of zero is allowed but discouraged. It indicates that no RTP should be sent, and this would cause the RTCP also to be stopped.
If multiple media streams of different types are present, it means that the offerer wishes to use those streams at the same time. A typical case is audio and video stream present in the video conference.
If multiple media streams of same type are present in the offer, it means that the offerer wishes to send (and/or) receive multiple streams of that type at the same time. When sending multiple streams of same type, it is matter of local policy as to how each media source of that type (for e.g. a video camera and VCR in the case of video) is mapped to each stream.
A typical usage example of multiple media streams of same type is a pre-paid calling card application. where the user can press and hold the pound key at any time during the call to hung up and make a new call on the same card. This requires media from user to two destinations - the remote gateway, and the DTMF processing application which looks for the pound. This could be accomplished by two media streams, one is sendrecv to the gateway, and the other sendonly to the DTMF application.
Multicast streams:
IF session description contains a multicast media stream which is listed as receive only, it means that the participants, including the offerer and the answerer, can only receive the media on that stream. This differs from the unicast view where the directionality refers to the flow of media between the offerer and answerer.
No comments:
Post a Comment