Subject: RE: [Fwd: RE: Adding Streams]

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Mar 2001 16:51:53 -0500

I personally think this sucks.
That means every add (every one!) needs to set mode.
Waste of time.  No value.  

This is the conjunction of two equally IN MY PERSONAL OPINION
AND IN THE MINORITY bad ideas:
    Subtract goes to boot state rather than last null state
    Mode defaults to inactive

Both are wrong, IMPO.
Given the current reality
	Examples must be changed
	Implementors beware

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2001 9:33 PM
> To: Rosen, Brian
> Cc: megaco ietf
> Subject: Re: [Fwd: RE: Adding Streams]
> 
> 
> Unless provisioned otherwise I would imagine so.
> 
> Christian
> 
> "Rosen, Brian" wrote:
> > 
> > Yes, but does mode change back from whatever it was to inactive
> > upon a subtract?
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Monday, March 12, 2001 11:11 PM
> > > To: megaco ietf
> > > Subject: [Fwd: RE: Adding Streams]
> > >
> > >
> > > Hello Dave,
> > >
> > > Section 1.4 of the implementors' guide additions covers 
> the default to
> > > "inactive".
> > >
> > > Christian
> > >
> > > -------- Original Message --------
> > > Subject: RE: Adding Streams
> > >    Date: Fri, 9 Mar 2001 12:03:27 -0500
> > >    From: Dave Sclarsky <[email-masked]>
> > >      To: "[email-masked]'" <[email-masked]>
> > >
> > >  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
> > >
> > >      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
> > >
> > >           I don't think there is any intelligence required to
> > >           have the rule that all streams areconnected to all
> > >           terminations in a context.  It's a simple rule.It
> > >           could be, in some unusual systems, that there are
> > >           terminations that can'tdeal with all of the streams
> > >           in a context.  An audio-only port in a
> > >           multimediaflow, 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 whenyou don't specify a local/remote.
> > >           This takes us back to another thread - mustyou
> > >           specify a local/remote for a physical termination
> > >           when the termination has nooptions.  For example, a
> > >           simple analog line on a simple media gateway has
> > >           noneed 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 needsaddresses and options.What do
> > >           you expect to happen if you created an ephemeral,
> > >           but did not specifya local/remote?  Do you get an
> > >           error?   No packets would flow, of course, butis 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 onestream?  Make up a null local/remote so you
> > >           can specify a streamId?  This isa common case, say a
> > >           video conference end point.  The physical port has
> > >           nooptions, typically.  The ephemeral (the RTP flow)
> > >           would have lots.Now, where is the case where you
> > >           explicitly DON'T want to have all streams
> > >           connectedto 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
> > >
> > >                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
> > >
> > >                > ....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
> > >
> > >
> > >                > 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.
> > >
> > >
> > >
> 
>