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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 13 Mar 2001 09:02:28 -0500

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: Wed, 14 Mar 2001 13:33:29 +1100

Unless provisioned otherwise I would imagine so.

Christian