datatracker.ietf.org
Sign In
Version 4.50, 2013-05-15
Report a bug

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

Expired Internet-Draft (None)
Document Stream: No stream defined
Last updated: 2012-03-05
Intended RFC status: (None)
Other versions: (expired, archived): plain text, pdf, html
Document shepherd:(None)
Shepherd writeup
IESG State: Expired
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. Unofficial copies of old Internet-Drafts can be found here:
http://tools.ietf.org/id/draft-lennox-avtcore-rtp-topo-offer-answer.

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)