Subject: Re: FW: [Megaco] Multiplex descriptor

From: Christian Groves <[email-masked]>
Date: Wed, 17 Jan 2007 11:27:47 +1100

Hello Arturo,

H.248 doesn't talk about topology and the multiplex termination. The 
multiplex termination may be referenced in the topology triple but I 
think more of the issue is what is the behaviour?  It is special because 
its really sitting in the middle of the context. ie. the media/data 
actually leaves the MG via other terminations. If monitoring is needed 
then these other terminations could be monitored.

What function/service are you trying to achieve that can't be done 
without this?

Regards, Christian

> -----Original Message-----
> From: Arturo Martin De Nicolas (AC/EDD)
> [mailto:[email-masked]] 
> Sent: Monday, January 08, 2007 4:45 PM
> To: [email-masked]
> Subject: [Megaco] Multiplex descriptor
>
> Hello,
>
> I have a question concerning a multiplexing termination, i.e. a
> termination with a mux descriptor. In the H.248.1 model (see 6.2) the
> multiplexing termination is connected on one side to the bearer
> termination or terminations representing the multiplexed stream, and on
> the other side to the bearer termination or terminations representing
> the demultiplexed (separated) streams, e.g. audio and video.
>
> My question is: in addition to these connections, may the multiplexing
> termination be also connected to some monitoring terminations, i.e. via
> one-way connections?
>
> Example:
>
> Context C1 with audio stream S1, video stream S2, and multiplexed stream
> S0.
>
> Multiplexed stream:  T1 -> Stream S0  
>
> Multiplexing termination: Tmux (muxdescriptor=H.223{T1}) -> Stream S0,
> S1 and S2
>
> Demultiplexed streams:  T3  ->  Stream S1 and S2
>
>
> Is it possible to add T1b to the context with the following topology?
>
> Topology {(*, T1b, Isolate), (Tmux, T1b, oneway)}, Add (T1, Stream S0)
>
> As I see it, this could in principle work. However, as the multiplexing
> termination is special, I wonder if this resulting context is legal. 
>
> Regards,
> Arturo
>                             
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>   

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

---

From: "Arturo Martin De Nicolas \(AC/EDD\)" <[email-masked]>
Date: Wed, 17 Jan 2007 13:57:18 +0100

Hi Christian,

I agree with you that best would be to monitor from the other
terminations (T1 or T3) in the example below.  But in some cases,
example, CS-IMS Gateway, during Handover on the CS side, this  would
lead to having to insert a new mux termination in the context: one in
the main connection, one in the monitoring branch, which is less
desirable.

But actually for this handover case there is a further complication. At
HO we have a context with a bothway connection, and a one-way
connection. At a certain point, these two connections have to be swaped:
the one-way becomes bothway, and the bothway becomes one-way. Finally,
at the third step, the one-way connection is released. If we take the
one-way branch from the mux termination, as I was suggesting below,
there is no way to do the swaping, right? You would send a MOD on the
Mux termination, now indicating T1b in the Mux descriptor, but according
to H.248 this would lead to the automatic subtraction of T1, which is
not was we wanted, as we still need to keep the connection (Tmux,T1)
one-way until the HO is completed.

Best regards,
Arturo

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, January 17, 2007 1:28 AM
To: Arturo Martin De Nicolas (AC/EDD)
Cc: megaco ietf
Subject: Re: FW: [Megaco] Multiplex descriptor

Hello Arturo,

Regards, Christian

> termination or terminations representing the multiplexed stream, and 
> on the other side to the bearer termination or terminations 
> representing the demultiplexed (separated) streams, e.g. audio and
video.

> termination be also connected to some monitoring terminations, i.e. 
> via one-way connections?
>
> Example:
>
> Context C1 with audio stream S1, video stream S2, and multiplexed 
> stream S0.
>
> As I see it, this could in principle work. However, as the 
> multiplexing termination is special, I wonder if this resulting
context is legal.

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jan 2007 11:05:07 +1100

Hello Arturo,

I'm a bit confused by your first paragraph. If monitoring is done on the 
CS and Packet side terminations why do you need to put a new mux 
termination in? I can see in the case of HO that you would add a new 
Tmux for T1b. A think this is much cleaner as the behaviour is undefined 
if T1 and T1b were added to the same mux. Also monitoring a Mux 
termination, what will you get multiplexed stream, de-multiplexed 
streams or both?

Regards, Christian

---

From: "Arturo Martin De Nicolas \(AC/EDD\)" <[email-masked]>
Date: Thu, 18 Jan 2007 09:23:48 +0100

Hi Christian,

In one case I was referring to one monitoring branch created
specifically for the HO, so I think we agree that in that case we would
need two Tmux terminations, right?

There could be also some cases for interception where you for some
reason would like to start the monitoring branch from, say, the packet
termination, but the path to the Monitoring Centre is CS, so that would
also require an extra Tmux.

Thus I was trying to explore ways to avoid these extra Tmux, but I guess
the conclusion is that taking a monitoring branch directly from the Tmux
termination is not recommended/allowed. Do you agree? You are right,
which side of the mux would be monitored is unclear. 

Thanks for your clarification.
Arturo

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 1:05 AM
To: Arturo Martin De Nicolas (AC/EDD)
Cc: megaco ietf
Subject: Re: FW: [Megaco] Multiplex descriptor

Hello Arturo,

Regards, Christian

Arturo Martin De Nicolas (AC/EDD) wrote:
> But actually for this handover case there is a further complication. 
> At HO we have a context with a bothway connection, and a one-way 

> Mux termination, now indicating T1b in the Mux descriptor, but 
> according to H.248 this would lead to the automatic subtraction of T1,

> which is not was we wanted, as we still need to keep the connection 
> (Tmux,T1) one-way until the HO is completed.
>
> Best regards,
> Arturo
>
>
>
> think more of the issue is what is the behaviour?  It is special 
> because its really sitting in the middle of the context. ie. the 
> media/data actually leaves the MG via other terminations. If 
> monitoring is needed then these other terminations could be monitored.
>

---

From: "Arturo Martin De Nicolas \(AC/EDD\)" <[email-masked]>
Date: Thu, 18 Jan 2007 09:52:46 +0100

Hi again,

Sorry, I was bit too quick jumping into conclusions.

About which side of the mux would be monitored: couldn't you determine
that by specifying the wanted stream in the monitoring terminations? S0
in T1b, in the example below. Also topology can be applied to a
particular stream.

Regards,
Arturo

-----Original Message-----
From: Arturo Martin De Nicolas (AC/EDD)
[mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 9:24 AM
To: Christian Groves
Cc: megaco ietf
Subject: RE: FW: [Megaco] Multiplex descriptor

Hi Christian,

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, January 18, 2007 1:05 AM
To: Arturo Martin De Nicolas (AC/EDD)
Cc: megaco ietf
Subject: Re: FW: [Megaco] Multiplex descriptor

Hello Arturo,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Jan 2007 10:07:43 +1100

G'Day Arturo,

Yes I agree on the need for two muxs.
With regards to the monitoring the problem I see is that the stream ids 
are not necessary unique. T1b could contain a stream 1 as well as T3 
(and even T1).  The demuxed streams are hidden from the rest of the 
context and the mux descriptor itself doesn't have any information on 
handling streams. So again I think its messy if we try to start using 
topology on mux terminations.

Regards, Christian

Arturo Martin De Nicolas (AC/EDD) wrote:
>> connection. At a certain point, these two connections have to be
>>     
> swaped:
>