Subject: [MMUSIC] unified plan glareless atomicity improvement

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 14:16:39 +0200

The draft currently doesn't say much about how the glareless
negotiation features relate to a=sendrecv/sendonly/etc...  I think
that using recvonly and sendonly could reduce the probability of
encountering glare.

It's a detail.  And obviously, there are tradeoffs here.  By choosing
to use sendonly in an offer, you foreclose the ability of the answerer
to use that m-line for their streams.  So you would need to generate
extra recvonly m-lines in order to enable the 1-RTT negotiation.
There may be other implications that then stem from using extra
m-lines, especially in legacy interop cases, e.g. where BUNDLE
negotiation fails, or you can't access SSRCs etc..., each of which
have various negative consequences.

I think that the only guidance needed is something like:
"Implementations MAY choose to exclusively use m-lines with a=sendonly
or a=recvonly in order to further reduce the probably of encountering
glare."

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 31 Jul 2013 15:34:58 +0200

I am not sure if this proposal answer this topic .. I had a similar
proposal with uni-directional handling w.r.t glare ...

http://tools.ietf.org/id/draft-nandakumar-rtcweb-glare-handling-00.txt

Cheers
./S
PS: Its been a while i read the above draft myself .. So please forgive me
, if this is totally irrelevant :)

On Wed, Jul 31, 2013 at 2:16 PM, Martin Thomson <[email-masked]>wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 31 Jul 2013 13:45:01 +0000

> or a=recvonly in order to further reduce the probably of encountering

This proposal makes a lot of sense to me. Stefan

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 15:45:27 +0200

On 31 July 2013 15:34, Suhas Nandakumar <[email-masked]> wrote:
> I am not sure if this proposal answer this topic .. I had a similar proposal
> with uni-directional handling w.r.t glare ...
>

I think that in many respects, the unified approach to glare handling
is similar to your glare draft.  However, I believe that the unified
plan approach doesn't mandate the crazy m-line reordering shenanigans
you propose there :)  Any unified plan implementation would no longer
require a strictly ordered set of m-lines.

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 31 Jul 2013 15:46:41 +0200

100% Agreed on the martial arts issue. :-)

Cheers
Suhas

On Wed, Jul 31, 2013 at 3:45 PM, Martin Thomson <[email-masked]>wrote:

> proposal

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Jul 2013 18:42:16 +0200

I don't understand how sendonly and recvonly reduce glare.
If I offer a sendonly m-line, it still must be answered. And 
subsequently an offer for that m-line can come from either side, 
possibly producing glare.

ISTM that you should offer a sendrecv m-line iff you intend a 
bidirectional flow, where the two sides are related, will have common 
properties and lifetimes.

There is still a problem if both sides want a bidirectional flow, but 
aren't agreed on who should initiate it. In that case they both might 
offer and glare. And there there remains the question of whether they 
recognize this as glare, rather than thinking they need both flows.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 19:47:16 +0200

> I don't understand how sendonly and recvonly reduce glare.

It just reduces the probability of a change collision by further
increasing the atomicity of the overall fragmented document.  For a
bi-directional line in a=sendrecv, there is more *stuff*.

There really isn't such a thing as a bidirectional flow once you are
talking about BUNGLE.