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

Document Type Expired Internet-Draft (individual)
Author Jonathan Lennox 
Last updated 2012-09-06 (latest revision 2012-03-05)
Stream (None)
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

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


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.)