Short but not exhaustive list of supported features:
| Call between Google Chrome and iPad device |
| Call between Google Chrome and Android device |
Many other features are supported by the underlying framework but not exposed to the user interface (in progress). For more information please refer to doubango website.
These features include: IPv6, OMA Large IM Message (MSRP), File Transfer (MSRP), Image Sharing (IR.79), Video Sharing (IR.74), TLS and IPSec Security Agreement (RFC 3329), Proxy-CSCF discovery using DHCPv4/v6, TURN, ...
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 |
|
|
| 2- Bodiless INVITE (without 100rel extension) [[Bob ==> Alice]] | ACK | 2xx INVITE | 3261 |
|
|
| 3- Provisional response [[Alice ==> Bob]] | INVITE | 1xx-rel INVITE | 3262 |
|
|
| 4- Bodiless INVITE (with 100rel extension) [[Bob ==> ALice]] | PRACK
| 1xx-rel INVITE | 3262 |
|
|
| 5- Two rounds [[Alice ==> Bob]] | PRACK | 200 PRACK | 3262 |
|
|
| 6 – UPDATE [[Alice ==> Bob]] | UPDATE | 2xx UPDATE | 3311 |
|
|
== SDP offer can be in:
Any reliable non-failure response (1xx-rel or 2xx),
== 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):
