Hi Colin, See inline... Tom P. > -----Original Message----- > From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx] > Sent: Thursday, July 13, 2006 11:06 AM > To: Phelan, Tom > Cc: dccp@xxxxxxxx > Subject: Re: Comments on RTP over DCCP > > 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. [Tom] Yes, I caught that yesterday. > > > 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. [Tom] Man, no wonder I'm confused about this :-). This text seems to have a few internal conflicts, but I think it comes down to saying a session is the traffic you receive on a given port (pair) plus destination address. Although a session may span multiple port/destination address sets. And it also seems to say that a session is one medium flow, although it isn't particularly clear or forceful about this, especially since a session can span multiple port/address sets. > > > 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. [Tom] Yes, so given the interpretation of the text above, multiple calls over one DCCP connection wouldn't be, well, normal. PS. Thanks for your patience in educating me on the intricacies of RTP. :-) > > Colin
