Subject: [rtcweb] AVPF vs AVP

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Sep 2011 17:08:55 +0200

Hi,

There has been this long thread with the subject partially containing
"AVPF". I want to clarify something in this context around AVPF. Rather
than the SRTP question.

An end-point that is AVPF compliant is in fact interoperable with an AVP
one as long as the trr-int parameter is set reasonably large. A
parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that
they are in fact compatible. This avoids the risk of any side timing out
the other if the AVP side is using the default 5 s minimum interval.

Based on this one could in fact have the RTCWEB nodes always use AVPF
for RTP/RTCP Behavior. The AVPF feedback messages are explicitly
negotiated and will only be used when agreed on.

This leaves us with any signaling incompatibilities when talking to a
legacy device. If one don't want to use cap-neg I see two directions to go:

1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling
gateway to legacy will change that by removing the F to AVP or SAVP.

2) RTCWEB end-point will always use AVPF but signal it as AVP. It will
detect the AVPF capabilities of the other end-point based on the
signaling of the feedback events intended to be used.

I think 1) is cleaner for the future. 2) might be more pragmatic.

In both cases I believe there are methods for negotiating a lower
trr-int than some AVP fallback value to preserve interoperability.

However, this still don't resolve the question if the "S" should be in
front of the RTP profile indicator or not. But it might help by removing
the F or not in the profile.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Randell Jesup <[email-masked]>
Date: Wed, 14 Sep 2011 10:10:11 -0700

> I think 1) is cleaner for the future. 2) might be more pragmatic.

I think this is something we should consider; I'll note that WorldGate 
has been using option 2 for the last 7 or so years with no problems.

-- 
Randell Jesup
[email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 14 Sep 2011 12:21:42 -0700

Option 2 is what is documented as the best practice for interoperability
purposes within the IMTC as well.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Randell Jesup
> Sent: Wednesday, September 14, 2011 10:10 AM
> To: [email-masked]
> Subject: Re: [rtcweb] AVPF vs AVP
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Sep 2011 21:32:37 +0200

> I think 1) is cleaner for the future. 2) might be more pragmatic.
If 2) is more pragmatic, the IETF should update the definition of AVP to 
allow use of AVPF functionality.
The responses seem to indicate that in practice, this is already being 
done (and this is a clear indication that the concept of "profile" in 
RTP has failed to achieve its purpose).

*shudder*

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Sep 2011 14:54:50 -0500

Here's a vote for Option 2.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Sep 2011 03:21:46 +0000

I am shocked, Shocked!, to see you suggest that we disregard RFC 4585 and SDP rules, when we have an IETF specified means of indicating multiple profile support using RFC 5939 SDP Capability Negotiation.
;)

-hadriel

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Sep 2011 14:05:46 +0200

> allow use of AVPF functionality.

No, Harald that I think is a bad idea. The core of AVPF is the timing
rule. From my perspective the important aspect is that one do implement
the timing rules. Thus it is important we have the label of AVPF to
indicate these rules.

Thus my proposal is really to say that an RTCWEB end-point SHALL
implement and always use the AVPF timing rules. It might send feedback
messages if those have been negotiated with a=rtcp-fb attribute.

> RTP has failed to achieve its purpose).

It works fine on the RTP level. But the signalling aspects has clearly
been botched.

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Sep 2011 14:09:42 +0200

On 2011-09-15 05:21, Hadriel Kaplan wrote:
> 
> I am shocked, Shocked!, to see you suggest that we disregard RFC 4585
> and SDP rules, when we have an IETF specified means of indicating
> multiple profile support using RFC 5939 SDP Capability Negotiation. 
> ;)

Yes, sometimes I do surprise myself ;-). But, I am not really arguing
for disregarding RFC 4585. I definintely want all the functions of the
AVPF spec. But it is clear that the "RTP/AVPF" on m= lines is the issue
that people have.

But on a serious note. If all the energy spent discussing CAPNEG had
instead been put into implementing it. It would be universally deployed
by now.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Sep 2011 14:18:21 +0200

> the timing rules. Thus it is important we have the label of AVPF to
But how do you "have" the label if you signal it as AVP??????
Is it a label that occurs in the spec only, and is undetectable on the wire?
That's the place where you lost me.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 15 Sep 2011 17:01:44 +0300

Magnus,
I noticed that you claim that all AVPF feedback messages are explicitly
negotiated, is this a requirement. At least RTCP-SR-REQ is not negotiated in
SDP.

