Subject: RE: [Megaco] Failure of MGC

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 27 Jul 2001 11:30:13 -0400

It was agreed in an earlier thread that a "Restart" implies full loss of
state -- the MG is coming up clean, with all physicals in NULL and no
ephemerals.

Kevin

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, July 27, 2001 11:20 AM
To:	Madhu Babu Brahmanapally
Cc:	'Terry L Anderson'; 'Kaul, Bharat'; [email-masked]
Subject:	RE: [Megaco] Failure of MGC

Hi Madhu, Tom, Brian,
As per the discussion going on over the list regarding the usage of "Service
Change Method", there is one thing still unclear as mentioned below.

In a service change command on ROOT termination, what does a METHOD field
actually convey i.e. either a change in the control association or the a
change
in the call state for all the associated terminations or both? For instance,
if
MG sends a Service Change command with "Restart" method on ROOT, does it
imply
that only the control association (re-registration) between MG and MGC is
affected or the call state of the associated terminations also change?

Regards,
Prashant

"Madhu Babu Brahmanapally" <[email-masked]> on 07/27/2001 08:04:15 PM

To:   "'Terry L Anderson'" <[email-masked]>, "'Kaul, Bharat'"
      <[email-masked]>
cc:   [email-masked] (bcc: Prashant Jain/HSS)

Subject:  RE: [Megaco] Failure of MGC

Hi Terry,
This is perfectly fine. If possible, text can be added related to the
Restart Method on ROOT termination from MGC(from the "ServiceChange Method
Usage" thread), if MGC specifies a ServiceChange Address, further requests
from the MG (Ex for Registration) will be sent to the newly specified
ServiceChange Address(If present). (I'm not sure if people have different
opinions, as the control association is broken, whether the MG should still
act on the (earlier controlling)MGC specified parameters).

Regards
Madhubabu

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, July 27, 2001 9:36 AM
To: Kaul, Bharat
Cc: Madhu Babu Brahmanapally; [email-masked]'
Subject: Re: [Megaco] Failure of MGC

"Kaul, Bharat" wrote:

> My comments are given below
>
> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 3:49 PM
> To: Madhu Babu Brahmanapally
> Cc: [email-masked]
>
> Let's discuss this before I write specific language.  I propose
> Graceful:  MG->MGC only
>
> [Bharat]  Alright with me
>
> Forced: MG->MGC & MGC->MG
> Restart: MG->MGC & MGC->MG
>
> [Bharat] What would be the difference between two methods when direction
is
> MGC->MG ?

Well I assume that the most common is MG->MGC.  MG signals that it wants
(local
GUI cmd or fault detected on TDM line, ...) to take one or more terminations
down.  It sends Forced or Graceful and then Restart when it wants them back
up.  MGC responds by Subtracting the terminations from any non-NULL Context
and
not Adding them.

I assume that some may want MGC to be able to also take lines out-of-service
(due to central mainenance decision, SS7 signaling, ...).  For most purposes
it
need not even inform MG, it simply Subtracts the terminations from any
non-NULL
contexts and avoids any Adds, but it may be useful to send Forced to the MG
to
make it aware that the lines are out of service.  This would be especially
useful for analog lines so the MG would not accept inbound calls (of course
turning off all events should accomplish this).  In any case there is little
the MG might do other than setting the state and replying with it to any
Audits.  But I see no reason to restrict it.

> Disconnected: MG->MGC only
>
> Handoff: MG->MGC & MGC->MG (as currently specified)
>
> [Bharat] Handoff from MG->MGC ? What does this mean ? So far I think
> specifications define handoff from MGC->MG only wherein MGC wants an MG to
> contact another MGC for further communication.

The current version H.248 states in the definition (I am not suggesting a
change):
    "Sent from the MG to the MGC, this indicates that the MG is attempting
to
establish a new association in accordance with a Handoff received from the
MGC
with which it was previously associated."

> Failover: MG->MGC only (only direction currently specified)
> [Bharat] This is ok.

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

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

---

From: Hariharasubramanian R <[email-masked]>
Date: Tue, 31 Jul 2001 15:00:06 -0500

Hello,

    I have a few questions/clarifications regarding Failure of MGC :

    All references are based on RFC 3015.

    (Q.1)    Section 11.4, second para: "Allowing the MGC to send
duplicate messages to *both* MGs accomodate pairs of MGs that are
capable of redundant failover ..."
            (*) In a scenario where providing MG fault tolerance is
intended, can one provision two virtual MGs in such a way that the one
acts as Active and another as Passive, (both provisioned with the same
semi-permenant terminations) ?
            (*) If so, will both the virtual MGs share the value of the
MID parameter ?

            (*) If the virtual MGs above are provisioned to have
different IP addresses, can I use the procedures in 11.4 as a
replacement for IP address takevover ?

            (*) How does the MGC learn about the *pair* of MGs capable
of redundant failover ? If *provisioning/management method* is the only
way, should we specify this explicitly (as for others) in the RFC ?

    (Q.2)    Section 11.5, last para: "Pairs of MGCs that are capable of
redundant failover ..." ::
            (*) Is this mechanism "intended" to be used in a situation
to run MGC in an Active/Passive mode so as to provide fault tolerance ?

TIA,

rhari !

--
!============================================================================!
= Hariharasubramanian R., Research Engineer, C-DoT, Bangalore.               =
= Call me at : OFF: 2383951(Dir) / 2263399 (268)                             =
=              RES: 3435971                                                  =
= Alternate email : [email-masked]                                      =
= Url: http://i.am/rhari                                                     =
!============================================================================!