W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: Mucking with SDP

From: Tim Panton new <thp@westhawk.co.uk>
Date: Mon, 6 Apr 2015 21:30:39 +0100
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <7F5311CA-91D1-4A56-BDE4-6ADBA5A21708@westhawk.co.uk>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>

> 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.

Received on Monday, 6 April 2015 20:31:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC