- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 07 Apr 2015 11:52:18 -0400
- To: public-webrtc@w3.org
On 4/6/2015 4:30 PM, Tim Panton new wrote: >>> On Apr 5, 2015, at 4:41 AM, tim panton <thp@westhawk.co.uk> wrote: >>> >>> In some ways this is regrettable - since almost all of my webRTC apps to date have had to mess with the SDP, >>> but I’m still hoping that as we get to 1.0 the need for this will be reduced. >> I know some of the mucking is to work around bugs in browsers that are getting fixed but I was wondering if you could send a list of SDP mucking around that you see apps needing to do so that we can eliminate any that should be eliminated. >> >> I think a full list would be very helpful. Thanks. > I’m not sure this is a full list - I often need to look at the SDP to work out what is going wrong, > but leaving that and (in)compatibility work arounds aside, here are some things I’ve needed to access > the sdp to do: > > 1) Set the b=AS and ptime to suit ‘app specific’ network situations (e.g. a TV whitespace link with pathological behaviour at 20ms) > 2) Fish out the DTLS fingerprint (for reasons I’ll not discuss on this list) > 3) Pull out the a=ssrc lines to to be able to associate a set of stats with a media type So as best I can tell, 2 of the 3 here are to get data out of the SDP; only one involved modification. Would providing appropriate attributes on the RTPSenders cover the b=AS and ptime issues? Any suggestions as to an appropriate API point to handle the other issues? -- Randell Jesup -- rjesup a t mozilla d o t com
Received on Tuesday, 7 April 2015 15:53:18 UTC