Subject: RE: [AVT] Offer/answer questions on RFC 4585

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 2 Oct 2007 14:13:19 +0200

Hi Roni,

>>I have a couple of questions on RFC 4585, regarding the usage with
offer/answer.
>>
>>My FIRST question is: are there any TECHNICAL reasons (I know it's
probably not allowed by RFC 3264) why a user receiving an AVPF offer,
but doesn't 
>>support it, can't reply with AVP answer (instead of rejecting the
stream)? My understanding is that if you offer AVPF you still have to be
able to do 
>>AVP, so...
>>(The receiver of course needs to understand the "AVPF" string in the
SDP)

>[RE:] I think that is this case the offer will include a=rtcp-fb with
rtcp-fb-vals. Since the receiver understands AVPF but do not support any
feedback 
>message it will remove all rtcp-fb-val in the answers.
>To me that looks like support of AVP so why do you want to change the
avpf to avp.

Ok, if it works that way.

So, if I have an MGCF/MGW I can do the following:

- The MGCF answers with AVPF, but without rtcp-fb-val

- The MGCF sends AVP down to the MGW (e.g using H.248)

Regards,

Christer

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

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 7 Oct 2007 11:45:18 +0200

Christer
This is my view. The different between AVP and AVPF is in the RTCP
messages so if the receiver understands the SDP of AVPF nothing bad will
happen.
Roni 

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2007 2:13 PM
> To: [email-masked]
> Subject: RE: [AVT] Offer/answer questions on RFC 4585
> 
> 
> Hi Roni,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Oct 2007 10:06:46 +0200

> messages so if the receiver understands the SDP of AVPF nothing bad will

Hmmm, I would not fully agree with this. I think it will work. However,
there are important difference in the RTCP timing rules between AVPF and
AVP, even when no AVPF feedback messages are used. Thus, the processing
of timing out SSRCs can be affected. But normally there is very little
difference unless feedback messages are sent. I do expect things to
work, unless the AVP receivers are strict about checking the timing
behavior of the other senders (which it really shouldn't do).

So one better test this well with the AVP implementation one is actually
using.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 8 Oct 2007 10:27:42 +0200

Magnus,
Do you see a problem in unicast?
Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, October 08, 2007 10:07 AM
> To: Even, Roni
> Cc: Christer Holmberg; [email-masked]
> Subject: Re: [AVT] Offer/answer questions on RFC 4585
> 
> Even, Roni skrev:
> > Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Oct 2007 10:37:52 +0200

> Do you see a problem in unicast?

Yes, the main problem is how one configures the bandwidth combined with
the need for "trr-int". If one reads Section 5 on compatibilities
between AVP and AVPF there is stressed the need to set "trr-int" to 5
seconds to avoid AVPF users to timeout AVP users. And if "trr-int" is
set to high AVP can timeout AVPF users. Thus removing rtcp-fb completely
may not be the right move, but only leaving trr-int=5 should work as
intended.

Cheers

Magnus Westerlund