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

On 3/14/13 6:19 AM, Markus.Isomaki@nokia.com 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 
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
>