The Early Session Disposition Type for the Session Initiation Protocol (SIP)
Extracted elements (20)
Application servers need a means to perform an offer/answer exchange with the UAC that is independent from the offer/answer exchange between both UAs, because the UAC may have applied end-to-end encryption or included key management information in the original offer that the application server is not supposed to use.
The application server model, which uses early-session bodies, was adopted because performing all offer/answer exchanges within the original dialog avoids synchronization problems, does not require globally routable URIs, avoids service interaction issues, and makes firewall management easier compared to establishing a separate dialog for early media.
UASs need a separate offer/answer exchange for early media to avoid media clipping. When an INVITE forks and the UAC mutes all but one UAS, if the chosen UAS sends a 200 OK after being muted, a new offer/answer exchange is needed to unmute it, causing clipping.
Early-session bodies follow the same offer/answer model as session bodies (RFC 3261 and RFC 3264) but may not appear in 2xx responses for an INVITE or in ACKs, distinguishing them from session bodies.
An early media session established using early-session bodies MUST be terminated when its corresponding early dialog is terminated or it transitions to a regular dialog.
Early-session bodies MUST follow the offer/answer model and MAY appear in the same messages as session bodies do, with the exceptions of 2xx responses for an INVITE and ACKs.
If a UA needs to refuse an early-session offer, it MUST do so by refusing all the media streams in it. When SDP is used, this is done by setting the port number of all media streams to zero.
It is NOT RECOMMENDED that early offers in INVITEs be included because they can fork, and the UAC could receive multiple early answers establishing early media streams at roughly the same time.
It is RECOMMENDED that UAs generating regular and early session descriptions use the same codecs in both, so that the remote UA does not need to change codecs when the early session transitions to a regular session.
The use of the same transport address (IP address plus port) in a session body and in an early-session body is NOT RECOMMENDED. Using different transport addresses to receive early and regular media makes it easy to detect the start of the regular media.
User agents MUST use early-session bodies to establish early media sessions in the same way as they use session bodies to establish regular sessions, as described in RFCs 3261 and 3264.
Preconditions as defined in RFC 3312 MAY be used with early-session bodies and are treated the same way as preconditions in regular sessions: UAs do not exchange media and the called user is not alerted until preconditions are met.
The 'early-session' disposition type for the Content-Disposition header field is defined to establish early media sessions within early dialogs, as opposed to regular 'session' bodies which establish sessions within regular dialogs. Early-session bodies follow the offer/answer model just as session bodies do.
The 'early-session' option tag is defined for use in Require and Supported header fields. A UA adding this option tag to a message indicates that it understands the early-session disposition type.
The 'early-session' Content-Disposition type is registered in the IANA registry for Content-Dispositions, described as: 'The body describes an early communications session, for example, an RFC 2327 SDP body'.
The 'early-session' SIP option tag is registered in the SIP parameters registry under 'Option Tags', indicating that a UA adding this tag understands the early-session content disposition.
An early media-specific risk analogous to PSTN toll fraud exists: rogue UAs may establish a bidirectional early media session and never send a 2xx response to exploit charging policies that treat early media as free. Operators should consider charging early media sessions that last too long or stopping them at the media level.
To prevent DoS attacks where an attacker causes a UA to send media to a victim by supplying the victim's transport address in a session description, the UA SHOULD perform a handshake (e.g., via a connection-oriented protocol, STUN, or SRTP key exchange) to verify willingness to receive media before sending large amounts of data.
UAs SHOULD encrypt their session descriptions (e.g., using S/MIME) to prevent attackers from gaining access to transport addresses in session descriptions and sending unauthorized media packets.
UAs SHOULD use media-level authentication mechanisms (e.g., SRTP) to prevent attackers from guessing transport addresses and injecting media. UAs wishing to keep communications confidential SHOULD use media-level encryption mechanisms such as SRTP.