Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 22 Jan 2004 13:22:07 -0500

Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way the
MG can know ahead of time that the MGC supports the package in question.
 
Basically, the MG can have events provisioned, but all bets are off as to
whether the MGC will accept or reject the event.  My personal feeling is
that MGCs should ask for events they wish to see, and not rely upon any
"event provisioning".
 
Kevin

  _____  

From: Aleksandr Ryabin [mailto:[email-masked]] 
Sent: Thursday, January 22, 2004 11:19 AM
To: [email-masked]; [email-masked]
Subject: Re: [Megaco] Can chp/mgcon event be persistent event?

Hi,

Persistent events in MGCP are defined by package specs.
Provisioned events in MEGACO are configured by an MG operator.
As for any descriptor default EventsDescriptor values can be
provisioned on MG to be non-empty.

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default value to

use in such cases, but of course can also be provisioned to something else
by an MG operator.

Regards,
        Aleks

At 03:20 PM 1/21/2004, Sampath Komanduri wrote:

Hi all,
It was my understanding that Megaco doesn't allow any persistent events. If
my understanding is correct... Could someone pls. clarify what the following
paragraph in H.248.10 mean?

ITU-T Rec. H.248.10 (07/2001) 1

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
This event occurs when the MG requires that the MGC start or finish load
reduction
towards the MG or to adjust the Load Reduction Percentage. The event is
ordered by the
MGC or provisioned.
                        EventsDescriptor Parameters: None
                        ObservedEventsDescriptor Parameters 
 
Thanks,
Sampath

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Sampath Komanduri" <[email-masked]>
Date: Thu, 22 Jan 2004 10:48:42 -0800

Aleks and Kevin,
Thanks for responding. I do understand that in the absence of MGC
requested event, if MG has to generate a notification, it would use
RequestID 0. However, I don't see anything with respect to RequestID 0
handling in the spec. other than the following text in Section 7.2.7:
    "Procedures for sending Notify commands with RequestID equal to 0
are for futher study."
 
a) What is the action *required* by the MGC upon recieving a notify with
requestID 0?
    1) Is MGC supposed to do what it would have done if it had
explicitly asked for the eventNotification? In our example, is MGC
"required" to take the *same actions* to reduce congestion on MG (upon
receipt of unsolicited notification) which it would have taken if MGC
had "solicited" the notification? OR
    2) MGC must just respond to the Notification and *not* do anything
with respect to helping MG in reducing the congestion.
    3) MGC can choose to *not* to even respond to the Notify? I hope
this is not the case, since it would result in a DISCONNECTED
association.
 
b) Which events qualify to be notified to MGC with RequestID 0?
    Only events on ROOT? Only event on ROOT and Analog lines? Any
events?
 
It would be good to see some supporting text in the Spec. if the authors
decide to leave the support of persistent events in Megaco.
 
Thanks,
Sampath

 -----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Thursday, January 22, 2004 10:22 AM
To: Aleksandr Ryabin; [email-masked]; [email-masked]
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

Provisioning something other than 0 will lead to rejection by the MGC.
Further, provisioning is done at the MG's own risk, as there is no way
the MG can know ahead of time that the MGC supports the package in
question.
 
Basically, the MG can have events provisioned, but all bets are off as
to whether the MGC will accept or reject the event.  My personal feeling
is that MGCs should ask for events they wish to see, and not rely upon
any "event provisioning".
 
Kevin

  _____  

Hi,

The only question here which RequestID to use for such pre-provisioned
events?
The common consensus on the list was that 0 is a reasonable default
value to 
use in such cases, but of course can also be provisioned to something
else
by an MG operator.

Regards,
        Aleks

Hi all,
It was my understanding that Megaco doesn't allow any persistent events.
If my understanding is correct... Could someone pls. clarify what the
following paragraph in H.248.10 mean?

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
 
Thanks,
Sampath

---

From: "Sampath Komanduri" <[email-masked]>
Date: Thu, 22 Jan 2004 10:48:42 -0800

Aleks and Kevin,

 
 
Thanks,
Sampath

 -----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Thursday, January 22, 2004 10:22 AM
To: Aleksandr Ryabin; [email-masked]; [email-masked]
Subject: RE: [Megaco] Can chp/mgcon event be persistent event?

 
Kevin

  _____  

Hi,

Regards,
        Aleks

Hi all,

4.2 Events
        4.2.1 MGCongestion
                Event name: MGCon
                        EventID: mgcon, (0x0001)
                        Description:
 
Thanks,
Sampath

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 22 Jan 2004 14:15:38 -0500

Hi Sampath,

a) MGC can ether accept it, i.e. 1), or reject with error 458 (Unexpected 
Event/RequestID).
b) Any

Regards,
         Aleks

At 01:48 PM 1/22/2004, Sampath Komanduri wrote:
>     "Procedures for sending Notify commands with RequestID equal to 0 are 
> for futher study."
>
>     1) Is MGC supposed to do what it would have done if it had explicitly 
> asked for the eventNotification? In our example, is MGC "required" to 
> take the *same actions* to reduce congestion on MG (upon receipt of 
> unsolicited notification) which it would have taken if MGC had 
> "solicited" the notification? OR
>     3) MGC can choose to *not* to even respond to the Notify? I hope this 
> is not the case, since it would result in a DISCONNECTED association.
>
>     Only events on ROOT? Only event on ROOT and Analog lines? Any events?
>
>Provisioning something other than 0 will lead to rejection by the 
>MGC.  Further, provisioning is done at the MG's own risk, as there is no 
>way the MG can know ahead of time that the MGC supports the package in 
>question.
>
>----------
>The only question here which RequestID to use for such pre-provisioned events?

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 22 Jan 2004 14:15:38 -0500

Hi Sampath,

Regards,
         Aleks