As for using AVPF while signaling AVP that will confuse endpoint that so not
understand this convention and can support AVPF. They will see an offer with
AVP but with parameters that are not part of AVP. They can respond with AVP
without the AVPF parameter and behave like AVP endpoints even though they
support AVPF. This will prevent them from sending AVPF feedback messages.
This may be a problem for what you call "legacy" video conferencing
endpoint. (I do not like the term legacy here since these are not legacy
endpoint but AVP/AVPF compliant EPs 

I think that if we are not going to use cap-neg we should make it
historical. 

Roni Even

> Behalf Of Magnus Westerlund
> Sent: Wednesday, September 14, 2011 6:09 PM
> To: [email-masked]
> Subject: [rtcweb] AVPF vs AVP
> 
> Hi,
>

---

From: "Roni Even" <[email-masked]>
Date: Thu, 15 Sep 2011 17:06:21 +0300

Hi,
RFC4585 talks about coexistence of AVP and AVPF systems in a multicast group
in section 5. Example 3 in section 4.4 of RFC 4585 talks about signaling but
claims to be incomplete and suggests using grouping for the alternatives
offers. The MMUSIC group did cap-neg for the alternatives.

Roni Even

> Behalf Of Harald Alvestrand
> Sent: Wednesday, September 14, 2011 10:33 PM
> To: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Sep 2011 18:06:01 +0200

> negotiated, is this a requirement. At least RTCP-SR-REQ is not negotiated in

You are correct, had not actually noticed that. Fortunately that isn't
an real issue.

First of all the support of AVPF can still be negotiated with the
a=rtcp-fb. Simply the trr-int configuration lets both side show support
of AVPF.

Secondly, for the RTCP-SR-REQ if one uses the header extension to
deliver the synch data then that is explicitly indicated. And if you
ignore or don't understand the request then you simple fall back to
normal synchronization procedures with more delay before completing it.

> support AVPF. This will prevent them from sending AVPF feedback messages.

They can still use AVPF timing rules, even if the other end-point is AVP
only. They only need to restrict themselves from sending feedback messages.

> endpoint but AVP/AVPF compliant EPs 

Yes, I agree it is not without issues in that regard.

I would also like to note that if you require AVPF and don't think
talking to AVP only end-points then one really should include the AVPF
in the m= line to prevent fallback.

> I think that if we are not going to use cap-neg we should make it

I kind of agree with that also. But if it constantly fails in the market
I think we have to recognize that and do something else that works better.

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2011 07:34:18 +0200

Hi Roni, 

>As for using AVPF while signaling AVP that will confuse 
>endpoint that so not understand this convention and can 
>support AVPF. They will see an offer with AVP but with 
>parameters that are not part of AVP. They can respond with 
>AVP without the AVPF parameter and behave like AVP endpoints 
>even though they support AVPF. This will prevent them from 
>sending AVPF feedback messages.
>
>This may be a problem for what you call "legacy" video 
>conferencing endpoint. (I do not like the term legacy here 
>since these are not legacy endpoint but AVP/AVPF compliant EPs 

Do those devices support CapNeg?

Regards,

Christer

> > "AVPF". I want to clarify something in this context around AVPF. 
> > Rather than the SRTP question.
> > 
> > An end-point that is AVPF compliant is in fact 
> interoperable with an 
> > AVP one as long as the trr-int parameter is set reasonably large. A 
> > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure 
> > that they are in fact compatible. This avoids the risk of any side 
> > timing out the other if the AVP side is using the default 5 
> s minimum 
> > interval.
> > 
> > legacy device. If one don't want to use cap-neg I see two 
> directions 
> > to
> > go:
> > 
> > front of the RTP profile indicator or not. But it might help by 
> > removing the F or not in the profile.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> >

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Sep 2011 08:43:31 +0300

Magnus,
I can agree that if you are doing video call you must send AVPF regardless
if you are talking with this type of systems that you call "not legacy" or
systems that you call "legacy". This must be a MUST in the text otherwise
the so called "legacy" end point will think it is AVP and will not send
feedback messages which will break video conferencing applications. 

Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, September 15, 2011 7:06 PM
> To: Roni Even
> Cc: [email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Sep 2011 08:49:00 +0300

Christer,
This is not the issue, since the capneg talks about how to address the
systems that do not support it.
In the current proposal it will work as long as it will have a distinction
when to send AVP or AVPF and for video calls it must say that you MUST send
AVPF regardless of what is the system on the other side otherwise it will
fail to achieve a reasonable video call.
What I object is to always sending AVP with AVPF information. This usage
should be based on the type of media that is being used (video MUST always
use AVPF!!!!)
Roni

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, September 16, 2011 8:34 AM
> To: Roni Even; Magnus Westerlund; [email-masked]
> Subject: RE: [rtcweb] AVPF vs AVP
> 
> 
> Hi Roni,
> 
> > =

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2011 07:50:31 +0200

Hi, 

>I can agree that if you are doing video call you must send 
>AVPF regardless if you are talking with this type of systems 
>that you call "not legacy" or systems that you call "legacy". 
>This must be a MUST in the text otherwise the so called 
>"legacy" end point will think it is AVP and will not send 

If the video conf app *requires* AVPF, you should include AVPF in the m= line.

The AVP+a=rtcp-fb proposal is an alternative to CapNeg, where there is "built-in" fallback to AVP in case the answerer does not support AVPF.

And, IF we choose to go forward with this proposal, it should also be adopted by CLUE.

Regards,

Christer

> > a=rtcp-fb. Simply the trr-int configuration lets both side show 
> > support of AVPF.
> > 
> > > As for using AVPF while signaling AVP that will confuse endpoint 
> > > that
> > so not
> > > without the AVPF parameter and behave like AVP endpoints 
> even though
> > they
> > They can still use AVPF timing rules, even if the other 
> end-point is 
> > AVP only. They only need to restrict themselves from 
> sending feedback 
> > messages.
> > 
> conferencing 
> > I kind of agree with that also. But if it constantly fails in the 
> > market I think we have to recognize that and do something else that 
> > works better.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2011 07:53:49 +0200

Hi, 

>This is not the issue, since the capneg talks about how to 
>address the systems that do not support it.

I think it is. Because, if they don't support CapNeg, they will still end up using AVP - even if they support AVPF - because that is the only thing they will understand in the offer.

>In the current proposal it will work as long as it will have 
>a distinction when to send AVP or AVPF and for video calls it 
>must say that you MUST send AVPF regardless of what is the 
>system on the other side otherwise it will fail to achieve a 
>reasonable video call.
>What I object is to always sending AVP with AVPF information. 
>This usage should be based on the type of media that is being 
>used (video MUST always use AVPF!!!!) Roni

I don't anyone has suggested that you are not allowed to mandate AVPF for video. You can do that by including AVPF in the video m= line.

Regards,

Christer

> endpoint that 
> > >so not understand this convention and can support AVPF. 
> They will see 
> > >an offer with AVP but with parameters that are not part of 
> AVP. They 
> > >can respond with AVP without the AVPF parameter and behave 
> like AVP 
> > >endpoints even though they support AVPF. This will prevent 
> them from 
> > >endpoint. (I do not like the term legacy here since these are not 
> > >legacy endpoint but AVP/AVPF compliant EPs
> > 
> > > > AVP one as long as the trr-int parameter is set 
> reasonably large. 
> > > > A parameter value of 1.5-5 seconds (I would recommend 3s) will 
> > > > ensure that they are in fact compatible. This avoids 
> the risk of 
> > > > any side timing out the other if the AVP side is using 
> the default 
> > > > 5
> > > s minimum
> > > > interval.
> > > >
> --------------------------------------------------------------------
> > > -
> > -
> --------------------------------------------------------------------
> > > -
> > -
> --------------------------------------------------------------------
> > > -
> > -
> > > >

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Sep 2011 09:20:15 +0300

Christer,
You can start with avpf asin the offer in capneg and not AVP depending on
the media type. Typically for audio you will have avp and video avpf

As for the current proposal what  I said is that if you are offering video I
think that the text should mandate offering AVPF if and not AVP with the
AVPF parameters. Otherwise it will break with what is called "legacy" that
support AVPF and the important feedback messages like (FIR, PLI, TMBBR,
etc.) will not be sent form the "legacy" answerer and may be ignored when
received from by the answerer since the offer was for AVP.
Roni

> Sent: Friday, September 16, 2011 8:54 AM
> I think it is. Because, if they don't support CapNeg, they will still
> end up using AVP - even if they support AVPF - because that is the only
> thing they will understand in the offer.
> 
> I don't anyone has suggested that you are not allowed to mandate AVPF
> for video. You can do that by including AVPF in the video m= line.
> 
> Regards,
> 
> Christer
> 
> 
> 
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Sep 2011 09:25:39 +0300

Hi Christer,
Again, the word is MUST for video. I think that systems that will interwork
with RTCWEB systems will support AVPF since they will need to support
current video codecs. I do not see RTCWEB systems interwork with systems
that support only H.261 or even H.263, so I assume that the interworking
will be with systems that also use AVPF for video.

As for CLUE, we can discuss it in CLUE if relevant at all. It may be
relevant only for the video capture that should be used for interworking
with non CLUE systems.
 
Roni

> Sent: Friday, September 16, 2011 8:51 AM
> To: Roni Even; Magnus Westerlund
> Cc: [email-masked]
> The AVP+a=rtcp-fb proposal is an alternative to CapNeg, where there is
> "built-in" fallback to AVP in case the answerer does not support AVPF.
> 
> > > > AVP but with parameters that are not part of AVP. They can
> respond
> > > with AVP

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2011 08:29:47 +0200

Hi, 

>Again, the word is MUST for video. I think that systems that 
>will interwork with RTCWEB systems will support AVPF since 
>they will need to support current video codecs. I do not see 
>RTCWEB systems interwork with systems that support only H.261 
>or even H.263, so I assume that the interworking will be with 
>systems that also use AVPF for video.
>  
>As for CLUE, we can discuss it in CLUE if relevant at all. It 
>may be relevant only for the video capture that should be 
>used for interworking with non CLUE systems.

Correct. 

Again, if we *mandate* the anyone involved in a session (CLUE session or something else) supports AVPF, we can use AVPF in the m= line.

Regards,

Christer

> > >I can agree that if you are doing video call you must send AVPF 
> > >regardless if you are talking with this type of systems 
> that you call 
> > >"not legacy" or systems that you call "legacy".
> "legacy" end 
> > >point will think it is AVP and will not send feedback 
> messages which 
> > >will break video conferencing applications.
> > 
> > If the video conf app *requires* AVPF, you should include 
> AVPF in the 
> > m= line.
> > 
> > And, IF we choose to go forward with this proposal, it 
> should also be 
> > adopted by CLUE.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > > > ignore or don't understand the request then you simple 
> fall back 
> > > > to normal synchronization procedures with more delay before
> > > completing it.
> > > >
> > > > >
> > > > > understand this convention and can support AVPF. They 
> will see 
> > > > > an
> > > > offer with
> > > > > support AVPF. This will prevent them from sending 
> AVPF feedback
> > > > messages.
> > > >
> > > > > I think that if we are not going to use cap-neg we 
> should make 
> > > > > it historical.
> > > >
> > > > market I think we have to recognize that and do something else 
> > > > that works better.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > >

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Sep 2011 16:03:34 +0300

Magnus,
Maybe we can take the approach from
draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same m-line
with the same port number twice, one as AVP and one as AVPF and let the
other side chose, he can answer with a port=0 for the profile it does not
want. If the multiplex proposal has backward interoperability than this
proposal also does.

Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 15:32:16 +0200

> want. If the multiplex proposal has backward interoperability than this

An idea with potential I would say. I have to think if it has any
issues. We may still have missed some aspect when it comes to Christer's
draft which breaks it.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 16 Sep 2011 16:13:40 +0200

> want. If the multiplex proposal has backward interoperability than this
The backwards compatibility case for this one (grouping type = PICKONE?) 
would be that the responder establishes two RTP sessions, one with AVP 
and one with AVPF. Presumably, one has to do a second SDP O/A to get rid 
of the one the initiator doesn't want, and hope that the responder 
hasn't started using that one for media.

In draft-holmberg, the backwards compatibility case is that the 
responder establishes two RTP sessions, and both are used - each for one 
media type. No second pass is needed (as far as I can tell from current 
discussion).

A lot of things become simpler if 2-pass SDP O/A is an acceptable 
mechanism - first send a very rich offer in order to figure out what the 
other side is willing to do, then a very lean offer with only the 
mechanisms one prefers and knows that the responder is capable of 
supporting.
But is this an acceptable strategy? It has costs both in time-to-setup 
and possibly a quite confusing intermediate state of the SDP session.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Sep 2011 18:06:10 +0000

> want. If the multiplex proposal has backward interoperability than this

You can't do that.  Not only is it not kosher in the sense that you're really offering two media sessions, rather than alternatives for one, but it actually won't work in practice: if the SDP offer crosses an SBC or App-Server B2BUA, some of them will treat them as two media sessions and thus offer 2 different port numbers on their UAC side and make it no longer distinguishable from a normal offer of two media sessions.
(and I've tested this on an SBC)

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Sep 2011 09:26:35 +0200

Hi,

I agree with Hadriel and Harald.

Also, even if there is no SBC, a UAS that doesn't support MULTIPLEX would see an offer of two different streams, and if it accepts both a second o/a would be needed anyway.

And, as Harald said, the backward compability is for entities that do not support multiplexing.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 16. syyskuuta 2011 21:06
> To: Roni Even
> Cc: <[email-masked]>
> > draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same 
> > m-line with the same port number twice, one as AVP and one 
> as AVPF and 
> > let the other side chose, he can answer with a port=0 for 
> the profile 
> > it does not want. If the multiplex proposal has backward 
> > interoperability than this proposal also does.
> 
> You can't do that.  Not only is it not kosher in the sense 
> that you're really offering two media sessions, rather than 
> alternatives for one, but it actually won't work in practice: 
> if the SDP offer crosses an SBC or App-Server B2BUA, some of 
> them will treat them as two media sessions and thus offer 2 
> different port numbers on their UAC side and make it no 
> longer distinguishable from a normal offer of two media sessions.