Sign in
Version 5.13.0, 2015-03-25
Report a bug

Real-Time Transport Protocol (RTP) Topology Considerations for Offer/ Answer-Initiated Sessions.

Document type: Expired Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2012-09-06 (latest revision 2012-03-05)
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: Expired
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found here:


This document discusses a number of considerations related to the topologies of Real-Time Transport Protocol (RTP) sessions initated using the Session Description (SDP) unicast Offer/Answer Model, especially as applied to source-multiplexed sessions. The primary observation is that certain topologies cannot be created by unicast SDP Offer/Answer. Notably, the it is not possible to negotiate the topology that RFC 5117 calls Topo-Transport-Translator (or "relay"). As a consequence of this limitation, certain topological assumptions can safely be made for RTP sessions initiated using unicast SDP Offer/Answer; and therefore, certain optimizations to RTP are possible in such sessions. This document also describes the optimizations that these assumptions make possible.


Jonathan Lennox <>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)