Subject: RE: [Megaco] MGC failure and freeing MG resources - restart metho d

From: Dan Elbert <[email-masked]>
Date: Mon, 13 Aug 2001 09:25:43 -0500

Hi Madhubabu

In the spec the "failover" method is defined as "sent from MG to MGC to
indicate the primary MG is out
      of service and a secondary MG is taking over" and not when the MG
stays the same but the MGC changes.
The use of the "disconnect" method is apparently restricted to reconnecting
to the primary MGC. but is the only one that gives
the MGC an indication that connection was lost and state may be changed, so
the MGC can audit, etc. 
The alternative to using "disconnect" when contacting the secondary MGC
seems to be "Restart", in that case the MGC has no idea 
that something failed before.
In conclusion, seems like using "disconnect" should be better.

Regards,
Dan

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, August 10, 2001 7:03 PM
To: 'Dan Elbert'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources

Hi Dan/All,

As discussed in the "failure of MGC" thread, disconnected method will be
used by the MG to send the SVC on ROOT to the same controlling MGC. (True
even when MG retries with others, and they didn't respond , and the MG has
to start the cycle with the earlier controlling MGC). While trying with MGCs
other than the controlling MGCs the "failover" method is used.

Regards
Madhubabu

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Friday, August 10, 2001 6:02 PM
To: 'Madhu Babu Brahmanapally'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources

Hi

Well it could work that way and probably makes sense because if the MGC went
down without a "handoff" then chances
are that the secondary MGC doesn't have the updated state of the call
anyway.
By the way, how do you understand the "disconnected" method in SVC ? Is this
the method that the MG should use when contacting
a secondary MGC after losing contact with the first one, or only if succeeds
in reconnection with the primary one ?
If the later is true then the "Restart" method should be using when
connecting to MGC. Is this true ?

Dan

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, August 10, 2001 4:14 PM
To: 'Dan Elbert'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources

Hi Dan/All,
This is a good point to note. But how does the MG got to know about the MGCs
failure (It will definitely be through some response timeout for other
terminations, )in which case the MG has to register with its secondary MGCs.
IMHO while registering with secondary MGCs the state of the terminations in
the MG is same as when it registers for the first time (and the calls have
to be dropped, so does the resource clearing).  IMO except for the
disconnection method and MGC directed handoff method, in all other cases MG
has to take the terminations to their initial state.

Regards
Madhubabu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dan Elbert
Sent: Friday, August 10, 2001 3:09 PM
To: [email-masked]'
Subject: [Megaco] MGC failure and freeing MG resources

Hi
If the MGC fails in the middle of a call, does the MG needs to take some
responsibility for freeing up his
resources or it can assume that the secondary MGC (if it succeed in
contacting it) will be responsible
for either continuing the call or clearing resources? It seems better for
the MG to have some robustness
and clear the resources, but then the backup MGC cannot keep the call alive.
Any toughts ?

Dan Elbert
RADVISION

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

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

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

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Mon, 13 Aug 2001 11:41:07 -0400

HI Dan/All,
Its true that RFC 3015 mentioned as you said. But the latest Implementers
Guide lists the addition of the statement regarding the usage of "failover"
method as follows
"Sent from MG to next MGC on pre-provisioned list in the event of detected
failure of current MGC with a “MGC Impending Failure” reason."

Regards
Madhubabu

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Monday, August 13, 2001 10:26 AM
To: 'Madhu Babu Brahmanapally'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources - restart
method

Hi Madhubabu

Regards,
Dan

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, August 10, 2001 7:03 PM
To: 'Dan Elbert'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources

Hi Dan/All,

Regards
Madhubabu

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Friday, August 10, 2001 6:02 PM
To: 'Madhu Babu Brahmanapally'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources

Hi

Dan

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Friday, August 10, 2001 4:14 PM
To: 'Dan Elbert'; [email-masked]
Subject: RE: [Megaco] MGC failure and freeing MG resources

Hi Dan/All,

Regards
Madhubabu

-----Original Message-----

Hi

Dan Elbert
RADVISION

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 13 Aug 2001 11:30:30 -0400

>stays the same but the MGC changes.
IG item 6.81 added:
This serviceChange method is also sent from the MG to the MGC when the 
MG detects that MGC has failed

-- 
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