An Offer/Answer Model with Session Description Protocol (SDP)
Extracted elements (30)
RTP payload type mappings MUST remain fixed for the duration of a session because of loose synchronization between signaling exchanges of SDP and the media stream; changing them mid-session could cause misinterpretation of already-in-flight packets.
Setting the connection address to 0.0.0.0 to indicate hold (from RFC 2543) is no longer recommended because it prevents RTCP use with held streams, does not work with IPv6, and breaks with connection-oriented media.
The offerer SHOULD (not MUST) use the first media format listed in the answer because there is often a need to change codecs on the fly, e.g., switching to a comfort noise codec during silence or to RFC 2833 DTMF, or due to congestion control.
The s= line is RECOMMENDED to be a single space or dash for unicast sessions because it is ill-defined for unicast (conceived for multicast). SDP syntax does not allow the s= line to be empty, so a placeholder is required.
Different RTP payload type numbers may be needed in each direction due to interoperability concerns with H.323; accordingly the offerer MUST send with the payload type numbers indicated in the answer if they differ from those in the offer.
RTCP is still sent and received for sendonly, recvonly, and inactive RTP streams; the directionality of the media stream has no impact on RTCP usage. For sendonly streams, the RTCP port is one higher than the indicated port unless explicitly indicated otherwise.
When both agents attempt to send updated offers simultaneously (glare condition), the higher layer protocol (such as SIP) must provide a mechanism to resolve the conflict; offer/answer itself does not define a glare resolution procedure.
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.
An agent MUST NOT generate a new offer if it has received an offer it has not yet answered or rejected, and MUST NOT generate a new offer if it has sent a prior offer for which it has not yet received an answer.
An offer or answer MUST be a valid SDP message as defined by RFC 2327, with one exception: the e= and p= lines MAY both be omitted. Additionally, an SDP used in offer/answer MUST contain exactly one session description.
Direction attribute constraints are strict: if a stream is offered as sendonly, the answer MUST be recvonly or inactive; if offered as recvonly, the answer MUST be sendonly or inactive; if offered as inactive, it MUST be marked inactive in the answer.
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, allowing streams to be matched by their order.
In the answerer's RTP stream, it MUST use the payload type numbers from the offer, even if they differ from those in the answer, when sending media.
In the case of RTP, the mapping from a dynamic payload type number to a particular codec within a media stream MUST NOT change for the duration of a session, even if formats are added or removed in subsequent offers.
Media formats in the m= line MUST be listed in order of preference, with the first format being most preferred. The recipient of the offer SHOULD use the format with the highest preference that is acceptable to it.
The application signaling protocol carrying offers and answers MUST provide a means for end-to-end authentication and integrity protection of offers and answers, and SHOULD offer encryption of bodies to prevent eavesdropping.
The connection address and port in the answer indicate where the answerer wishes to receive media, and MUST be present even for sendonly streams so RTCP can be received on the port one higher.
The numeric value of the session ID and version in the o= line MUST be representable with a 64-bit signed integer. The initial value of the version MUST be less than (2**62)-1 to avoid rollovers.
To defend against replay attacks, the application protocol MUST provide a secure way to sequence offers and answers and to detect and reject old offers or answers.
To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. The t= line in the answer MUST equal that of the offer; session time cannot be negotiated.
When changing ports, the offerer MUST be prepared to receive media on both old and new ports as soon as the offer is sent, and MUST NOT cease listening on the old port until media arrives on the new port.
When modifying a session, the o= line of the new SDP MUST be identical to the previous SDP except that the version MUST increment by one. If the version does not increment, the SDP MUST be identical to the previous SDP with that version.
A port number of zero in an offer or answer indicates the stream is not wanted (rejected). For an existing stream, setting port to zero terminates it; this also ceases RTCP for RTP streams.
Capabilities indication uses a specially structured SDP where all m= lines have port set to zero, the t= line is '0 0', and dynamic payload types have rtpmap attributes. This prevents media streams from being established if the SDP is mistaken for an offer.
Direction attributes (sendonly, recvonly, sendrecv, inactive) are applied per media stream or per session, controlling the flow of media between offerer and answerer. sendrecv is the default when no direction attribute is present.
The offer/answer model defines two roles: offerer (generates an SDP offer describing desired media streams, codecs, addresses, and ports) and answerer (responds with an SDP answer reflecting its own capabilities and accepted parameters).
An attacker who can modify offers or answers in transit can divert media streams for eavesdropping, disable calls, or inject unwanted media. A passive listener who can inject fake offers can cause similar harm.
Replay attacks are a specific concern: an attacker can replay an old offer (e.g., one that put media on hold) to disable ongoing media streams; the carrying protocol must provide sequencing and replay detection.
Hold mechanism: a sendrecv stream is placed on hold by the offerer marking it sendonly (offerer stops receiving); a recvonly stream is placed on hold by marking it inactive. Each stream direction is held independently. The held party SHOULD NOT automatically return held SDP.
Session lifecycle: an agent begins with no session; an initial offer starts a pending state; if answered the session is established; if rejected the session reverts to its prior state. At any time either party may issue a new offer to modify the session, but not while a prior offer is outstanding.