Subject: RE: [Megaco] Scope of StreamId

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Jul 2002 17:26:56 -0400

In Line

> -----Original Message-----
> From: Kevin Boyle [mailto:[email-masked]]
> Sent: Monday, July 08, 2002 1:56 PM
> To: Raphael Tryster; Christian Groves
> Cc: Christer Holmberg; [email-masked]
> Subject: RE: [Megaco] Scope of StreamId
> 
> 
> Comments inline. [KJBII]
> 
>  
> -----Original Message-----
> From: Raphael Tryster [mailto:[email-masked]]
> Sent: Monday, July 08, 2002 9:43 AM
> To: Christian Groves
> Cc: Christer Holmberg; [email-masked]
> Subject: RE: [Megaco] Scope of StreamId
> 
> 
> G'day Christian, 
> Thanks for your answer.  I think you have cleared up a basic 
> misconception I
> had, and many concepts are now falling into place in my mind. 
>  Could I try
> out a few more?
> 
> Simple calls have one physical termination and one ephemeral 
> termination in
> a context. 
> 
> [KJBII] This is certainly the most common, although there are 
> cases where I
> could see two physicals or two ephemerals in a context that could be
> considered a "simple" call.
Yes, "hairpin" connections are simple calls.  Some gateways can't
hairpin out to the network, but they really should.

> 
> Special calls such as call waiting, conference etc. will 
> usually have one
> physical termination and several ephemeral terminations in a context. 
> 
> [KJBII] There is no need, really, for a physical in a 
> conference context.
> The conference circuit resource is implied by the context.
As before, you can do a three way with two physicals and an ephemeral,
or three physicals, or 3 ephemerals, although, again, some gateways
don't implement the latter.

> 
> An alternative way to implement call waiting would be to move 
> terminations
> between different contexts, as in RFC 3015 section 6. 
> 
> [KJBII] Indeed.
There are two mechanisms implementations have used for call waiting -
move terminations between two contexts (with one context having
two terminations and the other having one), and using topology
to manipulate the media flow (using one 3 terminal context).
Interestingly, MGs should handle either, and the MGC can do whatever
it wants to.

> 
> Wherever an ephemeral termination appears in a call scenario, 
> it could be
> replaced by a physical termination if the call is between subscribers
> connected to the same MG. 
> 
> [KJBII] It could.  This hairpinning scenario is the first 
> "two physicals"
> case I mentioned above that comes to mind.
Yes

> 
> RFC 3015 section 6 gives an example of a context containing 
> only ephemeral
> and no physical terminations, though not as an initial 
> condition.  Would it
> ever make sense for a context to be created such that 
> initially it contains
> only an ephemeral termination? 
> 
> [KJBII] How about a call group scenario?  Several different 
> sets are placed
> in a group, and all ring when the number is dialed, but only 
> one answers.
> Here, you could set up the ephemeral in context first, then add the
> appropriate physical when the call is answered.
Many MGCs create a call by ringing the physical termination while
it is in the null context.  Some also create a context for the
ephemeral before they add the physical termination.  The sequence is:
	Create context, add ephemeral
	Ring physical in null
	when it answers, add physical to context
Some MGs supply remote ringback.  The MG could implement the ringback
termination as an ephemeral (more common) or physical (less common).

> 
> Based on your answer about StreamId, I would expect an MGC to allocate
> StreamIds according to the type of media.  For example, if 
> all audio streams
> get StreamId=1, then it is possible to move terminations 
> between contexts
> and get them connected.  Otherwise, it wouldn't work.  Is 
> this how real MGCs
> behave? 
Yes, all MGCs I have seen use consistant StreamIds.  Of course, there
are VERY few MGs that have implemented RFC3015 that have more than one
stream per termination.

> 
> 
> 
> When several terminations are in a context, e.g. in a 
> conference call, and
> they are all supposed to hear each other, they must all have the same
> StreamId.  This will be the case if the Stream descriptor is 
> not written
> explicitly in the Media descriptor, as StreamId=1 is assumed.
> 
> [KJBII] Correct.
Agree

> 
> The Megaco notion of a context can be thought of as a 
> generalization of the
> MGCP notion of a connection, in the sense that each bilateral 
> relationship
> between terminations in a Megaco context is like an MGCP connection.
> 
> [KJBII] Generally, yes.  However, Megaco's decomposition of 
> the "connection"
> is far more flexible and more powerful.  Complex 
> interconnection scenarios
> are a lot easier to set up and manipulate, if for no other 
> reason than the
> tools for doing that work are built into the protocol.
Yes, although there are some other architectural differences between
an MGCP connection and a Megaco context.

> 
> Draft-ietf-megaco-callflows-00.txt contains a conference 
> scenario in which
> the topology descriptor is used.  When the conference is 
> fully set up, each
> MG has a context containing its own physical termination, and 
> two ephemeral
> terminations representing the two remote parties.  For 
> example, in RGW1,
> Context1 contains PhyA, EphA representing remote B, and EphD 
> representing
> remote C.  The topology descriptor specifies bothway for each 
> of the three
> pairs of terminations in the context.  Now I understand that 
> each of the
> pairs involving PhyA needs to be bothway, so that subscriber 
> A can exchange
> media with remote subscribers B and C.  What I do not 
> understand is why the
> {EphA, EphD} pair needs to be bothway. Surely the media flow 
> between B and C
> is controlled in their respective gateways, and not in the 
> third leg of the
> call?
> 
> [KJBII] Actually, what this shows is that all media received 
> from B is sent
> to C (and vice versa).  If there is mixing of all the streams 
> on all three
> (potential) MGs as described in -callflows, then I would 
> think that there
> will be a significant echo problem.  The ephemerals should be 
> Isolated from
> each other in all the contexts.  Note that as each new 
> conferee is added,
> the number of contexts involved goes up by one, but the 
> distributed number
> of terminations goes up by ((number of conferees * 2) + 1). 
> That is, when
> you add a fourth conferee, there is a new ephemeral added to 
> each of the
> three existing contexts (each of which must be Isolated from 
> all the other
> ephemerals in its context), and a new context with four 
> terms: one physical
> and three ephemeral.  That's 7 terms, and the associated Topology work
> required to Isolate all the ephemerals from each other.  When 
> you add a
> fifth conferee, you get a fifth context and 9 more terms.  A 
> sixth adds 11
> terms, and so on.  This seems overly complex to me.
> 
> [KJBII] An alternate way to setup this conference is to have 
> the three (or
> more) members set up as "simple" calls, and a central 
> "conference context"
> where the media flows come together to be mixed and transmitted.  Four
> contexts in all in the three-way call case -- three with a 
> single physical
> and ephemeral, and one with three ephemerals.  As you add 
> conferees to this
> configuration, you still have an additional context, but the 
> distibuted
> number of terminations goes up by 3 -- the physical and 
> ephemeral in the new
> context, and one more ephemeral in the conference context.  
> Also, there is
> no Topology manipulation that has to occur for normal conferences.
> 
How you control conferencing has been a subject of much discussion without
a single, everyone-agrees-with-it answer.

Conferencing mixing is usually expressed as "mix-minus" - which means that
every terminal hears the sum of all terminals except himself.
Topology is defined as a sum of all inputs (a "star" mixer).  Thus
for any terminal, you need to hear every input except yourself.

Topology can be used to describe such a mix, but it's pretty complex
to do that, I think.  If you do use topology, you have all terminations
in one context.

I prefer to describe a conference bridge as a collection of two termination
contexts.  Each party to the bridge has an ephemeral representing the flow
from the network, and either a physical or ephemeral representing one
port on the bridge.  To use such a mechanism, you need a package that
describes a "ConferenceId" where every port with the same conferenceId
is mixed (using mix-minus) together.  This makes the establishment process
simpler, but now you have one context per participant.

Brian 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:28:04 +1000

G'Day Raphael,

I think Brian and Kevin have done a good summary. With regards to conferencing:
currently the only method available and the one described in the protocol is
that all participants (terminations) are placed in one context.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:28:04 +1000

G'Day Raphael,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:28:04 +1000

G'Day Raphael,

Regards, Christian

"Rosen, Brian" wrote:
> from the network, X-Mozilla-Status: 0009or ephemeral representing one

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 10:28:04 +1000

G'Day Raphael,

Regards, Christian