Subject: [AVT] Re: [MMUSIC] RE: SRTP payload mapping

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Nov 2006 12:07:07 -0500

This discussion should probably move to the AVT list; CC-ing.

Colin Perkins <[email-masked]> writes:
>> I believe atleast some kind of rough consensus was reached that in  order
>> to keep the existing RTP/RTCP architecture it should be possible to  send
>> feedback RTCP packets with a minimum size and thus abandon the  rules in
>> RFC3550 section 6.1.
>
>I do not believe that was the consensus. Instead the group considered  if
>that change should be explored to see if it resolves your problem,  without
>causing other issues. I can see reasons for making this  change, but also
>many potential problems due to lack of backwards  compatibility.

There may be ways to deal with this; AVPF has additional signalling
in the SDP indicating how it will be used; this can allow implementations
to negotiate the issues of RR/SR and avoid compatibility issues (I hope).

>> This means that in an implementetation the PT of the first RTCP packet
>> will be 200 or 201 with a relatively low bandwidth but it could  also be
>> 205 or 206 when small RTCP feedback packets are transmitted. Doing  like
>> this we will increase the chance of getting some useful feedback even
>> under severe radio conditions but we will still keep the RTP
>> architecture and and will avoid the fuss that inband signaling causes.
>>
>> I would like to avoid wordings like "should use SR or RR" for the  above
>> reasons. Also it seems to me like the cause for these "broken
>> implementations" is that many implementors just don't see any point in
>> transmitting large SR/RR's and CNAMEs in each and every RTCP packet.
>
>Yet many other implementations rely on this information being present  and
>correct, because they need lip-sync functionality, or because  they want to
>monitor reception quality, round-trip time, etc.

My suggestion is that if this was accepted (modulo signalling), the rule
would be to transmit RR/SR with similar timing rules to current RFC 3550
(AVP) timings, and allow early RTCP packets to not include RR/SR/CNAME/etc.
This would retain the normal AVP qualities while allowing for early
feedback.  Unfortunately this wasn't added to the original AVPF spec,
though it could have been.  It does slightly complicate the RTCP-sending
algorithm, but not dramatically, depending on the details decided on.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 21 Nov 2006 08:58:35 +0100

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]] 
> Sent: den 20 november 2006 18:07
> To: Colin Perkins
> Cc: Ingemar Johansson S (LU/EAB); Magnus Westerlund (KI/EAB); 
> [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] RE: SRTP payload mapping
> 
> >> I believe atleast some kind of rough consensus was reached 
> that in  
> >> order to keep the existing RTP/RTCP architecture it should be 
> >> possible to  send feedback RTCP packets with a minimum 
> size and thus 
> >> abandon the  rules in RFC3550 section 6.1.
> >
> >I do not believe that was the consensus. Instead the group 
> considered  
> >if that change should be explored to see if it resolves your 
> problem,  
> >without causing other issues. I can see reasons for making this  
> >change, but also many potential problems due to lack of 
> backwards  compatibility.
> 
> There may be ways to deal with this; AVPF has additional 
> signalling in the SDP indicating how it will be used; this 
> can allow implementations to negotiate the issues of RR/SR 
> and avoid compatibility issues (I hope).
> 
> >> This means that in an implementetation the PT of the first RTCP 
> >> packet will be 200 or 201 with a relatively low bandwidth but it 
> >> could  also be
> >> 205 or 206 when small RTCP feedback packets are 
> transmitted. Doing  
> >> like this we will increase the chance of getting some 
> useful feedback 
> >> even under severe radio conditions but we will still keep the RTP 
> >> I would like to avoid wordings like "should use SR or RR" for the  
> >> above reasons. Also it seems to me like the cause for 
> these "broken 
> >> implementations" is that many implementors just don't see 
> any point 
> >> in transmitting large SR/RR's and CNAMEs in each and every 
> RTCP packet.
> >
> >Yet many other implementations rely on this information 
> being present  
> >and correct, because they need lip-sync functionality, or 
> because  they 
> >want to monitor reception quality, round-trip time, etc.
> 
> My suggestion is that if this was accepted (modulo 
> signalling), the rule would be to transmit RR/SR with similar 
> timing rules to current RFC 3550
> This would retain the normal AVP qualities while allowing for 
> early feedback.  Unfortunately this wasn't added to the 
> original AVPF spec, though it could have been.  It does 
> slightly complicate the RTCP-sending algorithm, but not 
> dramatically, depending on the details decided on.

With some risk of beeing a little trigger happy.. This sounds like a
reasonable and relatively clean approach. 

I have already started on a draft that tries to describe this, I believe
that the purpose is then to propose some modifications to RFC4585.
The draft sofar describe a use case (slightly targeted towards the use
case in draft-johansson-avt-rtp-shim) but in order to make this more
general the use case might be removed.  
I have also started on a list of potential problems with RTCP packets
that does not follow the strict rules of section 6.1 of RFC3550. Sofar
only one problem is mentioned, namely that middle boxes might not
recognize non-compliant RTCP, what other problems might arise ?

Ingemar

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Nov 2006 11:30:22 +0000

On 21 Nov 2006, at 07:58, Ingemar Johansson S ((LU/EAB)) wrote:
...
> recognize non-compliant RTCP, what other problems might arise ?

The packet validation code in Appendix A of RFC 3550 discards non- 
compound RTCP packets. That would mean that old receivers wouldn't  
see non-compound packets, and so would underestimate the RTCP  
bandwidth used, and send faster than they should. Whether that's an  
issue in practice isn't clear.

Colin