- 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