Subject: Re: Adding Streams

From: [email-masked]
Date: Tue, 6 Mar 2001 09:36:40 +0530

In section 7.1.6 it is mentioned that

"Within a context, StreamID is a means by which
   to indicate which media flows are interconnected:  streams with the
   same StreamID are connected."

So only streams with same ID are interconnected.
In fact, the topology although defined on terminations makes it way into
the interconnection between streams.

"Rosen, Brian" <[email-masked]> on 03/05/2001 10:32:42 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Adding Streams

Suppose you create a context and add two terminations to it with
StreamId=1.  Then you add a third termination and specify
a media descriptor with StreamId=2.

Is the third termination connected to the other two on StreamId=1?

Are the first two terminations connected to the third on StreamId=2?

I think the answer is yes to both questions.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Mar 2001 08:02:57 -0500

I don't interpret this section as implying that if you don't
mention a stream that it is not connected.  For example, if
you create a context, put a termination in it, and set some
stream characteristics with Add, and then you subsequently
add another termination, but do not have any media descriptor
at all in the Add command, I think that termination is connected
to all of the streams in the context.

I think that it is Topology which could affect the connection
of terminations to streams.  By default, all terminations are
connected to all streams.  If the termination didn't implement
all the streams (like an audio-only termination in a multimedia
context), that is not an error, but with respect to the protocol,
it's "connected".

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 11:07 PM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: Adding Streams
> 
> 
> 
>

---

From: Dave Sclarsky <[email-masked]>
Date: Tue, 6 Mar 2001 15:45:36 -0500

Brian,

I agree, based on the sentence in 7.1.6 that says:
  Streams are created by specifying 
  a new StreamID on one of the 
  terminations in a Context.
It doesn't say that you must specify the stream ID on all terminations, just
one.

The 'side effect' of this, it seems, is that once you mention a new stream
ID on a TERMA, every termination in every context that TERMA is moved to
inherits that stream (until the stream is deleted, that is).

So, how do you delete a stream?

Dave Sclarsky
s-link corp.
[email-masked] 

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 8:03 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: Adding Streams

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Mar 2001 16:00:01 -0500

> So, how do you delete a stream?
Easy
7.1.6 Stream Descriptor 
    
   ....A stream is deleted by setting empty Local and Remote 
   descriptors for the stream with ReserveGroup and ReserveValue in 
   LocalControl set to "false" on all terminations in the context that 
   previously supported that stream.

---

From: Danny Levin <[email-masked]>
Date: Wed, 7 Mar 2001 09:57:59 -0500

Brian,

There is a clear specification in the spec. :

"StreamIDs are of local significance between MGC and MG and they are 
assigned by the MGC.  Within a context, StreamID is a means by which 
to indicate which media flows are interconnected:  streams with the 
same StreamID are connected."

What do you mean by T1 & T2 are connected with stream 3 ?
If T1 & T2 do not include stream 3 there is nothing to connect with 
(If you want to connect it with stream 1 or 2 why do you assign stream id 3
?)

The logic to put a termination with a stream id that is not connected with
any other termination is not in the scope of the spec.....

Danny Levin.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 8:12 AM
To: 'Christian Groves'
Cc: [email-masked]'
Subject: RE: Adding Streams

We have a major disconnect on what a stream is, and what multiple streams
in a context mean.

My view of streams is that a termination normally is connected to all
streams in a context.  The canonical example is a video conference, which
would have an audio stream, a video stream and a T.120 stream.  All
terminations
in the context are in all streams.

In your example, if T1 & T2 are connected to streams 1 & 2, then when you
add
T3, it is connected to streams 1 & 2 and if you then add stream 3, then
T1 and T2 are connected to stream 3.  

If you don't want streams 1 & 2 to be connected to T3, why are you putting
T3 in the context with T1 and T2?  By your argument, if I have T1 and T2
connected on stream 1 (forget stream 2 and 3), and Add T3 to the context
without any media descriptor, it is not connected to anything!

The example you used makes no sense -- if T1 is connected to stream 1 and
T2 is connected to stream 2, then there is no connection at all, you have
a bunch of one termination contexts.  If that is what you want, then use
separate contexts. 

Stream IDs exist so you can modify the properties of each stream
independently.
They don't imply which terminations are connected to which streams

All terminations are always on all streams in the termination.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 8:49 PM
> To: Rosen, Brian
> Cc: [email-masked]'
> The answer is ABSOLUTELY NO to both questions !!!!!!
> 
> Stream IDs relate the different streams on terminations.
> 
> Extend this a little:
> T1 and T2 have streams 1 & 2. Add T3 with stream 3. Should stream 3 be
> connected to 1 or 2? The MG can't possibly know. If you send 
> down 1 or 2
> it is completely unambiguous. The very reason we had stream 
> IDs was for
> this relation.
> 
> Christian
> 
> 
> 
> "Rosen, Brian" wrote:
> >

---

From: Dave Sclarsky <[email-masked]>
Date: Wed, 7 Mar 2001 14:26:08 -0500

> ....A stream is deleted by...on all terminations...

