Subject: RE: [Megaco] The question for the meaning of "streams with the s ame StreamID are connected"

From: Raphael Tryster <[email-masked]>
Date: Thu, 5 Dec 2002 10:05:18 +0200

You are confusing streams with terminations.  In your example, A, B and C
are terminations, not streams.  To connect them, you need to put them in the
same context with the same stream identifier, e.g. StreamId=1.  The
following exchange may help clarify some of these concepts.  Look in the
archive for some more postings in the same thread.

Raphael Tryster

Comments inline. [KJBII]
 
-----Original Message-----
From:	Raphael Tryster [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	Monday, July 08, 2002 9:43 AM
To:	Christian Groves
Cc:	Christer Holmberg; [email-masked] <mailto:[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.
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]]
<mailto:[SMTP:[email-masked]]>  
Sent:	Monday, 08 July, 2002 3:20 AM 
To:	Raphael Tryster 
Cc:	Christer Holmberg; [email-masked] <mailto:[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 Raphael Tryster wrote: 
	> 
	> "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]]
<mailto:[SMTP:[email-masked]]>  
	>      Sent:	Thursday, 23 May, 2002 12:03 PM 
	>      To:	Raphael Tryster 
	>      Cc:	[email-masked]; <mailto:[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 

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Thursday, 05 December, 2002 9:32 AM
	To:	[email-masked]
	Subject:	[Megaco] The question for the meaning of  "streams
with the same StreamID are connected"

	Hellow everyone.
	When I read Recommendation H.248(06/2000), I have one confusion
about the meaning of following sentence, which is printed in subclause 7.1.6
(Stream descriptor).
	 
	"Within a Context, StreamID is a means by which to indicate which
media flows are interconnected: streams with the same StreamID are
connected."
	 
	In above sentence, I can not find out the concrete meaning of
"streams with the same StreamID are connected".
	 
	For example, If there are three streams, A, B, and C,  and they all
have the same streamID and StreamMode as 'sendRecv', 
	does above sentence mean that the all data received by C is sent to
A and B, the all data from A and B is also sent to C and
	C stream sends the data consisting of the data from A and B to
external of it's context?
	 
	Of cause, I guess that A and B do as same thing as C.
	 
	My thought is correct?
	 
	Could you explain the meaning of above sentence using some concrete
examples.
	 
	Forgive my poor english.
	 
	Thank you for reading my question.
	Have a nice day!

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 5 Dec 2002 10:05:18 +0200

Raphael Tryster

Comments inline. [KJBII]
 
-----Original Message-----

G'day Christian, 

-----Original Message----- 
on the 
case that
a 
termination". 
clash 
context B,
and 
B prior
to 
Farnell 
within
the 

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Thursday, 05 December, 2002 9:32 AM
	To:	[email-masked]
	Subject:	[Megaco] The question for the meaning of  "streams

	Hellow everyone.

	 

	My thought is correct?

	Forgive my poor english.