Re: RTP payload

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>

Received on Monday, 1 September 2014 10:57:53 UTC