Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop)

[<[e-mail]>]

Hi,

Ted Hardie wrote:
>
>On Wed, Mar 13, 2013 at 6:19 PM,  <[e-mail]> wrote:
>> A question related to legacy interop for Bundle. Bundle was originally
>> motivated by RTCWeb, but since RTCWeb uses SDP, it has become a more
>> generic SDP issue. However, does the legacy interop issue concern
>> RTCWeb at all, or is it issue purely for SIP-based devices wanting to apply
>Bundle?
>>
>
>Hi Markus,
>
>The rtcweb charter says "There is a desire to standardize the basis
>for such     communication so that interoperable communication can be
>established  between any compatible browsers. The goal is to enable
>innovation on top of a set of basic components.  One core component is to
>enable real-time media like audio and video, a second is to enable data
>transfer directly between clients."  I believe we have generally read that to
>mean that the focus should be on browser-based clients and interop with
>non-WebRTC endpoints may end up relying on gateways or other
>intermediaries.
>

Agree. 

That's exactly why I'm trying to understand how much the various Bundle-like proposals make pure WebRTC pay for 
a) WebRTC-to-legacy interop 
b) SIP's internal legacy interop issues, by the fact that SIP will also want to use the same bundle mechanism and that imposes restrictions to the commonly used solution

"a)" would be to some extent acceptable although I think gateways can be relied quite heavily in that case to do the job, while "b)" sounds a bit silly. But perhaps that was part of the bargain when SDP was adopted for RTCWeb...

In additon to legacy interop there looms the requirement in general to be able to negotiate non-Bundle in WebRTC (or SIP?) for certain QoS schemes to apply. But that should be the fallback and not the default.

An ideal solution would work without added penalties, and perhaps we can get one. What would definitely help is an entire message-flow, including (trickle-)ICE, that would show that RTCWeb call setup is not in Browser-to-Browser case made slower because of (SIP's?) legacy interop issues. That could answer for instance to Andy Hutton's TURN gathering for all offered m-lines/ports issue. 

Markus