Subject: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 6 Sep 2015 13:24:12 +0000

I did not monitor the progress of this draft over its lifetime, so this is more of an "outsider's review" (which probably is useful in its own right)

i- 2. Terminology
"Media Type:  The general type of media data used by a real-time
      application.  The media type corresponds to the value used in the
      <media> field of an SDP m= line.  The media types defined at the
      time of this writing are "audio", "video", "text", "application",
      and "message"."

- It could be good to provide a reference to the corresponding IANA registry.
- I know it is not very common but still defined/possibly used, is there a specific reason not to include "image" (e.g., image/t38, image/g3fax) in this list?

ii- 3.  Background and Motivation
In general, this section seems trying to do a "hard sell", which IMHO can be softened up a little bit.

- "However, we note that many RTP-using application don't use network
   QoS features, and don't expect or desire any separation in network
   treatment of their media packets, independent of whether they are
   audio, video or text.  When an application has no such desire, it
   doesn't need to provide a transport flow structure that simplifies
   flow based QoS."
This really depends on the environment and deployment model. In addition to that, providing QoS with DiffServ is still possible when multiple types of media are sent in a single RTP session as explained in draft-ietf-dart-dscp-rtp (which is already referenced by this draft)

-  "1.  increased delay to establish a complete session, since each of
       the transport layer flows needs to be negotiated and established;"
At least negotiation part can happen in parallel. And when multiple streams use the same RTP session, isn't there still a need to negotiate different SSRC values, one per stream? A reference to RFC5576 could be useful as well.

iii- 5.3.  Per-SSRC Media Type Restrictions 
This section provides the justification why different SSRC but be used for audio and video streams but not really why a SSRC can't be re-used for streams of different type. It would be good to cover that aspect as well.

iv- 4.  Applicability
"Compatible RTCP Behaviour:  The RTCP timing rules enforce a single
      RTCP reporting interval for all participants in an RTP session.
      Flows with very different media sending rate or RTCP feedback
      requirements cannot be multiplexed together, since this leads to
      either excessive or insufficient RTCP for some flows, depending
      how the RTCP session bandwidth, and hence reporting interval, is
      configured."
This part IMHO requires more justification. Why is it not possible to send RTCP in different rates for different flows? Some RTCP packets could have reports pertaining to a single stream whereas the other ones (when timing for reports for different streams overlaps or is sufficiently close enough) for multiple streams. Aggregate RTCP bandwidth need shouldn't be a constraining factor just because a single transport flow is used AFAICS. If that is not the case, it really could be useful to explain why.

v- 7.  Signalling
"When using SDP signalling, the BUNDLE extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP
sessions containing multiple media types."
It could be a good idea to reference relevant sections as the bundle-draft has some irrelevant aspects (arguably which even could be confusing in the context of this specification).

Thanks,
Tolga

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: Friday, September 04, 2015 3:31 AM
> To: [email-masked]
> Subject: [rtcweb] Fwd: [AVTCORE] WGLC on draft-ietf-avtcore-multi-media-
> rtp-session-09
> 
> RTCWEB WG,
> 
> As an author of these documents I want to inform you that there is a
> relevant WG last call that ends in another 6 days.
> 
> RTCWEB is a consumer of this document, please review and send feedback
> to AVTCORE WG.
> 
> Cheers
> 
> Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 7 Sep 2015 12:35:02 +0100

Hi,

Thanks for the review; some responses inline.

> - I know it is not very common but still defined/possibly used, is there a specific reason not to include "image" (e.g., image/t38, image/g3fax) in this list?

I copied the list from draft-ietf-mmusic-rfc4566bis-15, which doesn't mention "image". I agree we should mention it, as should 4566bis. (I've cc'd Ali, for comment).

> This really depends on the environment and deployment model. In addition to that, providing QoS with DiffServ is still possible when multiple types of media are sent in a single RTP session as expl…

It's not clear what change you want here. Do you have a suggestion for how to update the text?

> At least negotiation part can happen in parallel. And when multiple streams use the same RTP session, isn't there still a need to negotiate different SSRC values, one per stream? A reference to RFC…

Negotiation can only happen in parallel to a certain extent, before the amount of STUN traffic causes congestion. The SSRCs also don't necessarily have to be negotiated in advance for either model. 

