Subject: Re: Connection Changes At MG (was Basic Package and NAS)

From: Brian Rosen <[email-masked]>
Date: Wed, 13 Oct 1999 09:56:40 -0400

So you are asking for the following changes
        Subtract can be sent from MG to MGC, but not
        Add, Modify or Move
      Subtract has a new parameter, Statistics, that
          can only come from MG to MGC
        Statistics is not returned automatically if the MG
          is the command initiator, but it is if it is
          the command responder
        Statistics has a new parameter, cause code, which
          is used if MG is the command initiator, but not
          if it is the command responder

All so that you can avoid an event in the NAS package.

Not a good idea IMHO.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Wednesday, October 13, 1999 9:40 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Connection Changes At MG (was Basic Package and NAS)
>
>
> I don't think this is a change to the architecture. Again, it
> is included
> in all the MEGACO precursors. It was an oversight to remove this
> capability. It is absolutely not an error condition. It is
> normal operation
> for a NAS.
>
> Why can't the MG send a SUBTRACT to the MGC? I can't see any
> harm. The MGC
> will be able to keep state and the MG operations don't have
> to change.
> Along with sending the SUBTRACT to the MGC, the MG will add a
> StatisticsDescriptor with a simple cause code. The MGC can do
> whatever it
> wants with this information. This is of course optional. MG's
> that wish to
> remain dumb do not need to implement SUBTRACT.
>
>
> At 09:29 AM 10/13/99 -0400, Brian Rosen wrote:
> >I think it is unwise to change the architecture of the
> >protocol.  This is an error condition.  The problem is
> >completely solved by sending a Notify to the MGC, which
> >responds with a Subtract.  It is, admittedly, one extra
> >message and its ack, but it's an error condition!
> >
> >The MGC wishes to know WHY the MG wants the connection
> >taken down.  The MGC must go through all the work it
> >would do for a Subtract to get its state consistent.
> >The Notify is the most appropriate way to tell the MGC,
> >and Subtract is the most efficient way to get the connection
> >taken down on both sides.
> >
> >The current mechanism suffices, adding a new one doesn't
> >improve anything.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > Sent: Tuesday, October 12, 1999 9:08 PM
> > > To: [email-masked]
> > > Subject: Connection Changes At MG (was Basic Package and NAS)
> > >
> > >
> > > I see APC-1744 has been submitted to address the matter of
> > > MG-notified loss
> > > of connection.  I have also heard requests for the MG to be
> > > able to notify
> > > an MGC that a connection has changed, possibly as the result
> > > of an action by
> > > another MGC operating on that MG.  How do people feel
> about that one?
> > >
> > > Either of these notifications would have to be defined in
> a package.
> > >
> > > > -----Original Message-----
> > > > From: Matt Holdrege [SMTP:[email-masked]]
> > > > Sent: Tuesday, October 12, 1999 8:54 PM
> > > > To:   [email-masked]
> > > > Subject:      Re: AW: AW: Basic Package and NAS
> > > >
> > > > At 06:01 PM 10/11/99 -0400, Chip Sharp wrote:
> > > > >At 01:37 PM 10/11/99 -0700, Matt Holdrege wrote:
> > > > >>OK, now how about the case where one management entity
> > > owns the NAS and
> > > > >>another owns the MGC. The NAS manager may decide to kill
> > > a certain user,
> > > > >>but he has no way to send a command to an MGC to do this.
> > > > >
> > > > >The MGC would have to program the NAS to notify the MGC of
> > > this event.
> > > >
> > > > Do you have any technical reason for doubling up on the
> signalling
> > > > messages? What objection is there to sending a disconnect
> > > rather than a
> > > > notifcation to request a disconnect?
> > > >
> > > > >MGCP also had the capability of sending a Delete
> > > Connection from the MG
> > > > to
> > > > >the MGC to notify the MGC that a connection could not be
> > > maintained.
> > > >
> > > > So why object to having this in MEGACO?
> > > >
> > > > >In all the compromising and opposition to most things MGCP
> > > making it into
> > > > >the text, this capability did not seem to make it into megaco.
> > > > >
> > > > >It is too late for mere mortals to submit contributions to
> > > the Red Bank
> > > > >meeting (and this is the last meeting before the white paper is
> > > > >published).  However, the all-powerful, :-),
> rapporteurs can submit
> > > > >contributions whenever they wish.  Since the rapporteurs
> > > for Q13 and Q14
> > > > >work for Lucent perhaps you could convince them of the need.
> > > >
> > > > Surely you know that SG16 is pretty open about such things.
> > > You can count
> > > > on a contribution on this, Lucent or not.
> > > >
> > > > >You are correct that there are dozens (probably more) of
> > > such scenarios
> > > > >that need to be looked at for megaco and H.248.  It didn't
> > > seem like
> > > > there
> > > > >was much interest in megaco in NAS issues and the nasreq
> > > WG didn't seem
> > > > >interested either.  That is why I've said that there was a
> > > lot of work on
> > > > >NAS issues still to be done before it can really be supported.
> > > >
> > > > On the contrary. As the archives should show, I've stated
> > > clearly and
> > > > often
> > > > that NAS requirements for MEGACO are a subset of voice
> > > requirements. I
> > > > even
> > > > recall the chair agreeing with me on this. Nothing special
> > > needs to be
> > > > supported. This lack of a disconnect message seems to be an
> > > aberration
> > > > that
> > > > we need to fix.
> > >
>

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 13 Oct 1999 07:07:44 -0700

You are overstating the changes and understating the reasons.
It's really not a big change and I still haven't heard any
technical reason not to allow an MG to do this. Again, MG's
are not required to implement this.