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

<> Thu, 14 March 2013 02:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A883C11E80A3 for <>; Wed, 13 Mar 2013 19:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.588
X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z0LcLgeqsKQs for <>; Wed, 13 Mar 2013 19:57:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA6B311E809C for <>; Wed, 13 Mar 2013 19:57:42 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2E2vZch007415; Thu, 14 Mar 2013 04:57:35 +0200
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Mar 2013 04:57:35 +0200
Received: from ([]) by ([]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 02:57:34 +0000
Thread-Topic: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop)
Thread-Index: AQHOIFobjnj4CWngkESdJ/Ha868olZikd41g
Date: Thu, 14 Mar 2013 02:57:33 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Mar 2013 02:57:35.0538 (UTC) FILETIME=[AE1C1120:01CE205F]
X-Nokia-AV: Clean
Subject: Re: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle, TURN and Legacy Interop)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Mar 2013 02:57:43 -0000


Ted Hardie wrote:
>On Wed, Mar 13, 2013 at 6:19 PM,  <> 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
>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


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.