> This section provides the justification why different SSRC but be used for audio and video streams but not really why a SSRC can't be re-used for streams of different type. It would be good to cove…

Sorry, I'm not sure what you're asking here. Can you rephrase?

> This part IMHO requires more justification. Why is it not possible to send RTCP in different rates for different flows? Some RTCP packets could have reports pertaining to a single stream whereas th…

The RTCP timing rules in RFC 3550 don't support different reporting intervals for different SSRCs (other than a sender/receiver split), and doing so runs a risk of causing inappropriate RTCP timeouts. We could add a reference to RFC 3550 here, if it helps?

> It could be a good idea to reference relevant sections as the bundle-draft has some irrelevant aspects (arguably which even could be confusing in the context of this specification).

Can you be specific on how BUNDLE should be referenced?

Cheers,
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 10 Sep 2015 10:27:10 +0000

Please see inline for questions/answers/comments.

Thanks,
Tolga

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, September 07, 2015 7:35 AM
> To: Asveren, Tolga <[email-masked]>
> Cc: [email-masked]; Ali Begen <[email-masked]>
> Subject: Re: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-
> session-09
> 
> Hi,
> 
> > I did not monitor the progress of this draft over its lifetime, so
> > this is more of an "outsider's review" (which probably is useful in
> > its own right)
> >
> > i- 2. Terminology
> > - I know it is not very common but still defined/possibly used, is there a
> specific reason not to include "image" (e.g., image/t38, image/g3fax) in this
> list?
> 
> I copied the list from draft-ietf-mmusic-rfc4566bis-15, which doesn't mention
> "image". I agree we should mention it, as should 4566bis. (I've cc'd Ali, for
> comment).
> 
> > This really depends on the environment and deployment model. In
> > addition to that, providing QoS with DiffServ is still possible when
> > multiple types of media are sent in a single RTP session as explained
> > in draft-ietf-dart-dscp-rtp (which is already referenced by this
> > draft)
> 
[TOLGA] Maybe just taking out QoS related part?
> > At least negotiation part can happen in parallel. And when multiple streams
> use the same RTP session, isn't there still a need to negotiate different SSRC
> values, one per stream? A reference to RFC5576 could be useful as well.
> 
> Negotiation can only happen in parallel to a certain extent, before the
> amount of STUN traffic causes congestion. The SSRCs also don't necessarily
> have to be negotiated in advance for either model.
[TOLGA] It could be useful to provide more information about how demultiplexing based on SSRC would work when multiple streams are sent in the same RTP session. Isn't there inherently a need to associate a stream with a particular SSRC? How is this done? Just a description of that, maybe in Section 5.2. so that the logic is obvious to people (particularly to first-time readers).
> 
> > iii- 5.3.  Per-SSRC Media Type Restrictions This section provides the
> > justification why different SSRC but be used for audio and video streams
> but not really why a SSRC can't be re-used for streams of different type. It
> would be good to cover that aspect as well.
> 
[TOLGA] Mea culpa, I think 5.3 already explains why the same SSRC can't be re-used for streams of different type:
  "The payload type will inform a receiver which
   media type the SSRC is being used for.  Thus the payload type MUST be
   unique across all of the payload configurations independent of media
   type that is used in the RTP session."
I guess this section provides the justification. Please correct me if I am wrong.
> > This part IMHO requires more justification. Why is it not possible to send
> RTCP in different rates for different flows? Some RTCP packets could have
> reports pertaining to a single stream whereas the other ones (when timing
> for reports for different streams overlaps or is sufficiently close enough) for
> multiple streams. Aggregate RTCP bandwidth need shouldn't be a
> constraining factor just because a single transport flow is used AFAICS. If that
> is not the case, it really could be useful to explain why.
> 
> The RTCP timing rules in RFC 3550 don't support different reporting intervals
> for different SSRCs (other than a sender/receiver split), and doing so runs a
> risk of causing inappropriate RTCP timeouts. We could add a reference to RFC
> 3550 here, if it helps?
[TOLGA] Can't this be changed? On a high level, aren't we talking about two different RTCP streams here? Why should their timing be aligned in any way?
> > It could be a good idea to reference relevant sections as the bundle-draft
> has some irrelevant aspects (arguably which even could be confusing in the
> context of this specification).
> 
[TOLGA] Maybe just specifying which sections are relevant and which are not, e.g. "14. RTP/RTCP extensions for identification-tag transport" in draft-ietf-mmusic-sdp-bundle-negotiation-23.txt, is this part relevant to  draft-ietf-avtcore-multi-media-rtp-session-09?

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Sep 2015 11:52:40 +0100

