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

From: <[email-masked]>
Date: Wed, 13 Mar 2013 22:19:57 +0000

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?

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.

Markus

From: [email-masked] [mailto:[email-masked]] 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 [[email-masked]]
To: [email-masked] [[email-masked]]
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 13 Mar 2013 22:55:34 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, March 13, 2013 6:20 PM
> To: [email-masked]; andrew.hutton@siemens-
> enterprise.com; [email-masked]
> Subject: [MMUSIC] Question about Bundle and Legacy Interop (RE: Bundle,
> TURN and Legacy Interop)
> 
> 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?
> 
> 
> 
> 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?

Not just for cellular but for any scenario in which QoS is based on using different 5-tuples for media flows for which different treatment is desired.

Cheers,
Charles

> 
> 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.
> 
> 
> 
> Markus
> 
> 
> 
> 
> 
> Sent from Windows using TouchDown (www.nitrodesk.com)
> 
> 
> 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.
> 
> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Mar 2013 22:17:37 -0400

On Wed, Mar 13, 2013 at 6:19 PM,  <[email-masked]> wrote:
> 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?
>

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

My personal view, not a consensus view of the chairs,

regards,

Ted Hardie

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 02:57:33 +0000

Hi,

Ted Hardie wrote:
>> 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?
>>
>
>Hi Markus,
>
>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
>intermediaries.
>

Agree. 

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. 

Markus

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2013 11:56:56 +0800

On 3/14/13 6:19 AM, [email-masked] wrote:
> 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:[email-masked] [mailto:[email-masked]] *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,
>
> Sent from */Windows/* using *TouchDown*(www.nitrodesk.com
> <http://www.nitrodesk.com>)
>
>
> *From:* Hutton, Andrew [[email-masked]]
> *To:* [email-masked] [[email-masked]]
> *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.
>
> [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Mar 2013 08:22:02 -0400

On Wed, Mar 13, 2013 at 11:56 PM, Paul Kyzivat <[email-masked]>
wrote:>> As far as I understand it, RTCWeb to Legacy interop can be
accommodated
> 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

> required. But a device that wants to make this possible should be able to.
> This could be important for media-intensive applications.
>
> This mostly applies to new applications. There is definitely a large overlap
> of needs between RTCWEB and CLUE.
>
>         Thanks,
>         Paul
>
>> Markus
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2013 20:46:13 +0800

> choice; the system is design so that this is a supported option, not a

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Mar 2013 13:53:26 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

As Jonathan Rosenberg said
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg06856.html)
> For many application developers, what is interesting about webRTC is
> NOT just browser to browser communications, but connecting users in
> a browser to users elsewhere - on other devices, in other
> networks. After all, the vast majority of web application developers
> do not have the luxury of a massive social graph, or the luxury of
> their users being parked persistently on their website and thus able
> to receive an incoming call. Many websites that have customer
> support or service needs would love to be able to allow their users
> to have a video call with an agent. However, those agents are
> probably sitting on existing agent systems which are not web based,
> and itbTo: 
Subject: 
--text follows this line--
s almost certainly true that they do not today support VP8,
> but rather H.264.

What he didn't say explicitly is that the existing agent systems use
SIP.  So there is a large market to be tapped if WebRTC connects
smoothly to SIP.  And when I say "smoothly", I mean that the web
server/SIP gateway only has to handle "signaling", that it can hand
the SDP across with little or no modification, and doesn't have to
touch the media packets at all.

Of course, WebRTC shouldn't be made less efficient or effective just
to interoperate with SIP, but I don't see that there's any necessity
to do that.  (As long as we remember EKR's dictum that in the context
of negotiating video media, an extra few hundred bytes added to an SDP
description is not significant!)

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Mar 2013 13:52:52 -0400 (EDT)

> From: "Charles Eckel (eckelcu)" <[email-masked]>
> 
> > From: [email-masked]
> > 
> Not just for cellular but for any scenario in which QoS is based on
> using different 5-tuples for media flows for which different
> treatment is desired.

The question of QoS differentiation is interesting and probably one we
have to address, as mobile devices have bandwidth limitations.

If it's possible to mark individual packets within a transport flow
for different QoS treatments, then we need to define QoS markings as
an "application level" attribute rather than a "transport level"
attirbute.

If QoS differentiation is done entirely based on transport
associations (5-tuples), then the strategy would be to have several
bundles of m= lines, one for each QoS type.

The naive way to do this, that is, just offering two different
bundles, is suboptimal if the offerer doesn't know whether different
media types need to be in different transport flows or not, because it
prevents the answerer from arranging for all the media to be in one
bundle (using one transport association, i.e., port) if the answerer
knows that there is no QoS problem.

This is a situation where using hierarchical bundling would provide a
solution:  If the offerer does not have a need for different transport
flows for audio and video, but is concerned that the answerer might
have such a need, it builds an offer containing a master bundle that
contains two subordinate bundles, one containing (e.g.) the audio
streams and one containing the video streams.

If the answerer does not want to separate audio and video, it accepts
all the bundling, and then all media are in one transport flow.  If
the answerer wants to separate audio and video, it rejects the
top-level bundle, but accepts each subordinate bundle individually,
thus arranging for two transport flows, one containing audio and one
containing video.

Dale