Subject: [Megaco] Streams & mixing

From: Dan Elbert <[email-masked]>
Date: Tue, 28 May 2002 15:22:05 +0300

Hi Christian
So do you think this should be a context property ?
I'm talking now about a v.1 implementation, so the evolution path may be to
put this in a mixer termination for now and later move this to a context
property.
I think we need packages defined, nobody seems to be working on this lately.
In any case, how do you think it should work after mixing the input streams
an producing the  output stream ? It seems to required to open in every rtp
termination 2 streams, 1 with only local descriptor (the input one) and one
with only remote descriptor (the output one). Does this seems OK ?

Thanks
Dan Elbert
RADVISION

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, May 28, 2002 4:40 AM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] Streams & mixing

G'Day Dan,

I'm not overly comfortable of having a seperate "mixer" termination when
really
its a function of the context. PErhaps what is needed is to further develop
the
requirements that were drafted on conferencing to come up with a few
packages.
One of which could define a property that is a list of streamIDs to be mixed
and
then sent to a single output stream.

Regards, Christian

Dan Elbert wrote:
>
> Hi
> Let's assume that I have n input video streams, n rtp terminations
> representing them, a mixing unit represented by a mixing termination, and
m
> output streams ( m<=n ) being mapped to the rtp terminations in some way.
> One way to implement this could be to assign stream id=1 to all the input
> streams and set the mode to receive only in the rtp terms, and sendrecv in
> the mixing term, and then to create m additional streams exiting the
mixing
> termination, and to put one of this m streams in every rtp termination
> according to the mapping.
> In this case stream 1 (input) has only local descriptor, and the output
> stream has only remote descriptor.
> This looks weird but if the same stream id is used for input and output I
> don't know how to indicate the mapping unless is some kind of "magic"
> happening in the mixer term so that every rtp term generates the right
> output stream.
> Any comments ?
>
> Dan Elbert
> RADVISION
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

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

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

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

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 28 May 2002 10:35:13 -0400

You've expressed the basic philosophical issue that we have to thrash out.
My own view when we were first developing the protocol was that we would add
specific context properties to indicate the mixing algorithms to be applied.
On the other hand, the mixing termination provides the focus for fairly
precise control of media processing.  I wonder if we might take the analysis
of the two approaches to the next stage by sketching or even detailing the
packages needed to do the job either way? 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, May 27, 2002 9:40 PM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] Streams & mixing

G'Day Dan,

Regards, Christian

m
mixing

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 28 May 2002 10:35:13 -0400

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, May 27, 2002 9:40 PM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] Streams & mixing

G'Day Dan,

Regards, Christian

m
mixing

---

From: Dan Elbert <[email-masked]>
Date: Wed, 29 May 2002 08:25:06 +0300

I agree that we need to define the packages, but also the use of the streams
is not clear to me.
 
Dan Elbert
RADVISION

-----Original Message----- 
From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, May 27, 2002 9:40 PM 
To: Dan Elbert 
Cc: [email-masked]' 
Subject: Re: [Megaco] Streams & mixing 

G'Day Dan, 

Regards, Christian 

m 

mixing 
> happening in the mixer term so that every rtp term generates the right 
<https://www1.ietf.org/mailman/listinfo/megaco>  

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

---

From: Dan Elbert <[email-masked]>
Date: Wed, 29 May 2002 08:25:06 +0300

Dan Elbert
RADVISION

-----Original Message----- 

G'Day Dan, 

Regards, Christian 

m 

mixing

---

From: Dan Elbert <[email-masked]>
Date: Wed, 29 May 2002 09:18:42 +0300

Hi Christian
1. Would this output stream id be different than the input stream id in the
termination ?
2. The problem of doing this control in each termination is that if you are
producing a composite stream and routing this to many termination and then
you change something in it, you have to send commands to al the
terminations. More than that, seems like some natural mapping is needed to
characterize this composite output stream. That's why I think it should be
either a mixing term or a context property - although is not clear how to
associate a stream witg a context property.

Dan

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, May 29, 2002 4:08 AM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] Streams & mixing

G'Day Dan,

I think Tom has elaborated on my concerns. I also agree with Tom that needs
to
be discussed in greater depth. Sg16 has a place holder for work on
conference
packages put wasn't driven at all at the February meeting. This could be a
context property or it could be a Local control property on the output
stream.
ie. property inputstream=5,6. This would suit your v.1 implementation.
Therefore
you wouldn't need to play with modes or "magic".

I think its a pity that we didn't add the possibility to add context
properties
via packages.

Regards, Christian

---

From: Dan Elbert <[email-masked]>
Date: Thu, 30 May 2002 15:56:24 +0300

Hi
We have been talking about requirements for a few months.
There was a requirements document presented at Dublin ITU-T meeting
(AVD-2102), including some description of the architecture. 
I was trying to see how this architecture would work and started to come up
with questions about the right use of streams, mixing terminations , etc.
I think that is time to refine the architecture, test it against specific
cases and start defining packages.
Is there people doing this kind of work now that can contribute from their
experience ?

Dan Elbert
RADVISION

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 10:54 AM
To: Christian Groves
Cc: Dan Elbert; [email-masked]'
Subject: Re: [Megaco] Streams & mixing

Hi,

I agree with Christian. Before we start thinking of HOW to do it, let's
first
concentrate on WHAT to do - ie come up with some kind of requirements.

Regards,

Christer Holmberg
Ericsson Finland

Christian Groves wrote:

> G'Day Dan,
>
> Please see my replies below.
>
> Cheers, Christian
>
> Dan Elbert wrote:
> >
> > Hi Christian
> [CHG] This depends what properties you put in the local and remote of the
output
> termination.
> [CHG] You don't have to convince me it should be a context property. I'm
trying
> think of a work around given that we don't want a new version of
H.248/Megaco to
> introduce it. I don't see that having to send commands is a problem
because you
> can do that typically in one transaction and its an issue that we
currently have
> today. I'm not sure what you mean by "natural mapping?". Another question
I'm
> beginning to think about is do we want generic mapping per stream or by
> component. ie. two seperate input video streams output on a seperate
> termination. Is it still two streams at the output each displayed on a
different
> part of a monitor or one mixed stream? This is where we come back to
needing
> some sort of requirements showing exactly want principles and architecture
we
> want. We can then see whether context property, termination property or
mixing
> termination is needed.
> > > I'm talking now about a v.1 implementation, so the evolution path may
be
> > > an producing the  output stream ? It seems to required to open in
every
> > rtp
> > > termination 2 streams, 1 with only local descriptor (the input one)
and
> > one
> > > > representing them, a mixing unit represented by a mixing
termination,
> > > > streams and set the mode to receive only in the rtp terms, and
sendrecv
> > in
> > > > This looks weird but if the same stream id is used for input and
output
> > I