Hi Tom,
On 11 Jul 2006, at 13:40, Phelan, Tom wrote:
A couple of comments/questions on RTP/DCCP (excuse me if I'm asking
questions I asked before, but if I did, I'm still unclear on the
answers):
Section 4.1 has a todo about supplying more direction on the
implementation of congestion control in an RTP app -- what do you have
in mind here?
As I mentioned yesterday, I plan to remove this, and give a pointer
to the TFRC media guide and DCCP user guide drafts.
Section 4.3 Multiplexing Data and Control -- do we need to create a
rule
for RTP that says RTP payload types must not conflict with RTCP packet
types? Or are we relying on the user of a particular profile to
know if
overlap exists and therefore open two connections?
RTP payload types are dynamically assigned during session setup. When
negotiating an RTP-over-DCCP session, you'd pick payload types that
don't conflict, according to section 4.3 of the draft.
Section 4.4, RTP Sessions and DCCP Connections -- I'm a little unclear
on the meaning of "RTP session", in particular the relationship of
session to synchronization source.
From RFC 3550 section 3:
RTP session: An association among a set of participants
communicating with RTP. A participant may be involved in
multiple
RTP sessions at the same time. In a multimedia session, each
medium is typically carried in a separate RTP session with its
own
RTCP packets unless the the encoding itself multiplexes multiple
media into a single data stream. A participant distinguishes
multiple RTP sessions by reception of different sessions using
different pairs of destination transport addresses, where a pair
of transport addresses comprises one network address plus a pair
of ports for RTP and RTCP. All participants in an RTP session
may
share a common destination transport address pair, as in the case
of IP multicast, or the pairs may be different for each
participant, as in the case of individual unicast network
addresses and port pairs. In the unicast case, a participant may
receive from all other participants in the session using the same
pair of ports, or may use a distinct pair of ports for each.
The distinguishing feature of an RTP session is that each
maintains a full, separate space of SSRC identifiers (defined
next). The set of participants included in one RTP session
consists of those that can receive an SSRC identifier transmitted
by any one of the participants either in RTP as the SSRC or a
CSRC
(also defined below) or in RTCP. For example, consider a three-
party conference implemented using unicast UDP with each
participant receiving from the other two on separate port pairs.
If each participant sends RTCP feedback about data received from
one other participant only back to that participant, then the
conference is composed of three separate point-to-point RTP
sessions. If each participant provides RTCP feedback about its
reception of one other participant to both of the other
participants, then the conference is composed of one multi-party
RTP session. The latter case simulates the behavior that would
occur with IP multicast communication among the three
participants.
The RTP framework allows the variations defined here, but a
particular control protocol or application design will usually
impose constraints on these variations.
Is this meant to allow, for example, two PSTN gateways multiplexing
media for several calls over the same DCCP connection?
Probably not. I'd expect each call to be a separate session.
Colin