Is this a catch22?? 
If you MODify T1 to delete stream1, doesn't it automatically come back,
since it still exists on T2?

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 4:00 PM
To: 'Dave Sclarsky'; Rosen, Brian; [email-masked]'
Cc: img
Subject: RE: Adding Streams

Easy
7.1.6 Stream Descriptor

---

From: "Michael Brown" <[email-masked]>
Date: Thu, 8 Mar 2001 03:50:56 -0500

I think the following question points out the flaw of the proposed approach
that terminations in the initial example where a new termination specifying
stream 3 results in the existing terminations automatically creating stream
3 and the new termination inherently creates streams 1 and 2. Basically,
this (as others have pointed out) eliminates the ability for the MGC to
specify a selected set of streams from the full capability of a termination
while leaving the streams unaffected on other terminations in the context.

I think the intent of the quoted section of the spec about default behavior
is that if one adds a termination to an existing context WITHOUT specifying
any streams, then all active streams that can be supported by the
termination will be "connected". If the MGC specifies some subset of the
active streams for the added termination, then only those streams will be
"connected" together. If the MGC is so stupid (or unaware) as to specify a
stream that is not currently active in the context, then I believe that the
termination is added, but is left "unconnected". If the MGC intends that
stream 3 should be made active in the context, it should specifically modify
the existing terminations to add that stream to these terminations as
appropriate.

The bottom line is that I don't believe that the level of intelligence
required in the GW to work the way that has been proposed is appropriate.
The MGC should be aware of the capabilities of the terminations involved in
a context and should be responsible for directing the behavior in the GW
when selectively choosing a subset of capabilities which are to be applied.

Michael

One additional

