Subject: [MMUSIC] Requirements for Bundle, Fumble etc.

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 9 Feb 2013 03:01:31 +0000

Hi,

I suggest that the requirements discussed at the interim (http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-10.pdf) regarding bundling on to a single 5-tuple need the following additional requirements.

1. Must work for a dual stack client when ICE candidates are used for address family negotiation. I think this is interesting because in this scenario there will of course be different candidates for each address family and we will probably need some rules to make sure this works.

2. Must work when a TURN server is used. This is interesting because although a single TURN allocation will be needed for the bundled candidates it will I assume be necessary to do additional TURN allocations just in case the peer does not support bundle.

Regards
Andy

---

From: Emil Ivov <[email-masked]>
Date: Sat, 09 Feb 2013 13:18:25 -0500

Hey all,

On 08.02.13, 22:01, Hutton, Andrew wrote:
> 2. Must work when a TURN server is used. This is interesting because
> although a single TURN allocation will be needed for the bundled
> candidates it will I assume be necessary to do additional TURN
> allocations just in case the peer does not support bundle.

This can actually be stated in a more generic way. I already mentioned
it to Cullen but it's probably worth putting it on the list too:

Some of the solutions that we discussed in Boston had the property of
requiring multiple port allocations which would translate into multiple
sets of ICE candidates. Note that, given how the whole point here is to
talk to non-webrtc offer/answer devices, offerers may often be choosing
not to use full trickle ICE and only resort to half trickle (or even
vanilla ICE).

Also note that, contrary to dedicated devices, WebRTC applications would
often have no indication that a call is about to occur, until a "Call
Us" button on a web page is clicked.

In other words, using solutions like one-rtp or MMT would mean that
clients would have to go through all the (paced) steps of harvesting
candidates in a blocking manner, while the user is waiting and without
even the option of using the vanilla ICE optimization of pre-harvesting
them in anticipation for a call.

I am not sure if this qualifies as a requirement but it would probably
be good to keep it in mind.

Cheers,
Emil

-- 
https://jitsi.org

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 9 Feb 2013 22:47:24 -0500 (EST)

> From: "Hutton, Andrew" <[email-masked]>
> 
> 1. Must work for a dual stack client when ICE candidates are used
> for address family negotiation. I think this is interesting because
> in this scenario there will of course be different candidates for
> each address family and we will probably need some rules to make
> sure this works.

Doesn't ICE already have rules for negotiating both IPv4 and IPv6
addresses simultaneously?  (I'm not very familiar with ICE, but
skimming RFC 5245 suggests that SDP can provide candidates with both
IPv4 and IPv6 addresses, and that the ICE negotiation handles them
both.)

Dale

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 10 Feb 2013 16:30:53 +0000

> IPv4 and IPv6 addresses, and that the ICE negotiation handles them

Absolutely ICE does have these rules we do however need to make sure that they work when bundle is being negotiated at the same time.

Andy

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 13 Feb 2013 21:30:05 +0000

> 2. Must work when a TURN server is used. This is interesting because although a single TURN allocation will be needed for the bundled candidates it will I assume be necessary to do additional TURN…

+1 makes sense to me. Now if only I had read this before up