The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model
Extracted elements (14)
An alternative design would have T respond 200 OK immediately and let A subscribe to the conference event package to learn about B's response. This was rejected because it is more complex, requires more messages, and introduces higher session setup delays.
RFC 5363 requires URI-list services to use opt-in lists (e.g., RFC 5360), but transcoders using this model are explicitly exempt: they produce no amplification (only one outgoing INVITE per incoming INVITE), the callee URI is supplied by the caller (not an opaque translation), and the caller's identity is present in the outgoing INVITE.
The URI syntax required to encode a recipient-list body into a '?body=' parameter in the 302 Contact header is complex. RFC 5370 notes it is simpler for callees to use the 3pcc transcoding model (RFC 4117) instead.
If a transcoder receives an INVITE with a URI-list containing more than one URI, it SHOULD return a 488 (Max 1 URI allowed in URI-list) response, as the model is limited to two-party sessions.
The transcoder MUST generate the From header field of the outgoing INVITE using the same value as the From header field in the incoming INVITE, subject to privacy requirements expressed in that incoming INVITE (RFC 3323, RFC 3325). This does not apply to the 'tag' parameter.
Transcoders MUST authenticate and authorize users and MAY provide information about the identity of the original sender in outgoing requests using the SIP identity mechanism (RFC 4474).
When the transcoder receives a final response for the outgoing INVITE, it SHOULD generate a new final response for the incoming INVITE with the same status code as the one received.
In the callee's invocation model, B returns a 302 (Moved Temporarily) response whose Contact header contains the transcoder URI plus a '?body=' parameter encoding a recipient-list body with B's own URI, redirecting A to invoke T.
In the conference bridge transcoding model, the transcoder T acts as a B2BUA between UAs A and B. Both UAs exchange signalling and media exclusively with T; no traffic flows directly between A and B.
User agent A invokes transcoding by sending an INVITE to the transcoder that includes a recipient-list body part (per RFC 5366) containing a single URI: user agent B's URI. This single INVITE establishes both the A-T session and triggers T to call B.
Transcoders implementing this specification behave as URI-list services per RFC 5366, so security considerations from RFC 5363 apply, including list integrity and protection against unsolicited requests. UAs SHOULD integrity-protect URI-lists using S/MIME or TLS, which can also provide confidentiality.
Caller invocation flow: (1) A sends INVITE+SDP+URI-list to T; (2) T sends 183 Session Progress to A; (3) T sends new INVITE to B; (4) B replies 200 OK; (5) T sends ACK to B; (6) T sends 200 OK to A; (7) A sends ACK to T; media flows A-T and T-B.
Unsuccessful session: if B returns a non-2xx response (e.g., 603 Decline), T propagates the same non-2xx response back to A. If the provisional 183 is lost, A cannot distinguish transcoder rejection from callee rejection; the History-Info header (RFC 4244) resolves this ambiguity.
The caller's INVITE to the transcoder uses multipart/mixed content with two body parts: an SDP session description (application/sdp) and a URI-list (application/resource-lists+xml) with Content-Disposition of recipient-list. The Require header must include 'recipient-list-invite'.