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

Paul Kyzivat <> Thu, 14 March 2013 03:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 745A621F8C4F for <>; Wed, 13 Mar 2013 20:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.18
X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lsRpdWu0qCoC for <>; Wed, 13 Mar 2013 20:56:57 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:96]) by (Postfix) with ESMTP id AE84121F8C3B for <>; Wed, 13 Mar 2013 20:56:57 -0700 (PDT)
Received: from ([]) by with comcast id BFUk1l0020x6nqcA9FwxVr; Thu, 14 Mar 2013 03:56:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:2006:56e9:cf8b:4ea7]) by with comcast id BFww1l00U2CH3Z58YFwxRX; Thu, 14 Mar 2013 03:56:57 +0000
Message-ID: <>
Date: Thu, 14 Mar 2013 11:56:56 +0800
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1363233417; bh=bJC3/P8h0j+LaSCUhgHT1aXN35tqXE+8J5pUoVGROhk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZSG2hLnFTt/Ak4TPz86TXUMtsFe9Khuup7u2k9zANBK0vVDD3dCpw7R62RXpBDQMw kaOt46UeSX1r86VozYrdKUAUUU2iPxfQijoMZZUwCEfiX/0CVBCUxQncqbOJB+tfwm BHmrGrQxvouf7gY/sMD6FGUwlIao7bktivML+IovBufMEYRutW3n/l0eA+Vi3M1iPh YF67KFDUW6HakuiAJlM3U/0YZcLKt9vFrZPeY9kVSz0iYxnNy4ThZLKlI1mR+7NkLa Of7MDfrWp7D0JbstOq+uO/j13KwKm9HIglMbQf7l6W1FyuaxDPEr0blrhh/t2HLPb8 KGjxYWd4vZWZw==
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 03:56:58 -0000

On 3/14/13 6:19 AM, wrote:
> Hi,
> 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?
> As far as I understand it, RTCWeb to Legacy interop can be accommodated
> by a gateway that on one side supports all the bells and whistles of
> RTCWeb such as Bundle and trickle-ICE, and to the other side uses
> existing offer/answer procedures without ICE or Bundle. Right? Or is
> there a particular reason why a WebRTC implementation should assume the
> other end (from its perspective) won’t do Bundle?

IMO there is an (at least implicit) goal that a sufficiently functional 
sip device be able to interoperate with an RTCWEB-based device without a 
media gateway.

That doesn't mean all sip devices. E.g. support of DTLS/SRTP will be 
required. But a device that wants to make this possible should be able 
to. This could be important for media-intensive applications.

Also, the limitations that RTCWEB has discovered, that lead to these 
proposals, are also limitations for classes of non-RTCWEB devices and 
applications. It would be unpleasant and unfortunate to make one set of 
extensions for RTCWEB, and then have to do a different set for other 

> I’ve seen some drafts claiming that Bundle would be harmful in for
> instance cellular networks for QoS differentiation. Is that the
> motivation where the non-Bundled RTCWeb use comes from, or are there
> some other good reasons?
> For SIP the legacy considerations are of course much more clear. But are
> the SIP vendors interested in Bundle? Presumably the IMS SIP vendors at
> least not, if it complicates their QoS setup.

This mostly applies to new applications. There is definitely a large 
overlap of needs between RTCWEB and CLUE.


> Markus
> *From:* [] *On
> Behalf Of *ext Christer Holmberg
> *Sent:* 13 March, 2013 22:12
> *To:* Hutton, Andrew;
> *Subject:* Re: [MMUSIC] Bundle, TURN and Legacy Interop
> Hi,
> Nothing prevents you from only sending host candidates in the first
> offer, of you want to do.
> Regards,
> Christer
> Sent from */Windows/* using *TouchDown*(
> <>)
> -----Original Message-----
> *From:* Hutton, Andrew []
> *To:* []
> *Subject:* [MMUSIC] Bundle, TURN and Legacy Interop
> Hi,
> It seems that one of the motivations of the current bundle-03 proposal
> is that the first offer is compatible with a legacy device and that a
> second offer is required for bundle (See
> One issue that I see is that if TURN is being used there could be a
> significant overhead in creating the first offer is multiple TURN
> allocations are needed for each m-line which will all then have to be
> released if bundle is used.
> I am not sure if there is a way to avoid this other but the draft should
> I think mention this issue.
> Regards
> Andy
> _______________________________________________
> mmusic mailing list
> <>
> _______________________________________________
> mmusic mailing list