Subject: [MMUSIC] SRTP payload mapping

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 9 Nov 2006 16:20:16 -0500

Hi Magnus,

During my presentation for best-effort SRTP you said something I did not
understand.  I think you said that even if I offer payload type X, that the
other side may legitimately send me RTP with payload type Y.  Is that
true???  That seems bizarre to me, and I can't find that anywhere, but
obviously that will break payload mapping.  How would I know what to do with
such RTP when I receive it and I didn't offer it?

-hadriel

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 09 Nov 2006 13:43:35 -0800

Hadriel Kaplan skrev:
> Hi Magnus,
> 
> During my presentation for best-effort SRTP you said something I did not understand.  I think you said that even if I offer payload type X, that the other side may legitimately send me RTP with payload type Y.  Is that true???  That seems bizarre to me, and I can't find that anywhere, but obviously that will break payload mapping.  How would I know what to do with such RTP when I receive it and I didn't offer it?

I don't think so, at least not intended it. You should only receive 
payload types part of your offer.

My points against this solution was:

1. It doesn't resolve the issue for RTCP/SRTCP.

2. It consumes the double amount of payload format. We already have a 
few mechanism that does similar things. Combined with RTCP MUX consuming 
1/4th of the total space for safety reasons the number of available 
payloads are very much reduced.

3. The issue does come from that SRTP and the other profiles, FEC below 
RTP etc all assumed when being developed to have a signalling mechanism 
that will put it in place the right mechanisms before using them. So 
what we are trying to accomplish is really to retro fit a quite 
difficult requirement onto these solutions. I don't find this solution 
particular good. However I currently don't have a good proposal.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 9 Nov 2006 17:25:39 -0500

Oh, sorry, comments below...

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, November 09, 2006 4:44 PM
> 

Yeah, that has to be decided: ignore it, payload-map them, or define a
standard/reserved PT for SR/RR of SRTCP.
 
> payloads are very much reduced.

Yup.  There's no free lunch.  Personally I don't think rtcp-mux needs to be
so conservative.  Since many of the RFC's are written as if everyone
conforms to previous RFCs, and the argument against trying to be more clever
is usually "we can't be concerned with broken implementations", I don't
think we need to be worried about it for RTCP either.

> particular good. However I currently don't have a good proposal.

Are you referring to the payload-mapping piece, or the general idea of
best-effort offers?  Payload-mapping is not the best way, and one could have
an entire alternate m= line with those unique payload types, but then all
the rtpmaps and such need to be repeated.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Thu, 16 Nov 2006 21:00:31 -0500

>think we need to be worried about it for RTCP either.

Not to be argumentative here - but everytime I hear that my stomach
goes queasy.  "We" may not be concerned with broken implementations - but
"I" and an awful lot of other implementors DO need to deal with broken
implementations that there is NO chance will be fixed in the short or
medium term (say 5 years or perhaps more).  And these are implementations
that can't be avoided.  Not to mention trying to negotiate calls with
current-day ATAs.  Note: I'm not talking about negotiating with a UA that
*does* try to implement best-effort SRTP/etc, I'm talking about negotiating
with existing implementations.

>the rtpmaps and such need to be repeated.

And second/third/fourth m= line for alternate profiles has ALL sorts of
problems for current implementations.  Not to mention totally blowing any
chance of using UDP.  Etc, etc -- #include <std/profile-negotiation-issues.h>

-- 
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)

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 17 Nov 2006 00:05:48 -0500

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Thursday, November 16, 2006 9:01 PM
> >

Oh I agree with you in general, but there's gotta be some (fine) line to be
drawn, and on the rtcp packet type reserving I think expecting an SR/RR is
reasonable.  The rtcp-mux draft could even just say "If you do this muxing
thing then you must use SR or RR as the first RTCP packet type of a
compound, as per the RFC blah blah..."  I mean both sides have to agree to
do rtcp-mux, so why not just say it? 

