Subject: [MEDIACTRL] Questions about <join> request

From: "Victor Paulsamy" <[email-masked]>
Date: Fri, 20 Feb 2009 13:01:49 -0800

The following are unclear for me from mixer control package-05 ID.

Q1. When is it allowed to send a <join> request?
Q2. When would a <join> request be in conflict with the existing setup?
Q3. How does a <join> request impact the existing media relationships
(the outcome of <join> request)?

Consider an example conference scenario where participants A, B and C
are joined to a conference (conf10) using <join>.

Now, if an announcement by a MS has to be whispered to, say, participant
A:

R1. <join id1="MS" id2="conf10">
	<stream media="audio" direction="inactive"/>
    </join> 	

R2.  <join id1="MS" id2="A">
	<stream media="audio" direction="sendonly"/>
    </join>

Q4. Is issuing a second <join> for a specific participant valid as shown
in R2? (first <join> joined A to conf10; MS to conf10; and the second
<join> is to join both A & MS)

Q5. In R2, there's nothing that ties this command to conf10 (neither
identifier carries conference ID). And yet, is this command executed in
the context of conf10? 

Q6. What prevents an entity from executing R2 outside the context of
conf10?

Q7. Is the media direction ("inactive") in R1 valid? Or should MS be
first joined to conf10 using "sendonly"? The whisper is not supposed to
be heard by anyone other than A. Though MS is added as a "sendonly"
participant to the conference, MS wouldn't begin playout until after the
control from AS? 

Any clarification would be helpful; Thanks in advance.

--victor

---

From: Stéphane Bastien <[email-masked]>
Date: Mon, 23 Feb 2009 05:57:23 -0800

Hi,

Here is my interpretation of the mixer specification. Shoot me if I'm wrong! (And I'd like to know if I'm wrong - I'm working on an implementation right now).

See below...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Paulsamy
Sent: 20 février 2009 16:02
To: [email-masked]
Subject: [MEDIACTRL] Questions about <join> request

[[SB]] Whenever id1 and id2 exists.

[[SB]] I can't think of an example right now.

[[SB]] The spec allows two modes: either the last join takes precedence, or the last join "adds" another audio source to the previous <join>. (We use the second approach in BroadSoft implementation.)

[[SB]] Yes.

[[SB]] There is no such thing as "the context of conf10" in the specification. <join> is only related to id1 and id2.

[[SB]] Since there is no such thing as "context of conf10", why would we try to prevent it?

Q7. Is the media direction ("inactive") in R1 valid?

[[SB]] R1 looks like a noop.

 Or should MS be first joined to conf10 using "sendonly"? 

[[SB]] Why would you try to join MS to conf10?

The whisper is not supposed to be heard by anyone other than A.

[[SB]] Then you don't join MS to conf10 at all.

 Though MS is added as a "sendonly" participant to the conference,

[[SB]] Where is this join? Why would you do it?

 MS wouldn't begin playout until after the control from AS? 

[[SB]] The time at which MS begins playing is not related in any way to the <join> operations.

--victor
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl