Re: senders vs receivers codec selection

One thing I like to mention is that we do need an ability to receive
multiple codecs and switch between them based on the payload type to be
interoperable with current VoIP. To interop with current WebRTC we need to
support ability to switch between OPUS, RFC 4733 tones and comfort noise
based on the payload type. I am also familiar with quite a few system which
switch the transmitting audio codec without any signaling notification to
the remote side, such as international VoIP carriers that switch between
G.729 and G.711 within the same call with no signaling.

_____________
Roman Shpount


On Sun, May 11, 2014 at 8:24 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> Currently the receiver has a payload type for each codec. This
> configuration allows the receiver can receiver with any codec on the same
> SSRC and allow auto-switching between them. This ability is true so long as
> the codec is not SVC enabled because the layering information was defined
> within the context of the receiver object itself and not within the context
> of receiver's codec.
>
> If the receiver object is only supposed to work with a particular codec
> only then why are we supplying the receiver object with a set of codecs and
> payload type for each codec? So to me, that suggests the receiver object
> CAN switch between codecs. If does allow this behaviour then why doesn't it
> then work too for SVC codecs but only non SVC codecs?
>
> To me this implies we should do one of the following:
> 1) make the sender / receiver only have one codec and that's it. Want to
> receive or send with a different codec? Use a different sender / receiver
> object. -OR-
> 2) make the sender / receiver work for all codecs equally by defining the
> layering within the context of the SVC codec and not within the context of
> the receiver
>
> I'm completely fine with either scenario "1" or "2" but I don't like the
> way it kind-of half works now. "2" is more work for ORTC implementors but
> it allows for easier management of the receiving streams for an application
> developer.
>
> -Robin
>
>
>   Bernard Aboba <Bernard.Aboba@microsoft.com>
>  May 11, 2014 at 8:10 PM
> I have been assuming that a receiver always needs to specify the
> payloadType (e.g. It cannot be missing or null), even if there is an SSRC
> specified.
>
>   Robin Raymond <robin@hookflash.com>
>  May 11, 2014 at 10:41 AM
>
> My understanding was this:
> A RTCRtpSender picks a single codec for sending but a receiver can receive
> on any of the defined RTCRtpCodecs.
>
> Here's a few questions:
> a) If a sender wants to change sending codecs, do they setup a new sender
> object?
>
> b) If a receiver latches onto a stream with a particular payload type, is
> that latch permanent (i.e. if sender changes sending codecs, does a new
> receiver need to be setup to receive a payload type even on the same SSRC)?
>
>
> As things are defined now, the sender must pick a sending codec. The
> receiver does not have enough information to receive upon any codec because
> the layering information only works for one codec's scenario (despite
> having a list of codecs available) thus the receiver can only receive upon
> one payload type.
>
> -or-
>
> The receiver can only work on one codec if using SVC, but can switch
> between codecs if the other codecs are not configured using SVC (since only
> one SVC scenario can be setup).
>
>
> Therefor, it's doesn't appear to be currently possible for the receiver to
> configure a bunch of SVC codecs and then the sender pick which one to use,
> even though the receiver can configure a bunch of non-SVC codecs and can
> have the sender pick which one to use.
>
>
> I want to confirm my understanding is correct (and if others agree that
> this should be correct).
>
> -Robin
>
>