Although at the end of the day we're only talking about saving 9 numbers
(?), so it's no biggie to me either way.  Just thinking a stitch, in time,
saves 9.  :)

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Fri, 17 Nov 2006 22:22:07 -0500

>do rtcp-mux, so why not just say it? 

I'm ok with it assuming RR/SR at the start of an RTCP.  That wasn't the
point I thought was being discussed, and it's not a common bug (though I
imagine it occurs - if it is even somewhat common, I'd re-assess).  The
thing that worried me the most was the idea of assuming in an RFC that
implementors conform to all (or even most) previous RFCs.

I just want people to remember that if a new RFC is to get implemented
widely, it has to be able to work with "enough" existing implementations
that predate it, and each of those implementation will have implemented
some (generally small) subset of the existing RFCs, and each will have
many minor bugs and some major bugs.

"Be conservative in what you send, and liberal in what you receive."  :-)

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 20 Nov 2006 07:56:02 +0100

Hi

During the thursday AVT session in San Diego I presented the problems
that large RTCP packets can cause in higly VoIP optimimized radio
bearers such as those being speacified in 3GPP, a problem that initially
led to the proposal of using inband signaling in the RTP flow for
adaptation purposes in a VoIP service. 

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. 
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. 

Ingemar

> Sent: den 18 november 2006 04:22
> To: Hadriel Kaplan
> Cc: Magnus Westerlund (KI/EAB); [email-masked]
> Subject: Re: [MMUSIC] RE: SRTP payload mapping
> 
> >Oh I agree with you in general, but there's gotta be some 
> (fine) line 
> >to be drawn, and on the rtcp packet type reserving I think 
> expecting an 
> >SR/RR is reasonable.  The rtcp-mux draft could even just say 
> "If you do 
> >this muxing thing then you must use SR or RR as the first 
> RTCP packet 
> >type of a compound, as per the RFC blah blah..."  I mean both sides 
> >have to agree to do rtcp-mux, so why not just say it?
> 
> I'm ok with it assuming RR/SR at the start of an RTCP.  That 
> wasn't the point I thought was being discussed, and it's not 
> a common bug (though I imagine it occurs - if it is even 
> somewhat common, I'd re-assess).  The thing that worried me 
> the most was the idea of assuming in an RFC that implementors 
> conform to all (or even most) previous RFCs.
> 
> I just want people to remember that if a new RFC is to get 
> implemented widely, it has to be able to work with "enough" 
> existing implementations that predate it, and each of those 
> implementation will have implemented some (generally small) 
> subset of the existing RFCs, and each will have many minor 
> bugs and some major bugs.
> 
> 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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 Nov 2006 12:21:42 +0000

> feedback RTCP packets with a minimum size and thus abandon the  

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.

> 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.

Colin

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 20 Nov 2006 13:35:14 +0100

Hi

My intention is not to kick out the compound RTCP packets, they are
useful for the purposes described below. 
Rather I would like to see the rules relaxed so that is possible to
transmit critical feedback messages with RTCP without the need to
transmit them in compound RTCP. In other words both compound RTCP and
non compound RTCP will be transmitted and it will be possible to achieve
both the features that RTCP is originally intended for aswell as timely
and more robust feedback especially in radio environments with degraded
radio conditions.

Ingemar

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: den 20 november 2006 13:22
> To: Ingemar Johansson S (LU/EAB)
> Cc: Hadriel Kaplan; Magnus Westerlund (KI/EAB); [email-masked]
> > bearers such as those being speacified in 3GPP, a problem that 
> > initially led to the proposal of using inband signaling in the RTP 
> > flow for adaptation purposes in a VoIP service.
> >
> > 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.
> 
> > 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 
> 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.
> 
> Colin
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 Nov 2006 13:26:02 +0000

> and more robust feedback especially in radio environments with  

I suggest you raise the issue on the AVT list; MMUSIC cannot work on  
RTCP.

Colin

---

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 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).

>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.