W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Moving forward with SDP control

From: Roman Shpount <roman@telurix.com>
Date: Thu, 18 Jul 2013 14:50:19 -0400
Message-ID: <CAD5OKxvExcuvmsj1zf74U4nVePM6XtwPH+qM8Pfaj3afRtP68Q@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
On Thu, Jul 18, 2013 at 12:51 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 07/17/2013 07:00 PM, Roman Shpount wrote:
> On Wed, Jul 17, 2013 at 5:52 AM, Harald Alvestrand <harald@alvestrand.no>wrote:
>> That was the original rationale for exposing the SDP, actually; people
>> with exotic needs could get satisfaction without complexifying the API
>> interface, but in return, they had to do SDP munging.
>  I do not think that the interface of the application with outside world
> and its support of exotic features is the issue. The issue are exotic and
> any new features implemented and exposed by the browser.
> Roman, using "the issue" might be one of the issues that's confusing us.
> Are you talking about what you see as the major issue when running the
> same application in two browsers, and having them talk to each other?
You said "people with exotic needs" and that is underspecified as well. The
"issue" I was referring to was the reason people need to modify SDP to
address their "exotic needs". There are three distinct possibilities:

1. People who need interface with external systems which need something
specific or exotic in SDP. Since typically those external systems under
control of the application developers, they should know how to produce
whatever SDP format is needed to interface them. These people will continue
to mangle no matter what we do and we should let them.

2. People who need to implement "exotic" call setup scenarios. This is very
difficult if not impossible now due to the offer/answer state machine. You
can build another call setup scenario and fool the webrtc offer/answer
state machine by generating SDP, but this is so fragile it is not practical.

3. People who need to interface some "exotic", new, or underexposed
features in the browser. This from my point of view is the main reason why
people do SDP mangling. The main difficulty with doing this is that SDP,
features exposed in SDP, and how these features are affected by SDP
mangling is grossly underdefined. Unless they can be defined in such a way
that you can produce a predictable SDP and predictable results by SDP
mangling, we will need to interop test each web application with each
browser and each browser version. Having the same application experience
across different versions of Firefox and Chrome  is very difficult at the
current WebRTC state. I am afraid it will be impossible with more browsers,
more features supported, and more complex applications.
Roman Shpount
Received on Thursday, 18 July 2013 18:50:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC