[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] RTP topologies and terms
Ye-Kui.Wang at nokia.com skrev:
> Dear RTP Experts,
>
> Could anyone help to clarify the following: what is the RTP topology,
> and what is the right term for end-point B?
>
> The topology is as follows:
>
> +----+ +---+ +---+
> | A |=====>| B | ----------->| C |
> +----+ +---+ +---+
>
> - A sends a scalable bitstream of multiple layers using multiple RTP
> sessions (layered multicast).
> - B aggregates the input RTP streams from the multiple RTP sessions to
> one RTP stream and sends to C.
>
> I failed to map the topology to any of those (or their combinations)
> mentioned in draft-ietf-avt-topologies-06.txt , where all seem talking
> about end points within one RTP session. Also I am wondering whether B
> can be called a translator, mixer or (RTCP terminating) MCU? There are
> multiple RTP sessions between A and B, and there seems to be only one
> RTP sessions between B and C, therefore B terminates RTP sessions. If
> this is true, then B can neither be called translator nor mixer,
> according to the comment made by Colin earlier (on August 18 2007 in the
> AVT reflector that "Neither an RTP translator or a RTP mixer terminate
> the RTP session."). Or is it so that the one RTP stream from B to C are
> still of multiple sessions (hence B does not terminate RTP sessions)?
>
Well, the RTP topologies document hasn't very much discussed the issue
of scalability modification of streams. In my view B is either a mixer
or a translator depending on how it does the aggregation. The fact that
it appears that it terminates some of the RTP sessions for the higher
layers I don't think really count in this case. There is correlation
between the RTP sessions carrying the layers that I think is maintained
over the translation. I do expect that CNAMEs etc are consistent over
all the layers. But it will be interesting to rewrite the RTCP reports
to correctly reflect that your packets from layer X which was sent to
the receiver in the aggregate has been delivered or lost.
I think this maybe needing more discussion in the SVC document. It is
after all proposing to do these things using what it call MANEs.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt