Re: [webrtc-pc] sdpFmtpLine isn't very convenient

>I would expect for a sender, it's exactly the "fmtp" line from the 
remote description, and for a receiver, it's exactly the "fmtp" line 
from the local description.

I think this makes sense. As a result, for a receiver, sdpFmtpLine 
will often represent codec capabilities and for the sender, it will 
represent codec settings.  That is more or less how things worked out 
with the ORTC codec capabilities/settings.

>I thought codecs could only be reordered, not modified. I'll create a
 separate issue for that, since I don't see it mentioned anywhere.

We need to spell out whether it is possible to modify 
codecs[].sdpFmtpLine (and if so, what it means to do so). 

The receiver's sdpFmtpLine can't be modified since there is no 
receiver.setParameters() method and in any case, since the receiver's 
sdpFmtpLine represents capabilities, it doesn't seem like modifying it
 would make sense.

For a sender in ORTC, the equivalent of the codec sdpFmtpLine (e.g. 
the codec parameter settings) can be changed, and it's not clear to me
 that this would violate the prohibition against setting the 
negotiation-needed flag. 

For example, let us say that within the Offer and Answer the Opus fmtp
 line looks like this: 

       a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000;
       maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0

So both the Offerer and Answerer support stereo and FEC, but neither 
wants DTX. 

What if the application decides that it doesn't want to encode stereo 
(e.g. it's a phone call and bandwidth availability is poor)?   Can it 
set the stereo dictionary entry to 0?  What if it wants to use 
external FEC rather than Opus internal FEC?  Can it set useinbandfec 
to 0? 

-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/1022#issuecomment-279547002 
using your GitHub account

Received on Monday, 13 February 2017 22:40:17 UTC