Re: senders vs receivers codec selection

Perhaps we should cite the RTP Usage draft as a normative dependency.  Reading the current Editor's draft, we could also be more clear about the meaning of multiple encodings for receivers and senders. For example, on a receiver, simulcast typically implies receiving one of multiple streams, whereas with SVC multiple streams are received. On a sender, simulcast and SVC both imply sending multiple streams.

On May 11, 2014, at 9:11 PM, "Roman Shpount" <rshpount@turbobridge.com<mailto:rshpount@turbobridge.com>> wrote:

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<mailto: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


<compose-unknown-contact.jpg>
Bernard Aboba<mailto: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.

<postbox-contact.jpg>
Robin Raymond<mailto: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