Re: RTP payload

There is no issue here. The codecs returned from getCapabilities is a static list including the preferred sending payload ID but is not mandated to be such.

Whatever codec list + payload number you specify to the encoding parameters will be the sending codec you use. As the application developer you can chose whatever you want to send with… it’s a “do as I say” API. You can negotiate these values if you want, or specify then, or use the preferred. It’s entirely up to you. Same goes for the receiving side. Whatever you programmatically specify in the enocoding parameters is the value used. So it’s entirely up to you which side’s preferred payload number you use and how you negotiate and choose.

-- 
Robin Raymond

On September 1, 2014 at 6:57:26 AM, Iñaki Baz Castillo (ibc@aliax.net) wrote:

2014-08-31 16:47 GMT+02:00 Robin Raymond <robin@hookflash.com>:  
> You control exactly what sender/receiver expect for payload numbers (and  
> everything else pretty much). So you can acheive the same behaviour, or  
> change the behaviour. Which means when a shim is written it can be made to  
> behave exactly like SDP O/A. But it need not behave exactly like SDP O/A.  

Sure. But when I create a RTCRtpSender instance and add a track and  
then get the RTCRtpCapabilities.codecs, would them indicate the  
sending RTP payload? or the payload to expect in the incoming RTP  
packets in the same transport?  

IMHO it makes lot of sense that those payload values are the sending  
ones (given that this is not SDP O/A party and thus there is no need  
to negotiate incoming RTP when we send), but in the case of "SDP O/A  
emulation", does it mean that I should "manually" override those  
"payload" values with the remote info once I've initiated my  
RTCRtpSender and received the remote "description"?  





--  
Iñaki Baz Castillo  
<ibc@aliax.net>