Subject: [Fwd: RE: Adding Streams]

From: Christian Groves <[email-masked]>
Date: Tue, 13 Mar 2001 15:10:44 +1100

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.