Re: [rtcweb] Offer/answer for heterogeneous encode/decode

Hi,

Like some others, I think the must-decode-both-must-endcode-one alternative as such sounds interesting (whether it has any impact on the licence/IPR issues I'll leave to others to speak for).

However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only able to receive/decode it.

As Justin said, for the "base case" we could probably make it work, as we would know than an rtcweb endpoint must be able to send/encode one of the codecs.

But, what when we add more codecs? Assume Alice sends an offer with H264, VP8 and the new fancy codec X. Bob supports codec X, but he has no clue whether Alice can actually encode it. So, in addition to X Bob will also have to include, and reservce resources for,  H264 and VP8 in the answer - just in case. And, when Alice receives the answer, she can not send a new offer and remove H264 and VP8, because she doesn't know whether Bob can encode X. It will not be possible to negotiate down to a single common codec X - even if both Alice and Bob are able to both encode and decode X.

...and, a legacy answerer which supports X may include only X in the answer, which means Alice has to send a new Offer, without X, in case she can only decode it.

Also, in case there is a gateway/transcoder, even if both endpoints indicate support of the same codec(s), it may still have to insert a transcoder, just in case - as it doesn't know which codecs the endpoints are able to encode.

So, I would STRONLGY RECOMMEND AGAINST allowing to indicate sendrecv for decode-only codecs. I think it would backfire very soon.

Usage of unidirectional, sendonly/recvonly, m- line would of course solve this, and you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

Another alternative is to perform some kind of capability exchange before the actual offer is sent. But, that would of course increase the number of messages etc.

Regards,

Christer

________________________________
From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson [martin.thomson@gmail.com]
Sent: Saturday, 23 November 2013 3:03 AM
To: Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:
> I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream

The bidirectional thing in O/A is the strange way to do things.  Two
lines is pretty intuitive.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb