Subject: [Megaco] Scope of StreamId

From: Raphael Tryster <[email-masked]>
Date: Sun, 7 Jul 2002 11:32:54 +0200

"If a termination is moved from one context to another, the effect on the
context to which the termination is moved is the same as in the case that a
new termination were added with the same StreamIDs as the moved
termination". 

Question:  If StreamID has context scope, then how do we prevent a clash
between the StreamID of a termination moved from context A to context B, and
the StreamID of a termination that was already present in context B prior to
the move?

Raphael Tryster
	
	-----Original Message-----
	From:	Christer Holmberg [SMTP:[email-masked]]
	Sent:	Thursday, 23 May, 2002 12:03 PM
	To:	Raphael Tryster
	Cc:	[email-masked]; Peter Farnell
	Subject:	Re: [Megaco] Local and remote descriptors

	Streams with the same StreamID are associated with each other within
the
	scope of a Context.

	Regards,

	Christer Holmberg
	Ericsson Finland

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 8 Jul 2002 15:43:16 +0200

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?

1.	Simple calls have one physical termination and one ephemeral
termination in a context.

2.	Special calls such as call waiting, conference etc. will usually
have one physical termination and several ephemeral terminations in a
context.

3.	An alternative way to implement call waiting would be to move
terminations between different contexts, as in RFC 3015 section 6.

4.	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.

5.	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?

6.	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?

7.	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.

8.	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.

9.	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?

Regards,

Raphael Tryster

	-----Original Message-----
	From:	Christian Groves [SMTP:[email-masked]]
	Sent:	Monday, 08 July, 2002 3:20 AM
	To:	Raphael Tryster
	Cc:	Christer Holmberg; [email-masked]
	Subject:	Re: [Megaco] Scope of StreamId

	Hello Raphael,

	I don't think there is a problem here. You probably actually want a
clash
	between stream IDs. ie. if you move a termination with stream ID=1
into another
	context that also has streamID=1 then the streams will be mixed.
This is
	desirable behaviour for conference, 3pty etc.

	Regards, Christian

termination".
	>      Streams with the same StreamID are associated with each other
within the

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 8 Jul 2002 15:43:16 +0200

G'day Christian,

Regards,

Raphael Tryster

	-----Original Message-----
	From:	Christian Groves [SMTP:[email-masked]]
	Sent:	Monday, 08 July, 2002 3:20 AM
	To:	Raphael Tryster
	Cc:	Christer Holmberg; [email-masked]
	Subject:	Re: [Megaco] Scope of StreamId

	Hello Raphael,

	Regards, Christian

termination".
within the

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 8 Jul 2002 13:55:42 -0400

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, 

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.

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.

An alternative way to implement call waiting would be to move terminations
between different contexts, as in RFC 3015 section 6. 

[KJBII] Indeed.

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.

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.

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? 

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.

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.

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.

Regards, 
Raphael Tryster 
-----Original Message----- 
From:   Christian Groves [SMTP:[email-masked]] 
Sent:   Monday, 08 July, 2002 3:20 AM 
To:     Raphael Tryster 
Cc:     Christer Holmberg; [email-masked] 
Subject:        Re: [Megaco] Scope of StreamId 
Hello Raphael, 
I don't think there is a problem here. You probably actually want a clash 
between stream IDs. ie. if you move a termination with stream ID=1 into
another 
context that also has streamID=1 then the streams will be mixed. This is 
desirable behaviour for conference, 3pty etc. 
Regards, Christian 
termination". 
the 
>      Ericsson Finland 

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 8 Jul 2002 13:55:42 -0400

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, 

[KJBII] Indeed.

[KJBII] Correct.

Regards, 
Raphael Tryster 
-----Original Message----- 
From:   Christian Groves [SMTP:[email-masked]] 
Sent:   Monday, 08 July, 2002 3:20 AM 
To:     Raphael Tryster 
Cc:     Christer Holmberg; [email-masked] 
Subject:        Re: [Megaco] Scope of StreamId 
Hello Raphael, 
termination". 
the

---

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

In Line

> From: Kevin Boyle [mailto:[email-masked]]
> Sent: Monday, July 08, 2002 1:56 PM
> To: Raphael Tryster; Christian Groves
Yes, "hairpin" connections are simple calls.  Some gateways can't
hairpin out to the network, but they really should.

> 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.

> between different contexts, as in RFC 3015 section 6. 
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.

> case I mentioned above that comes to mind.
Yes

> 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).

> and get them connected.  Otherwise, it wouldn't work.  Is 
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.

> explicitly in the Media descriptor, as StreamId=1 is assumed.
Agree

> 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.

> 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