FW: [AVT] RFC3550 RTP Session defintion Qi

[Ivan R. Judson]

This is an interesting clarification for those who think about streaming
media.

--Ivan 

-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Stephen Casner
Sent: Monday, August 16, 2004 6:56 PM
To: Oren Peleg
Cc: AVT WG
Subject: RE: [AVT] RFC3550 RTP Session defintion Qi

To close off this thread, let me mention that Oren Peleg sent a private
reply to say that he understood what I was saying about RTP sessions after
considering that the same RTCP report is sent to all participants in a
shared session.

To be fair, this is a rather subtle issue that we authors and designers of
RTP did not understand correctly when RFC 1889 was written.  That first
version of the spec defined the RTP session by the destination port pair
(RTP+RTCP) and required that a participant use the same destination port to
receive packets from all other participants in a multi-party unicast RTP
session.

At the 41st IETF in Los Angeles in April, 1998, Marcel Graf asked me about
the number of RTP sessions in a multi-unicast scenario because this was
unclear in the context of H.323 session setup.  It was not until relatively
late in the editing of the spec for RFC 3550 that we discussed the current
RTP session definition at some length.  It became clear to me that "the
distinguishing feature of an RTP session is that each maintains a full,
separate space of SSRC identifiers" and that the underlying use of multicast
with a common port pair or unicast with different port pairs did not matter.

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt