Subject: [MMUSIC] Comments on draft-alvestrand-one-rtp-01

From: [email-masked] (Dale R. Worley)
Date: Fri, 1 Feb 2013 18:36:22 -0500 (EST)

general

I think the concept is that the various media streams are
demultiplexed out of the common RTP scheme by the fact that each
payload type (codec type number) appears in at most one m= line of the
bundle.  But that isn't stated explicitly anywhere.  In any case, the
method for demultiplexing the RTP should be stated explicitly.

section 4

   If the answerer wishes to refuse an entire m= section, while
   accepting the RTP session otherwise, he MAY indicate this by setting
   the port number of the relevant section to zero.

... and remove that m= line's mid value from the group attribute.
RFC 5888 section 9.2

section 7

In regard to RTCP, it appears that RTCP reports on each SSRC
separately.  I would expect that the bandwidth for the RTCP reports on
a stream would be limited to 5% of the bandwidth for that stream.
This keeps the total RTCP bandwidth below 5% of the total stream
bandwidth; indeed it is what you would get if you simply merged the
RTCP streams for the various media streams considered as separate RTP
streams.  In this configuration, the RTCP for an audio stream would
never exceed the RTP for the audio stream.  Although it does result in
the frequency of reports differing between the various streams.

Dale

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Feb 2013 19:38:52 +0100

> method for demultiplexing the RTP should be stated explicitly.

This is incorrect. Media streams are demultiplexed by SSRC.
Payload types are specified in at most one m= line because if the same 
payload type value appeared in two different m= lines, it would be 
impossible to tell from the incoming RTP packet which type it was 
intended to be.

> ... and remove that m= line's mid value from the group attribute.

Good catch.

> the frequency of reports differing between the various streams.

This is incorrect (or I'm serioiusly misunderstanding something). An 
RTCP sender or receiver report (RFC 3550 section 6.4) is supposed to 
report on all SSRCs, and the transmission interval is set for the RTP 
session, not separately for each media stream.

>
> Dale
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Feb 2013 22:27:06 -0500 (EST)

> From: Harald Alvestrand <[email-masked]>
> 

This is more complex than it first appears, including ambiguity in the
term "media stream".  I'm considering the problem of attributing each
incoming RTP packet to a particular m= line in the SDP.  But that is
based on an assumption that identifying the correct m= line is
important to the application layer above.  More about that later...

> session, not separately for each media stream.

Your understanding is much more likely to be correct than mine, and
RFC 3550 section 6.4 supports your statement.  But as somebody noted,
if there is both an audio and video stream, RTCP reports should be
sent sufficiently frequently for the video stream that the information
contained in them for the audio stream approaches the bandwidth of the
audio stream itself.

We may not need to care, given the RTCP is still a small fraction of
the overall bandwidth demand, but it may desirable to modify the rules
in section 6.4 to allow less frequent reports for sources that are
producing packets less frequently.

Dale