> On 10 Sep 2015, at 11:27, Asveren, Tolga <[email-masked]> wrote:
> 
>>> - I know it is not very common but still defined/possibly used, is there a specific reason not to include “image” (e.g., image/t38, image/g3fax) in this list?
>> 
>>> In general, this section seems trying to do a “hard sell", which IMHO can be softened up a little bit.
>>> 

Since RFC 3550 explicitly calls out QoS as a reason for sending multiple media streams on different transport layer flows, I don’t think we can do this.

>>> At least negotiation part can happen in parallel. And when multiple streams use the same RTP session, isn’t there still a need to negotiate different SSRC values, one per stream? A reference to RFC5576 could be useful as well.
>> 

RTP doesn’t have a requirement to associate a stream with an SSRC. Certain classes of application might have such a requirement, but that’s a signalling issue, and so not something for this draft (it’s something for BUNDLE, or similar, to specify).

>>> iii- 5.3.  Per-SSRC Media Type Restrictions This section provides the justification why different SSRC but be used for audio and video streams but not really why a SSRC can’t be re-used for streams of different type. It would be good to cover that aspect as well.
>> 

The 2nd and 3rd paragraphs of Section 5.3 explain why an SSRC can’t simultaneously be used for audio and video streams. 

An SSRC cannot start using audio and then switch to using video, since that would require a change in RTP timestamp rate (which RFC 7160 explains doesn’t work). However, an SSRC can send audio then leave the session (by sending an RTCP BYE, or stopping sending RTP and RTCP for long enough that it times out), then a new source can start with the same SSRC number sending video; this doesn’t cause confusion because the audio SSRC has gone before the video SSRC starts.

>>> This part IMHO requires more justification. Why is it not possible to send RTCP in different rates for different flows? Some RTCP packets could have reports pertaining to a single stream whereas the other ones (when timing for reports for different streams overlaps or is sufficiently close enough) for multiple streams. Aggregate RTCP bandwidth need shouldn’t be a constraining factor just because a single transport flow is used AFAICS. If that is not the case, it really could be useful to explain why.
>> 

Their timing isn’t aligned, they merely use the same base RTCP reporting interval, before randomisation, and modulo the difference between sender and receiver bandwidth allocation. This is the usual RFC 3550 RTCP timing rules. If you want different reporting intervals, you need to use separate RTP sessions. 

> [TOLGA] Maybe just specifying which sections are relevant and which are not, e.g. "14. RTP/RTCP extensions for identification-tag transport" in draft-ietf-mmusic-sdp-bundle-negotiation-23.txt, is t…

This is to address the stream identification issue you raise above.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 10 Sep 2015 16:55:12 +0000

>> The RTCP timing rules in RFC 3550 don't support different reporting 
>> intervals for different SSRCs (other than a sender/receiver split), 
>> and doing so runs a risk of causing inappropriate RTCP timeouts. We 
>> could add a reference to RFC
>> 3550 here, if it helps?

Their timing isn’t aligned, they merely use the same base RTCP reporting interval, before randomisation, and modulo the difference between sender and receiver bandwidth allocation. This is the usual RFC 3550 RTCP timing rules. If you want different reporting intervals, you need to use separate RTP sessions.
[TOLGA] I was also referring to reporting timing but admittedly not being clear. But then again, why should their timing be the same? Is there a technical justification or "just" because RFC3550 (which probably did not consider the use case defined/explained in this draft as it was not defined yet) says so?

Thanks,
Tolga

