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

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

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 06:40:04 -0700

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.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Oct 1999 08:26:57 -0700

Brian,

The main problem is that it's an error condition,
but there is no generic "error" event that can be
posted on the MG to catch all unexpected errors.
In order to make this work properly, the MGC would
need to post event requests for all error sources
-- which ought to be on a package basis -- and
listen for them.

I believe that Ericsson has a proposal for having
a generic error event. I haven't read it, but I
think it's intended for cause codes to be relayed.
If we expanded that to expect any out of band
error code (and probably allow packages to expand
the error code space), then MEGACO as it currently
stands might be made to work.

The only other option is to allow for the MG to do
subtracts with reason. This has the benefit of
cutting down on a half a round trip, but also has
the potential for abuse on the MG side (eg, the MG
subtracts because it's having a bad hair day).

I suspect that both are probably appropriate in
certain circumstances. If for no other reason, it
would probably be good for the MG to have a
catch-all way to alert an MGC that something is
dreadfully wrong/inconsistent with the
termination's state. This could be done with a
ServiceChange wink, but that seems rather heavy
handed.

Is there a real problem with allowing for both?

         Mike