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

On Wed, Mar 13, 2013 at 11:56 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>
wrote:>> 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.
>

*If* the javascript application downloaded into the browser was
written to use SIP as its signalling protocol and if the web server
had a method of rendezvous with the SIP endpoints proxy, this might be
possible.  But there is no requirement that the applications make this
choice; the system is design so that this is a supported option, not a
requirement.

regards,

Ted

> 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
> applications.
>
>
>> 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.
>
>         Thanks,
>         Paul
>
>> Markus
>>
>> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
>> Behalf Of *ext Christer Holmberg
>> *Sent:* 13 March, 2013 22:12
>> *To:* Hutton, Andrew; mmusic_ietf.org
>> *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*(www.nitrodesk.com
>> <http://www.nitrodesk.com>)
>>
>>
>> -----Original Message-----
>> *From:* Hutton, Andrew [andrew.hutton@siemens-enterprise.com]
>> *To:* mmusic@ietf.org [mmusic@ietf.org]
>> *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
>> http://www.ietf.org/proceedings/86/slides/slides-86-mmusic-9.pdf).
>>
>> 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@ietf.org <mailto:mmusic@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic