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

Re: Mucking with SDP

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 07 Apr 2015 21:01:17 +0100
Message-ID: <5524378D.5070507@alvestrand.no>
To: public-webrtc@w3.org
On 04/06/2015 09:30 PM, Tim Panton new wrote:
>> 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

That's a bug in current stats implementations, and may point to a bug in
the stats spec.

Can you check if the stats spec gives the information you want?


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


-- 
Surveillance is pervasive. Go Dark.
Received on Tuesday, 7 April 2015 20:01:47 UTC

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