Subject: Re: [MMUSIC] [rtcweb] Plan A, respun

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 8 May 2013 14:38:36 +0200

A couple of questions (and sorry for the rtcweb/webrtc centric 
perspective) for clarification:

* How would the info about PC-track and PC-stream id's be conveyed (I 
assume the msid draft)?

* What is your thinking regarding mapping between PC-tracks and m-lines? 
For example, if Alice's app initiates a session with two video 
PC-track's flowing to Bob's app, that would presumable create a session 
with two sendonly m-lines. If, at a later stage, Bob's app upgrades the 
session by sending three video PC-tracks to Alice's app. How would the 
Bob -> Alice video PC-tracks be allocated to the existing m-lines 
(becoming sendrecv), and how would pick which one to use a new m-line? 
E.g., would it be random, or should the app decide, and based on what in 
that case?

Stefan

On 2013-05-07 20:30, Adam Roach wrote:
> In order to facilitate discussion between the two SDP format
> alternatives we're considering, I've put together a document that more
> clearly spells out the Plan A approach as we originally envisioned it.
> Note that this is a slightly different approach than Cullen outlined in
> Orlando. I fear the Orlando approach may have suffered from its attempts
> to incorporate some elements of Plan B in an attempt to appease
> proponents of that approach; and, in doing so, lost some of its clean
> architecture.
>
> The cleaned up, new-and-improved description of the Plan A approach is
> available here:
>
> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt
>
> Note that we've omitted discussion of glare reduction from that
> document, as I believe that mid-session glare can be completely avoided
> by applications implementing a set of non-normative behaviors. These
> behaviors are described in the a separate companion document:
>
> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt
>
> Thanks.
>
> /a
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 08:43:20 -0700

On 8 May 2013 05:38, Stefan Håkansson LK
<[email-masked]> wrote:
> A couple of questions (and sorry for the rtcweb/webrtc centric perspective)
> for clarification:
>
> * How would the info about PC-track and PC-stream id's be conveyed (I assume
> the msid draft)?

Yes, that's a solved problem. No sense reiterating it in the draft
(it's orthogonal to what the draft actually addresses).

> * What is your thinking regarding mapping between PC-tracks and m-lines? For
> example, if Alice's app initiates a session with two video PC-track's
> flowing to Bob's app, that would presumable create a session with two
> sendonly m-lines. If, at a later stage, Bob's app upgrades the session by
> sending three video PC-tracks to Alice's app. How would the Bob -> Alice
> video PC-tracks be allocated to the existing m-lines (becoming sendrecv),
> and how would pick which one to use a new m-line? E.g., would it be random,
> or should the app decide, and based on what in that case?

Alice's offer would contain at least two m-lines.  Those would not
necessarily be sendonly.  If she was capable of receiving more than 2
inbound, the offer could contain recvonly lines too (I believe that
this fits with the OfferToReceiveVideo=n constraint).  Of course, if
those lines were not compatible with what Bob wanted to send (too
much, different codecs, different constraints, etc...), then Bob is
required to send another offer to get his media out.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 9 May 2013 13:41:46 +0200

> (it's orthogonal to what the draft actually addresses).

Right, just wanted it clarified.

> this fits with the OfferToReceiveVideo=n constraint).

OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines 
would be sendonly, 1 would give one sendrecv and one sendonly and so on.

So, if OfferToReceiveVideo=0 was used (or was even the default), we 
would in the case of a symmetric service (Alices's and Bob's apps 
intending to send the same amount of audio and video tracks, and doing 
it from the start of the session) actually end up with the same 3-way 
handshake as in Plan B (since sendonly/recvonly can't be upgraded to 
sendrecv without a new offer)?

(I have no problem with that behavior, I just want to understand)

> Of course, if

...because new m-lines are required.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 May 2013 08:45:47 -0700

On 9 May 2013 04:41, Stefan Håkansson LK
<[email-masked]> wrote:
> OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines would be
> sendonly, 1 would give one sendrecv and one sendonly and so on.
>
> So, if OfferToReceiveVideo=0 was used (or was even the default), we would in
> the case of a symmetric service (Alices's and Bob's apps intending to send
> the same amount of audio and video tracks, and doing it from the start of
> the session) actually end up with the same 3-way handshake as in Plan B
> (since sendonly/recvonly can't be upgraded to sendrecv without a new offer)?
>

I think that you have it understood.

> ...because new m-lines are required.

Yep.