-----Original Message-----
From: Dave Sclarsky [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 2:26 PM
To: 'Rosen, Brian'; [email-masked]'
Cc: img
Subject: RE: Adding Streams

Is this a catch22?? 

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 4:00 PM
To: 'Dave Sclarsky'; Rosen, Brian; [email-masked]'
Cc: img
Subject: RE: Adding Streams

Easy
7.1.6 Stream Descriptor

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 8 Mar 2001 10:29:54 -0500

I don't think there is any intelligence required to have the rule that all
streams are
connected to all terminations in a context.  It's a simple rule.
It could be, in some unusual systems, that there are terminations that can't
deal with all of the streams in a context.  An audio-only port in a
multimedia
flow, for example.  That shouldn't be an error, but logically, it's
connected to the stream,
it just doesn't pass that stream out.
 
If you don't specify a local/remote, you get what you would normally get
when
you don't specify a local/remote.  This takes us back to another thread -
must
you specify a local/remote for a physical termination when the termination
has no
options.  For example, a simple analog line on a simple media gateway has no
need to have a local/remote setting.  Even a T1 would not normally need
local/remote.
You need local/remote when you have RTP, or AAL2, or something that needs
addresses and options.
 
What do you expect to happen if you created an ephemeral, but did not
specify
a local/remote?  Do you get an error?   No packets would flow, of course,
but
is it an error?  I don't think so.
 
What do you do on a physical port that has no options when there is more
than one
stream?  Make up a null local/remote so you can specify a streamId?  This is
a common case, say a video conference end point.  The physical port has no
options, typically.  The ephemeral (the RTP flow) would have lots.
 
Now, where is the case where you explicitly DON'T want to have all streams
connected
to all terminations?  We can do this pretty easily the way sip does hold -
zero address.
I don't want the usual case to take the work so the unusual case can be
spiffy.
 
Brian

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:51 AM
To: [email-masked]'
Subject: RE: Adding Streams

Michael 

One additional 

-----Original Message----- 
From: Dave Sclarsky [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, March 07, 2001 2:26 PM 
To: 'Rosen, Brian'; [email-masked]' 
Cc: img 
Subject: RE: Adding Streams 

Is this a catch22?? 

-----Original Message----- 
From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, March 06, 2001 4:00 PM 
To: 'Dave Sclarsky'; Rosen, Brian; [email-masked]' 
Cc: img 
Subject: RE: Adding Streams 

Easy 
7.1.6 Stream Descriptor

---

From: Danny Levin <[email-masked]>
Date: Thu, 8 Mar 2001 11:35:57 -0500

Brian,
 
What is wrong with the following simple rule :
 
If you want a termination to be connected to a specific stream than add a
media descriptor for this stream to this termination 
(including stream id ; the default is streamid = 1).
If you don't have an address (local or remote)  than just leave it empty.
 
Danny.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 10:30 AM
To: 'Michael Brown'; [email-masked]'
Subject: RE: Adding Streams

 

 
Brian

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:51 AM
To: [email-masked]'
Subject: RE: Adding Streams

Michael 

One additional 

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

Is this a catch22?? 

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

Easy 
7.1.6 Stream Descriptor

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 8 Mar 2001 11:40:42 -0500

You can't have an empty Stream Descriptor.
 
You are suggesting
Add=foo{Media{Stream=2{}}
You can't do that.  You also can't say
Add=foo{Media{Stream=2{Local{}}}
 
And, why do you want to?  The normal case is all terminations get all
streams.
There are a few cases where you don't want that; make those the exceptions.
 
Brian

-----Original Message-----
From: Danny Levin [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 11:36 AM
To: 'Rosen, Brian'; 'Michael Brown'; [email-masked]'
Subject: RE: Adding Streams

Brian,

 
Danny.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 10:30 AM
To: 'Michael Brown'; [email-masked]'
Subject: RE: Adding Streams

 

 
Brian

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:51 AM
To: [email-masked]'
Subject: RE: Adding Streams

Michael 

One additional 

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

Is this a catch22?? 

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

Easy 
7.1.6 Stream Descriptor

---

From: "Michael Brown" <[email-masked]>
Date: Fri, 9 Mar 2001 06:07:23 -0500

I disagree that there is no intelligence in connecting terminations as per
the basic rule. Having said that, however, the point of my initial post was
not to suggest that the basic rule is too complex. To be completely clear, I
agree that adding a termination WITHOUT specifying a selected subset of
possible stream types results in all streams being connected as appropriate.
I also agree that for terminations that can't deal with all the streams in a
context (which I don't think will be that unusual) it would NOT be treated
as an error.
 
The objection that I was trying to voice is in the case proposed that
started this whole discussion. That example was not the basic case and
therefore, it is my contention that for the case proposed it shouldn't be
assumed that adding a termination which specifies a previously unknown
stream would result in all terminations in the context creating that stream
as well. I'm not suggesting it is an error to specify the previously unknown
stream (although I will say again that I think the MGC should be smart
enough not to do this).
 
Again, to be sure what I'm saying is clear, I do believe that the basic rule
where the MGC DOES NOT specify particular streams is appropriate. In the
case where the MGC DOES specify a subset of the streams supported by the
termination then only that subset should be acted upon by the MG.
 
Michael

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 10:30 AM
To: Brown, Michael [NC1:GW10:EXCH]; [email-masked]'
Subject: RE: Adding Streams

 

 
Brian

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:51 AM
To: [email-masked]'
Subject: RE: Adding Streams

Michael 

One additional 

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

Is this a catch22?? 

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

Easy 
7.1.6 Stream Descriptor

---

From: Dave Sclarsky <[email-masked]>
Date: Fri, 9 Mar 2001 12:03:27 -0500

I'm afraid that there is a fly in the ointment.
 
Take a look at the thread (00/08/29-00/09/06) titled 'Is Media required on
the Physical Termination/Default value f or M ODE' (and someone's corrected
title 'Is Media required on the Physical Termination/Default value for M
ODE' - notice the spaces).  The thread points out that the default value for
MODE in localControl is not defined in the spec.  There seemed to be
consensus at that time that the MG must have some legal value (to satisfy
audit) and that the natural default value is "inactive".
 
This breaks the simple case, since media cannot flow on a stream unless that
stream's MODE is set explicitly by the MGC.  It's not all bad news, because
it doesn't mean we need local/remote on physical terminations, we only need
localControl (i.e. no SDP needed when it doesn't apply)!
 
Can we fix this with text in the IG that states that the default for MODE is
inactive?  With that change, the MGC would be required to specify
localControl/Mode on every stream on every termination that it wants to
interconnect.
 
DaveS.

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Friday, March 09, 2001 6:07 AM
To: [email-masked]'
Subject: RE: Adding Streams

 
 
Michael

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 10:30 AM
To: Brown, Michael [NC1:GW10:EXCH]; [email-masked]'
Subject: RE: Adding Streams

 

 
Brian

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:51 AM
To: [email-masked]'
Subject: RE: Adding Streams

Michael 

One additional 

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

Is this a catch22?? 

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

Easy 
7.1.6 Stream Descriptor

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Mar 2001 11:08:57 -0500

I should have cut into this thread ages ago.  Brian's original question is a
bit metaphysical, like "If a tree falls in the forest and there is no one to
hear it, is there any sound?".  Streams are the means whereby individual
flows are directed.  Unless you explicitly specify a stream descriptor on a
given termination with a given streamID, the flows corresponding to that
streamID are inactive on that termination (Dave's point).  So if one
termination specifies stream 3 and the other(s) in the context do not (the
MOVE example earlier in this thread), that means stream 3 is dead-ended.
Until another termination is told to support it, there's no need to allocate
any resources to process it (which is probably what Brian was getting at).
By the way, I believe the spec. warns that the MGC should consider the
compatibility of streamIDs when moving terminations between contexts.

-----Original Message-----
From: Dave Sclarsky [mailto:[email-masked]]
Sent: Friday, March 09, 2001 12:03 PM
To: [email-masked]'
Subject: RE: Adding Streams

 

DaveS.

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Friday, March 09, 2001 6:07 AM
To: [email-masked]'
Subject: RE: Adding Streams

 
 
Michael

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 10:30 AM
To: Brown, Michael [NC1:GW10:EXCH]; [email-masked]'
Subject: RE: Adding Streams

 

 
Brian

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 3:51 AM
To: [email-masked]'
Subject: RE: Adding Streams

Michael 

One additional 

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

Is this a catch22?? 

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

Easy 
7.1.6 Stream Descriptor