- From: Roman Shpount <roman@telurix.com>
- Date: Thu, 18 Jul 2013 14:50:19 -0400
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
- Message-ID: <CAD5OKxvExcuvmsj1zf74U4nVePM6XtwPH+qM8Pfaj3afRtP68Q@mail.gmail.com>
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