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

On 3/14/13 8:22 PM, Ted Hardie wrote:
> 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.

Yes, I agree. But it must be possible. In particular, I don't want to 
get into a situation where RTP multiplexing in RTCWEB is incompatible 
with RTP multiplexing in CLUE, requiring a media gateway, or the 
foregoing of multiplexing, to resolve.

	Thanks,
	Paul

> 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
>