> Sent: Thursday, September 10, 2015 6:53 AM
> specific reason not to include “image” (e.g., image/t38, image/g3fax) in this
> list?
> >>
> >> I copied the list from draft-ietf-mmusic-rfc4566bis-15, which doesn't
> >> mention "image". I agree we should mention it, as should 4566bis.
> >> (I've cc'd Ali, for comment).
> >>
> >>> - "However, we note that many RTP-using application don't use
> >>> network  QoS features, and don't expect or desire any separation in
> >>> network  treatment of their media packets, independent of whether
> >>> they are  audio, video or text.  When an application has no such
> >>> desire, it  doesn't need to provide a transport flow structure that
> >>> simplifies  flow based QoS."
> >>> multiple types of media are sent in a single RTP session as
> >>> explained in draft-ietf-dart-dscp-rtp (which is already referenced
> >>> by this
> >>> draft)
> >>
> Since RFC 3550 explicitly calls out QoS as a reason for sending multiple media
> streams on different transport layer flows, I don’t think we can do this.
> 
> >>> At least negotiation part can happen in parallel. And when multiple
> streams use the same RTP session, isn’t there still a need to negotiate
> different SSRC values, one per stream? A reference to RFC5576 could be
> useful as well.
> >>
> >> Negotiation can only happen in parallel to a certain extent, before
> >> the amount of STUN traffic causes congestion. The SSRCs also don't
> >> necessarily have to be negotiated in advance for either model.
> > [TOLGA] It could be useful to provide more information about how
> demultiplexing based on SSRC would work when multiple streams are sent in
> the same RTP session. Isn't there inherently a need to associate a stream
> with a particular SSRC? How is this done? Just a description of that, maybe in
> Section 5.2. so that the logic is obvious to people (particularly to first-time
> readers).
> 
> RTP doesn’t have a requirement to associate a stream with an SSRC. Certain
> classes of application might have such a requirement, but that’s a signalling
> issue, and so not something for this draft (it’s something for BUNDLE, or
> similar, to specify).
> 
> justification why different SSRC but be used for audio and video streams but
> not really why a SSRC can’t be re-used for streams of different type. It would
> be good to cover that aspect as well.
> >>
> The 2nd and 3rd paragraphs of Section 5.3 explain why an SSRC can’t
> simultaneously be used for audio and video streams.
> 
> An SSRC cannot start using audio and then switch to using video, since that
> would require a change in RTP timestamp rate (which RFC 7160 explains
> doesn’t work). However, an SSRC can send audio then leave the session (by
> sending an RTCP BYE, or stopping sending RTP and RTCP for long enough that
> it times out), then a new source can start with the same SSRC number
> sending video; this doesn’t cause confusion because the audio SSRC has
> gone before the video SSRC starts.
> 
> 
> >>> iv- 4.  Applicability
> multiple streams. Aggregate RTCP bandwidth need shouldn’t be a
> >> The RTCP timing rules in RFC 3550 don't support different reporting
> >> intervals for different SSRCs (other than a sender/receiver split),
> >> and doing so runs a risk of causing inappropriate RTCP timeouts. We
> >> could add a reference to RFC
> >> 3550 here, if it helps?
> > [TOLGA] Can't this be changed? On a high level, aren't we talking about two
> different RTCP streams here? Why should their timing be aligned in any way?
> 
> Their timing isn’t aligned, they merely use the same base RTCP reporting
> interval, before randomisation, and modulo the difference between sender
> and receiver bandwidth allocation. This is the usual RFC 3550 RTCP timing
> rules. If you want different reporting intervals, you need to use separate RTP
> sessions.
> 
> >>> v- 7.  Signalling
> >> has some irrelevant aspects (arguably which even could be confusing
> >> in the context of this specification).
> >>
> > [TOLGA] Maybe just specifying which sections are relevant and which are
> not, e.g. "14. RTP/RTCP extensions for identification-tag transport" in draft-
> ietf-mmusic-sdp-bundle-negotiation-23.txt, is this part relevant to  draft-ietf-
> avtcore-multi-media-rtp-session-09?
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Sep 2015 18:56:30 +0100

