Re: Moving forward with SDP control

On 7/18/13 8:52 PM, Roman Shpount wrote:
> On Thu, Jul 18, 2013 at 12:51 AM, Harald Alvestrand
> <harald@alvestrand.no <mailto: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 <mailto: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.

Thanks Roman for this list. But it is still speculation as I understand 
it. We would be much better off knowing what is missing in terms of 
functionality.

I would very much welcome more concrete input on the matter.

> _____________
> Roman Shpount
>

Received on Friday, 19 July 2013 10:39:17 UTC