Real-Time Transport Protocol (RTP) Topology Considerations for Offer/ Answer-Initiated Sessions.
draft-lennox-avtcore-rtp-topo-offer-answer-00

 
Document Type Expired Internet-Draft (individual)
Last updated 2012-09-06 (latest revision 2012-03-05)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html
Stream Stream state (No stream defined)
Document shepherd No shepherd assigned
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
https://www.ietf.org/archive/id/draft-lennox-avtcore-rtp-topo-offer-answer-00.txt

Abstract

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.

Authors

Jonathan Lennox (jonathan@vidyo.com)

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