Subject: [Megaco] Actions at MG during MGC oveload

From: Rajeev K R <[email-masked]>
Date: Mon, 25 Oct 2004 17:32:06 +0100

Hi All,

Issue:
MGC is overloaded and has detected that a particular MG
(or rather subscribers on a particular MG) is placing lot of calls
and could be an apparent reason for the overload.
MGC wants to restrict the call rate from the MG.
MG terminations are supervised for offhook with embedded dial tone 
signal and digit collection on off-hook event detection.
So the MGC dos not issue a MOD command to MG
to play dial tone and collect digits. So obviously during the overload
situtaion
MGC do not want to control individual terminations to restrict the call rate
as it would deteriorate its load condition.

I thought of the following actions:
1. MGC modify the digitmap to allow only certain digit strings(like 911) to
be reported.
   This can be done for all terminations using wildcard so
   that this action does not impose burden on MGC.
   This is perfectly legal in H.248 so not much to discuss about this.

2. MGC instruct the MG to delay dialtone.
   This should be done in the embedded signal itself.
   Otherwise the MGC has to remove the embedded dial tone signal globally
   and delay the playing of dialtone for individual termination 
   by sending a delayed MOD(sig=dialtone) message.
   This would impose processing burden on the already overloaded MGC. 
   This can be done by defining a new signal DelayedDialtone with delay
parameter.
   This will be set globally replacing the normal cg/dt event.   

3. MGC instruct the MG to delay reporting of digit collection event.
   (Delaying off-hook event notification is not considered as the MGC need
to know
   this info immediately for termination state machine.
   A new event DelayedDigitmapCompletion with delay parameter will be
defined for this.
   This will be set globally replacing the normal dd/ce event.

4. Instruct the MG to ignore dialling events for a percentage of
terminations.
   A new property IgnoreDialPercentage will be defined for ROOT termination.
   The MG will ignore digits for a percentage of terminations.
   The algorithm at MG will be defined in the package so that a 
   subscriber is not denied service for a long time.  
   This could be coupled with playing a different tone than dialtone
   if the dialling is to be ignored for a termination.

5. Instruct the MG to ignore dialling events based on temination priority.
   A new property for physical terminations to indicate priority.
   This will be set by MGC based on subscriber information after MG restart
or when
   a new subscriber is provisioned in MGC.

   A new property IgnoreDialPriority will be defined for ROOT termination.
   MG will ignore the dialled digits for terminations if the termination
   priority is less than this ROOT property value.
   This could be coupled with pecentage , i.e a certain percentage of
subscribers
   below a certain priority would be denied service.
   This could also be coupled with playing a different tone than dialtone
   if the dialling is to be ignored for a termination.

6. Instruct the MG that MGC is overloaded and MG take the above actions by
itself.
   based on pre-provisioned values.
	
I would like to know whether the suggested actions contain any protocol
violation.
In all these actions, I am not giving the MG the freedom to decide anything
here.
Everything is still happening under the control of MGC.
Of course, except the percentage mechanism where the MG actually decides
who are the unfortunate subscribers. But still the action is initiated by
MGC.

I would espcially like to know whether MG actions like delaying event
reporting, 
delaying signal and ignore events selectively based on ROOT properties are
legal.
This solution need to be implemented across multiple vendors,
so I thought I better clarify all these before I proceed.

Thanks,
Rajeev

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