SDP Offer/Answer (SOA)

SDP stands for Session Description Protocol and has been specified by the IETF in RFC 4566. It was previously defined in RFC 2327, which is now obsolete.

In order to understand this post, the reader MUST have a basic knowledge of how SIP (Session Initiation Protocol) works and how sessions are setted up and teared down.

The goal of this post is to explain (Highlights) how to implement a robust SOA (SDP Offer/Answer) machine. This can apply to both basic SIP equipment and 3GPP NGN/IMS nodes with MMTel extensions.

Related RFCs (Highlights): 3261, 3262 (100rel; PRACK), 3264 (Offer/Answer model), 3311 (UPDATE), 3312 (Preconditions/QoS), 3960 (Early Media and Ringing Tone Generation) and draft-ietf-sipping-sip-offeranswer-12.

	Alice	Bob
	SDP Offer	SDP Answer	RFC	Callflow	Note
1- Basic Call [[Alice ==> Bob]]	INVITE	2xx INVITE	3261	Alice sends the initial offer in the INVITE (or reINVITE if session is already established) Bob's answer is sent in the 2xx INVITE response	If a reINVITE fails, the session parameters in effect prior to the reINVITE MUST remain unchanged To reject the offer, Bob should send a 488 INVITE response with a warning header field indicating the reason. If this was a reINVITE, a failure response should not be sent if media has already been exchanged.
2- Bodiless INVITE (without 100rel extension) [[Bob ==> Alice]]	ACK	2xx INVITE	3261	Alice sends initial INVITE without offer Bob's offer is sent in the 2xx INVITE response Alice's answer is sent in the ACK request	The initial INVITE has no SDP offer As there is no offer in the initial offer, the first reliable non-failure message MUST have an Offer. As we suppose that 100rel extension is not supported then the offer MUST be in the 2xx response. To reject /update the offer, Alice should first send her answer in the ACK response. Once the ACK is sent, Alice can send another offer or hangup the call.
3- Provisional response [[Alice ==> Bob]]	INVITE	1xx-rel INVITE	3262	Alice sends the initial offer in the INVITE Bob's answer is sent in the first reliable provisional response, in this case it's a 1xx response	Both clients MUST support 100rel extension As the first realiable provisional response contains a SDP, and is the first to do so, then that SDP is the answer to the offer and cannot be updated in subsequent reliable responses (200 to 600). If an unreliable response precedes a reliable response it's considered as a "preview" of the answer that will be coming, and hence may be treated like an answer until the actual one arrives. To reject the offer, Bob should send a 488 INVITE response with a warning header field indicating the reason.
4- Bodiless INVITE (with 100rel extension) [[Bob ==> ALice]]	PRACK	1xx-rel INVITE	3262	Alice sends an initial INVITE without offer Bob's answer is sent in the first reliable provisional response, in this case it's a 1xx INVITE response Alice's answer is sent in the PRACK response	Both clients MUST support 100rel extension As there is no offer in the initial INVITE, the first reliable non-failure message MUST have an offer. As we suppose that 100rel extension is supported by both endpoints then the offer MUST be in the first 1xx-rel response. To reject/update the offer, Alice should first send her answer in the PRACK request. Once the 2xx PRACK is received, Alice can send another offer (reINVITE or UPDATE) or hangup the session.
5- Two rounds [[Alice ==> Bob]]	PRACK	200 PRACK	3262	Alice sends an initial INVITE with or without offer (case 3 or 4 respectively) Bob's answer or offer (case 3 or 4 respectively) is sent in the first reliable provisional response As the first provisional response contains a SDP then, Alice can send another offer in the PRACK request Bob sends his second answer in the 200 PRACK	To reject/update the offer, Bob should first send his answer in the 200 PRACK response. Once the PRACK is sent, Bob can send another offer (reINVITE or UPDATE) or hangup the call.
6 – UPDATE [[Alice ==> Bob]]	UPDATE	2xx UPDATE	3311	The initial offer/answer could be made by using any of the above use cases Alice sends an UPDATE request with an offer to update the previous negociated SDP session Bob's answer is included in the 2xx UPDATE	Both clients MUST support UPDATE To reject the offer, Bob should send a 488 UPDATE response with a warning header field indicating the reason.In this case the session parameters in effect prior to the UPDATE MUST remain unchanged and the session is not teared down.

SDP

== SDP offer can be in:

• Any reliable non-failure response (1xx-rel or 2xx),

• INVITE, PRACK and ACK requests. PRACK request contains an offer only if the reliable response which it acknoledges contains an answer to the previous offer/answer exchange (draft-ietf-sipping-sip-offeranswer-12 subclause 2.1)

== In a SDP pmessage, some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given in RFC 4566 subclause 5.

Generating an Answer

