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

[Martin Thomson <[e-mail]>]

On 22 November 2013 15:44, Paul Giralt (pgiralt) <[e-mail]> wrote:
> While you’re right that it would work for this scenario, my point was really
> that Offer/Answer is not really asymmetric as implied earlier. Take for
> example the hypothetical case where you are only able to decode VP8 but only
> able to encode H.264. If I offer VP8 as my only codec (because it’s the only
> thing I’m able to decode therefore I never want anyone to send me anything
> other than VP8) I cannot send H.264 in the offer because that implies I’m
> able to decode it. The other side then wants to say it can only receive
> H.264 so it would have to send back an answer with only H.264. I guess
> there’s nothing really inherently stopping you from doing this because as
> far as I can tell, 3264 only says the answer has to be a subset of the offer
> for multicast streams, however how would the answering side know that the
> offering side is even capable to receiving H.264? Perhaps Offer/Answer can
> technically be asymmetric, but it doesn’t seem practical to use it this way
> because you cannot really indicate your send and receive capabilities
> independent of each other.

Judicious application of a=sendonly or a=recvonly avoids this issue.
If you want to send H.264, try a=sendonly on a line with H.264.  If
you want to receive VP8, try a=recvonly on a line with VP8.