- From: Tim Panton new <thp@westhawk.co.uk>
- Date: Mon, 6 Apr 2015 21:30:39 +0100
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
> On 6 Apr 2015, at 20:50, Cullen Jennings (fluffy) <fluffy@cisco.com> 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 There was a recent example on the rtcweb of tagging media source so the far end knows which stream was real video and which was screenshare, but that isn’t a case I’ve had. Tim.
Received on Monday, 6 April 2015 20:31:09 UTC