== SDP message in the unreliable responses to the INVITE request must be identical to the answer which is included in the reliable response. A session description in an unreliable response that precedes a reliable response can be considered a "preview" of the answer that will be coming, and hence may be treated like an answer until the actual one arrives (draft-ietf-sipping-sip-offeranswer-12 subclause 3.1).

== An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero (RFC 3264 subclause 6).

== For each "m=" line in the offer, there MUST be a corresponding "m=" line in the answer. The answer MUST contain exactly the same number of "m=" lines as the offer. This allows for streams to be matched up based on their order. This implies that if the offer contained zero "m=" lines, the answer MUST contain zero "m=" lines (RFC 3264 subclause 6).

== UAS should send an SDP answer reliably (if possible) before it starts sending media. And, if neither the UAC nor the UAS support 100rel, the UAS should send a preview of the answer before it starts sending media (draft-ietf-sipping-sip-offeranswer-12 subclause 3.1).

== When a UAS has received an initial INVITE without an offer, it must include an offer in the first reliable response to the INVITE (draft-ietf-sipping-sip-offeranswer-12 subclause 5.2.2).

== The answer to an offered session description is based on the offered session description. If the answer is different from the offer in any way (different IP addresses, ports, etc.), the origin line MUST be different in the answer, since the answer is generated by a different entity. In that case, the version number in the "o=" line of the answer is unrelated to the version number in the o line of the offer (RFC 3264 subclause 6).

== The "t=" line in the answer MUST be equal that of the offer. The time of the session cannot be negotiated (RFC 3264 subcaluse 6).

== When a UAC does not include an SDP body in the INVITE request, it expects the offer to be received with the first reliable response.

== The UAC will send the answer in the request to acknowledge the response, i.e. PRACK or ACK request of the reliable response (draft-ietf-sipping-sip-offeranswer-12 subclause 3.1.2)

Modifying the Session

== Both the re-INVITE and UPDATE methods can be used in an established dialog to update the session (draft-ietf-sipping-sip-offeranswer-12 subclause 3.3).

== When both UAs support the 100rel extension, they can UPDATE the session in the early dialog once the first offer/answer exchange has been completed (draft-ietf-sipping-sip-offeranswer-12 subclause 3.2).

== When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. If the previous SDP had N "m=" lines, the new SDP (in the UPDATE or reINVITE) MUST have at least N "m=" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. (RFC 3264 subcaluse 8).

== New media streams are created by new additional media descriptions below the existing ones, or by reusing the "slot" used by an old media stream which had been disabled by setting its port to zero. Reusing its slot means that the new media description replaces the old one, but retains its positioning relative to other media descriptions in the SDP. New media descriptions MUST appear below any existing media sections (RFC 3264 subcaluse 8.1).

== Existing media streams are removed by creating a new SDP with the port number for that stream set to zero. The stream description MAY omit all attributes present previously, and MAY list just a single media format (RFC 3264 subclause 8.2).

== The list of media formats used in the session MAY be changed (RFC 3264 subcaluse 8.3.2).

== The Address, Port or Transport for a stream MAY be changed (RFC 3264 subclause 8.3.1).

== The media type (audio, video, etc.) for a stream MAY be changed (RFC 3264 subclause 8.3.3).

== Any other attributes in a media description MAY be updated in an offer or answer (RFC 3264 subclause 8.3.4).

== If a reINVITE fails, the session parameters in effect prior to the reINVITE MUST remain unchanged, as if no re-INVITE had been issued (draft-ietf-sipping-sip-offeranswer-12 subclause 3.4 which reference RFC 3261 section 14.1).

== 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 it has not yet answered or rejected. It MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection (draft-ietf-sipping-sip-offeranswer-12 subclause 4).

Holding media

== "HOLD" should be indicated in an established session by sending a new offer containing "a=sendonly" for each media stream to be held. An answerer is then to respond with "a=recvonly" to acknowledge that the hold request has been understood (RFC 3264 subclause 5.1). That is, the directionality of the media stream has no impact on the RTCP usage.

If UA2 has previously been "placed on hold" by UA1, via receipt of "a=sendonly", then it may initiate its own hold by sending a new offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will answer with "a=inactive" because that is the only valid answer that reflects its desire not to receive media (draft-ietf-sipping-sip-offeranswer-12 subclause 5.3).

== An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer (RFC 3264 subclause 8.4).

Indicating Capabilities

== An SDP constructed to indicate media capabilities is structured as follows (RFC 3264 subclause 9):

• It MUST be a valid SDP, except that it MAY omit both "e=" and "p=" lines. The "t=" line MUST be equal to "0 0"
• For each media type supported by the agent, there MUST be a corresponding media description of that type
• The session ID in the origin field MUST be unique for each SDP constructed to indicate media capabilities