@techreport{lennox-avtcore-rtp-topo-offer-answer-00,
    number =    {draft-lennox-avtcore-rtp-topo-offer-answer-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-lennox-avtcore-rtp-topo-offer-answer/00/},
    author =    {Jonathan Lennox},
    title =     {{Real-Time Transport Protocol (RTP) Topology Considerations for Offer/ Answer-Initiated Sessions.}},
    pagetotal = 11,
    year =      2012,
    month =     mar,
    day =       5,
    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.},
}