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

From: David Dykhuizen <[email-masked]>
Date: Thu, 15 Mar 2001 16:27:44 -0600 (CST)

Along the same lines, we "always" have to send ReserveGroup and
ReserveValue as they are not "Optional" in the ASN.1, even when 
we have a stated default - this is a waste of time (no value).

ASN.1 Definition:

LocalControlDescriptor ::= SEQUENCE
{
    steamMode      StreamMode  OPTIONAL,
    reserveValue   BOOLEAN,
    reserveGroup   BOOLEAN,
    propertyParms  SEQUENCE OF PropertyParm,
    ...
}

Defaults defined in chapter 7.1.7, second to the last paragraph:

The default value of ReserveValue and ReserveGroup is False. ...

/David

==> 
==> 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.
==> > > >
==> > > >
==> > > >
==> > 
==> > 
==>

---

From: Christian Groves <[email-masked]>
Date: Fri, 16 Mar 2001 10:22:41 +1100

Yes. This has already been pointed out and will go into the
implementors' guide additions. Its an inconsistency between the
procedures and the ASN1.

Christian