> [TOLGA] I was also referring to reporting timing but admittedly not being clear. But then again, why should their timing be the same? Is there a technical justification or "just" because RFC3550 (w…

The technical justification is as I said above: you get inappropriate timeouts, because the algorithm is based on all SSRCs using the same base reporting interval. 

Colin

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 10 Sep 2015 20:27:03 +0000

Inline...

Thanks,
Tolga

> Sent: Thursday, September 10, 2015 1:57 PM
> >> [TOLGA] Can't this be changed? On a high level, aren't we talking about
> two different RTCP streams here? Why should their timing be aligned in any
> way?
> >
> > [TOLGA] I was also referring to reporting timing but admittedly not being
> clear. But then again, why should their timing be the same? Is there a
> technical justification or "just" because RFC3550 (which probably did not
> consider the use case defined/explained in this draft as it was not defined
> yet) says so?
> 
> The technical justification is as I said above: you get inappropriate timeouts,
> because the algorithm is based on all SSRCs using the same base reporting
> interval.
[TOLGA] But that is exactly what I am asking, why can’t that be changed so that algorithm for different SSRCs are executed independently if multiple streams are multiplexed?
> >>>>> this is more of an "outsider's review" (which probably is useful
> >>>>> in its own right)
> >>>>>
> >>>>> i- 2. Terminology
> >>>>> - It could be good to provide a reference to the corresponding
> >>>>> IANA
> >> registry.
> >> specific reason not to include “image” (e.g., image/t38, image/g3fax)
> >> in this list?
> >>>>
> >>>> I copied the list from draft-ietf-mmusic-rfc4566bis-15, which
> >>>> doesn't mention "image". I agree we should mention it, as should
> 4566bis.
> >>>>> In general, this section seems trying to do a “hard sell", which
> >>>>> IMHO can
> >> be softened up a little bit.
> >>>>>
> >>>>> network  QoS features, and don't expect or desire any separation
> >>>>> in network  treatment of their media packets, independent of
> >>>>> whether they are  audio, video or text.  When an application has
> >>>>> no such desire, it  doesn't need to provide a transport flow
> >>>>> structure that simplifies  flow based QoS."
> >>>>> addition to that, providing QoS with DiffServ is still possible
> >>>>> when multiple types of media are sent in a single RTP session as
> >> Since RFC 3550 explicitly calls out QoS as a reason for sending
> >> multiple media streams on different transport layer flows, I don’t think
> we can do this.
> >>
> >> streams use the same RTP session, isn’t there still a need to
> >> negotiate different SSRC values, one per stream? A reference to
> >> RFC5576 could be useful as well.
> >>>>
> >> demultiplexing based on SSRC would work when multiple streams are
> >> sent in the same RTP session. Isn't there inherently a need to
> >> associate a stream with a particular SSRC? How is this done? Just a
> >> description of that, maybe in Section 5.2. so that the logic is
> >> obvious to people (particularly to first-time readers).
> >>
> >> RTP doesn’t have a requirement to associate a stream with an SSRC.
> >> Certain classes of application might have such a requirement, but
> >> that’s a signalling issue, and so not something for this draft (it’s
> >> something for BUNDLE, or similar, to specify).
> >>
> >> justification why different SSRC but be used for audio and video
> >> streams but not really why a SSRC can’t be re-used for streams of
> >> different type. It would be good to cover that aspect as well.
> >>>>
> >>> [TOLGA] Mea culpa, I think 5.3 already explains why the same SSRC
> >>> can't be
> >> re-used for streams of different type:
> >>> "The payload type will inform a receiver which  media type the SSRC
> >>> is being used for.  Thus the payload type MUST be  unique across all
> >>> of the payload configurations independent of media  type that is
> >>> used in the RTP session."
> >>> I guess this section provides the justification. Please correct me
> >>> if I am
> >> wrong.
> >>
> >> An SSRC cannot start using audio and then switch to using video,
> >> since that would require a change in RTP timestamp rate (which RFC
> >> 7160 explains doesn’t work). However, an SSRC can send audio then
> >> leave the session (by sending an RTCP BYE, or stopping sending RTP
> >> and RTCP for long enough that it times out), then a new source can
> >> start with the same SSRC number sending video; this doesn’t cause
> >> confusion because the audio SSRC has gone before the video SSRC starts.
> >>
> >>
> >>>>> iv- 4.  Applicability
> >> RTCP in different rates for different flows? Some RTCP packets could
> >> have reports pertaining to a single stream whereas the other ones
> >> (when timing for reports for different streams overlaps or is
> >> sufficiently close enough) for multiple streams. Aggregate RTCP
> >> bandwidth need shouldn’t be a constraining factor just because a
> >> single transport flow is used AFAICS. If that is not the case, it really could
> be useful to explain why.
> >>>>
> >> Their timing isn’t aligned, they merely use the same base RTCP
> >> reporting interval, before randomisation, and modulo the difference
> >> between sender and receiver bandwidth allocation. This is the usual
> >> RFC 3550 RTCP timing rules. If you want different reporting
> >> intervals, you need to use separate RTP sessions.
> >>
> >>>>> v- 7.  Signalling
> >> not, e.g. "14. RTP/RTCP extensions for identification-tag transport"
> >> in draft- ietf-mmusic-sdp-bundle-negotiation-23.txt, is this part
> >> relevant to  draft-ietf- avtcore-multi-media-rtp-session-09?
> >>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Sep 2015 21:42:22 +0100

> On 10 Sep 2015, at 21:27, Asveren, Tolga <[email-masked]> wrote:
> 
> Inline...
> 
> Thanks,
> Tolga
> 
>>>>> could add a reference to RFC 3550 here, if it helps?
>>>> [TOLGA] Can't this be changed? On a high level, aren’t we talking about two different RTCP streams here? Why should their timing be aligned in any way?
>>> 
>>> [TOLGA] I was also referring to reporting timing but admittedly not being clear. But then again, why should their timing be the same? Is there a technical justification or “just” because RFC3550 (which probably did not consider the use case defined/explained in this draft as it was not defined yet) says so?
>> 

Because that wouldn’t be compatible with existing RTP. You’re essentially saying you want to run multiple RTP sessions in parallel on the same port, to get different RTCP timing behaviour for each media. That would be easy to implement if we’d chosen a shim-based approach, rather than the BUNDLE approach (and was one of the many reasons some of us advocated that). It doesn’t work with the single RTP session model we adopted, however. You’d have to partition the SSRC space for the different sessions, rewrite RTCP scheduling and timeout rules, collision resolution, etc. By the time you’ve done that, you have a whole new protocol, incompatible, and sharing little but the packet syntax with RTP.

Using RTP/AVPF with the T_rr_interval parameter gives a lot of flexibility, and you can almost certainly do something that has a similar effect to what you suggest using it, in a compatible way. Failing that, run multiple RTP sessions on different transport layer ports, and you have flexibility to use whatever different RTCP intervals you want.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 10 Sep 2015 20:45:29 +0000

Thanks for the explanation, now it makes sense.

Thanks,
Tolga

> Sent: Thursday, September 10, 2015 4:42 PM
> >>>>> The RTCP timing rules in RFC 3550 don't support different
> >>>>> reporting intervals for different SSRCs (other than a
> >>>>> sender/receiver split), and doing so runs a risk of causing
> >>>>> inappropriate RTCP timeouts. We could add a reference to RFC 3550
> here, if it helps?
> >>>> [TOLGA] Can't this be changed? On a high level, aren’t we talking about
> technical justification or “just” because RFC3550 (which probably did not
> >> The technical justification is as I said above: you get inappropriate
> timeouts, because the algorithm is based on all SSRCs using the same base
> reporting interval.
> > [TOLGA] But that is exactly what I am asking, why can’t that be changed so
> that algorithm for different SSRCs are executed independently if multiple
> streams are multiplexed?
> 
> Because that wouldn’t be compatible with existing RTP. You’re essentially
> saying you want to run multiple RTP sessions in parallel on the same port, to
> get different RTCP timing behaviour for each media. That would be easy to
> implement if we’d chosen a shim-based approach, rather than the BUNDLE
> approach (and was one of the many reasons some of us advocated that). It
> doesn’t work with the single RTP session model we adopted, however. You’d
> have to partition the SSRC space for the different sessions, rewrite RTCP
> scheduling and timeout rules, collision resolution, etc. By the time you’ve
> done that, you have a whole new protocol, incompatible, and sharing little
> but the packet syntax with RTP.
> 
> Using RTP/AVPF with the T_rr_interval parameter gives a lot of flexibility, and
> you can almost certainly do something that has a similar effect to what you
> suggest using it, in a compatible way. Failing that, run multiple RTP sessions
> on different transport layer ports, and you have flexibility to use whatever
> different RTCP intervals you want.
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>