Subject: [Megaco] MGC-MG dialogue failure detection

From: [email-masked]
Date: Fri, 5 Jul 2002 09:57:20 +0200

I would like to point out an issue which is as far as I know is not solved
in RFC3015.

I suppose that the  MG is registered to the MGC and that there is no
transaction on going.
If the MGC fails, there is no way for the MG to detect it when using UDP.

I have already seen two mechanisms implemented by stack vendors to solve
this issue :

1- Use of ping to detect that the correspondent is no more reachable
2- Use of a ServiceChange ROOT with termination = undefined as a  polling
mechanism

     * on MGC side if no response to the poll, return to initial state
waiting for a ServiceChange
        from the MG. Inform the Call Control that  the terminations are no
more usable
        to establish new calls

     * on MG side if no response to the poll, return to initial state and
try to retrieve the dialog
        by sending ServiceChange to the primary MGC  or to the secondary
MGC if it is provisioned.

I think that to avoid that everyone defines it own mechanism which can lead
to interoperabilty problems
it should be defined in the RFC.

Jean-Luc Lecuyer
--------------------------------------------------------------------------------------------
Jean-Luc Lecuyer :          VND/E10 VS  BU R&D/CCPD Lannion
Full telephone number :                                         33 (0)2 96 04 77 09
Full fax number :                                                        33 (0)2 96 04 72 35
Email :                                                         [email-masked]
---------------------------------------------------------------------------------------------

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

---

From: Dan Elbert <[email-masked]>
Date: Sun, 7 Jul 2002 10:17:03 +0300

Hi Rajeev
This are exactly the problems that the package is trying to solve.
If MGC detects that MG is not responding, just don't send any message to it
until it registers again.
Then when inactivity timer expires, MG send event, doesn't get a response,
and finally registers again.
Then same will happen to every MG when the MGC goes down and up again.

Dan Elbert
RADVISION

-----Original Message-----
From: Rajeev K R [mailto:[email-masked]]
Sent: Saturday, July 06, 2002 4:18 AM
To: [email-masked]; [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi Jean-Luc,

ITU-T SG16 has published a document named
H.248 Annex M.6: Inactivity Timer Package
which can be used by MG to detect the MGC failure.
MG can send Notify with event=it/ito and chcek whether MGC gives a response.
When there is no response for some number of attempts, MG can initiate
registration procedure.

From the MGC side the package suggest the use of Audit for ROOT with empty
descriptor.

But there is another problem, the standard still does not address. This is
more from a practicality
point of view. This is from the MGC side. Suppose the MGC detect that the MG
is not responding and
mark that this MG is unregistered.
Now how can the MGC inform the MG that its registration is removed ?
If the MG is actually down there is no problem because when the MG comes up
again, it will register.
If the MG is not down, it will never register again.
When it tries to initiate a call, it will get a response that the MG is not
registered.
Some MGs register again when they get this response, but some MGs do not.

Another scenario is where all the MGs are registered, but the MGC go down
and come up.
How can the MGC force the MGs to register again ?
Is the MGC allowed to use the previous state of registation(state before it
went down) for its MGs ?

Regards,
Rajeev

---

From: Dan Elbert <[email-masked]>
Date: Sun, 7 Jul 2002 10:17:03 +0300

Hi Rajeev

Dan Elbert
RADVISION

-----Original Message-----
From: Rajeev K R [mailto:[email-masked]]
Sent: Saturday, July 06, 2002 4:18 AM
To: [email-masked]; [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi Jean-Luc,

Regards,
Rajeev

---

From: "Harry Suede" <[email-masked]>
Date: Sun, 07 Jul 2002 22:22:45 +0800

Hi

Where can I find this document? I am unable to locate it.

Regards
Harry

----- Original Message -----
From: "Rajeev K R" <[email-masked]>
Date: Sat, 6 Jul 2002 09:17:32 +0800
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Megaco] MGC-MG dialogue failure detection

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8

---

From: "Harry Suede" <[email-masked]>
Date: Sun, 07 Jul 2002 22:22:45 +0800

Hi

Regards
Harry

---

From: [email-masked]
Date: Mon, 8 Jul 2002 16:29:38 +0200

You can find it at :

http://www.packetizer.com/iptel/h248/

Jean-Luc

Carl Rutter <[email-masked]>@ietf.org on 08/07/2002 16:19:19

Sent by:  [email-masked]

To:   "'Harry Suede'" <[email-masked]>, Rajeev K R
      <[email-masked]>, [email-masked]
cc:
Subject:  RE: [Megaco] MGC-MG dialogue failure detection

Same here,
Anyone know where we can get it?

Carl

-----Original Message-----
From: Harry Suede [mailto:[email-masked]]
Sent: Sunday, July 07, 2002 10:23 AM
To: Rajeev K R; [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi

Regards
Harry

----- Original Message -----
From: "Rajeev K R" <[email-masked]>
Date: Sat, 6 Jul 2002 09:17:32 +0800
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Megaco] MGC-MG dialogue failure detection

> > it should be defined in the RFC.
--------------------------------------------------------------------------
> ------------------
> > Full telephone number :                                         33 (0)2
96
> 04 77 09
--------------------------------------------------------------------------
> -------------------

---

From: Carl Rutter <[email-masked]>
Date: Mon, 8 Jul 2002 10:19:19 -0400

Same here,

Carl

-----Original Message-----
From: Harry Suede [mailto:[email-masked]]
Sent: Sunday, July 07, 2002 10:23 AM
To: Rajeev K R; [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi

Regards
Harry

----- Original Message -----
From: "Rajeev K R" <[email-masked]>
Date: Sat, 6 Jul 2002 09:17:32 +0800
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Megaco] MGC-MG dialogue failure detection

96

---

From: Carl Rutter <[email-masked]>
Date: Mon, 8 Jul 2002 10:19:19 -0400

Same here,

Carl

-----Original Message-----
From: Harry Suede [mailto:[email-masked]]
Sent: Sunday, July 07, 2002 10:23 AM
To: Rajeev K R; [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi

Regards
Harry

----- Original Message -----
From: "Rajeev K R" <[email-masked]>
Date: Sat, 6 Jul 2002 09:17:32 +0800
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Megaco] MGC-MG dialogue failure detection

96

---

From: [email-masked]
Date: Mon, 8 Jul 2002 16:29:38 +0200

You can find it at :

Jean-Luc

Same here,

Carl

-----Original Message-----
From: Harry Suede [mailto:[email-masked]]
Sent: Sunday, July 07, 2002 10:23 AM
To: Rajeev K R; [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi

Regards
Harry

----- Original Message -----
From: "Rajeev K R" <[email-masked]>
Date: Sat, 6 Jul 2002 09:17:32 +0800
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Megaco] MGC-MG dialogue failure detection

96

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 08 Jul 2002 12:59:00 -0400

Hi,

         One problem that inactivity package does not solve is a service 
interruption.
That is if a primary MGC fails (crashes) such that it can not send SC 
handoff to
MG and secondary MGC takes over right away then currently there is no way for
secondary MGC to let MG know that it is an active MGC now, since SC has to be
initiated from MG before any message is sent from new MGC. Thus using 
inactivity
package even if inactivity timer set to a minimum (10 msec) there will be 
still a service
interruption delay of at least Notify time-out period which counted in 
seconds and
which is a huge delay for real time systems. That is during this time 
(seconds) an
MGC acting as soft switch will not be able to establish new calls as well 
as modify
calls currently in progress.

One way to work around is to allow any provisioned MGC (e.g. primary, 
secondary,
etc.) to send SC handoff with its own MgcIdToTry at any point of time to 
take over.

Another way could be to extend inactivity timer package and add Notify 
time-out ("nto")
parameter to "ito" event with the same attributes as "mit" parameter which 
will allow MGC
to set time-out for Notify response which is send on "mit" expiration. This 
way MGC at
least will have control of maximum service outage a secondary MGC should 
expect on
a primary MGC permanent failure. More over it could be specified if "nto" 
parameter is
set to 0 then it would direct MG to start failover process as described in 
par 11.5 right
away on "mit" expiration without sending Notify to primary MGC.

Any comments, or other ideas regarding this problem?

Thanks
         Aleks

---

From: Carl Rutter <[email-masked]>
Date: Tue, 9 Jul 2002 15:31:54 -0400

I'll second the secondary MGC handoff approach.
Section 11.2 of the RFC indicates the 
Secondary's have to have been pre-provisioned
on the MG so not just any MGC could take over.

Carl

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:08 PM
To: Christian Groves; [email-masked]
Cc: Dan Elbert; 'Rajeev K R'
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi Christian,

         This still would not solve "software" fail over (e.g. MGC with 
different IP/port)
as it only will work for "hardware" (hot swap) fail over (e.g. MGC with 
same IP/port),
but then it has nothing to do with the protocol, since as you correctly 
pointed out
MG would not have to know about it.

         What I'm trying to find a solution for is a protocol supported way 
for such
a situation. That is if we can put into MEGACO some provisions to overcome
this bottleneck in the protocol itself.

         My proposals do not deal with "hot swap" mechanism since "hot swap"
does not have a problem as you correctly stated. The fact is that the
protocol
already have a handoff mechanism which already works in most scenarios. By
allowing initiating handoff from secondary MGCs would solve the bottleneck.
         The problem with this as I understand is that generally speaking 
MG is
the one that must initiate the control connection (specifically in case of 
TCP).
This also can be worked around by allowing MG to initiate control
connections
to all MGCs including secondary on startup, or some other time, before
the primary MGC failure occurs. Only one will be "active", the one to
current primary MGC thus control connection will be up by the time
secondary MGC will need to send handoff to itself.
         Of course this all can be defined as optional functionality to be
backward compatible.

         Does anybody have any strong objections on allowing secondary
MGCs to send handoff for itself and/or for MG to establish multiple control
connections?

Thanks
         Aleks

At 09:00 PM 7/8/2002, Christian Groves wrote:
>Hello Aleksandr,
>
>For the problem you describe I assume that you are talking about a very
large
>gateway (that is highly reliable) that would have many new call attempts 
>during
>the 10sec period.
>
>You can address the situation below in a number of ways.
>o Design your MGC so that it hot swaps to another MGC without the MG ever
>knowing. ie. use the same connection to the MG. This assumes that there
would
>have to be sharing of states/records between the 2 MGCs. This would
eliminate
>the problem completely.
>o Use a reliable transport ie. SCTP and set your timers quite tightly. This
>would minimise the problem.
>
>Through the development of Megaco/H.248 we stayed clear of using it as a
"hot
>swap" mechanism as this would lead us to make assumptions about the
>communication between MGCs which is rather out of scope of our charter.
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
> >
> > Hi,
> >
> > > > I think that to avoid that everyone defines it own mechanism which
can
> > >lead
> > > > Full telephone number :                                         33 
> (0)2 96
> > >04 77 09
> > > > Full fax number :
> > >33 (0)2 96 04 72 35
> > > > Email :

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 9 Jul 2002 16:08:14 -0400

Doesn't this open the possibility that a secondary MGC could take over from
a primary that isn't out of service, causing control conflicts?  If the
primary is in service, do we really want a secondary taking over?

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:08 PM
To: Christian Groves; [email-masked]
Cc: Dan Elbert; 'Rajeev K R'
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi Christian,

Thanks
         Aleks

large
would
eliminate
"hot
can

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 9 Jul 2002 16:08:14 -0400

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:08 PM
To: Christian Groves; [email-masked]
Cc: Dan Elbert; 'Rajeev K R'
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi Christian,

Thanks
         Aleks

large
would
eliminate
"hot
can

---

From: Carl Rutter <[email-masked]>
Date: Tue, 9 Jul 2002 15:31:54 -0400

Carl

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:08 PM
To: Christian Groves; [email-masked]
Cc: Dan Elbert; 'Rajeev K R'
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hi Christian,

Thanks
         Aleks

large
would
eliminate
"hot
can

---

From: Carl Rutter <[email-masked]>
Date: Tue, 9 Jul 2002 16:39:39 -0400

Yes,
 
The down side of this approach would put the burden on the Secondary MGCs to
make sure
IF they are doing a Handoff they are only taking over for a downed Primary.
But putting the decision making up in the MGCs, I believe, would be a useful
thing.
I think the Inactivity mechanism would still stand.  This would be another
way
of handling the Primary unexpectedly going down.

Carl

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 4:08 PM
To: Aleksandr Ryabin; Christian Groves; [email-masked]
Cc: Dan Elbert; 'Rajeev K R'
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Kevin 

-----Original Message----- 
From: Aleksandr Ryabin [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, July 09, 2002 1:08 PM 
To: Christian Groves; [email-masked] 
Cc: Dan Elbert; 'Rajeev K R' 
Subject: Re: [Megaco] MGC-MG dialogue failure detection 

Hi Christian, 

Thanks 
         Aleks 

large 
would 
eliminate 

"hot 

> > >From: Rajeev K R [ mailto:[email-masked] <mailto:[email-masked]>
] 

can 

<https://www1.ietf.org/mailman/listinfo/megaco>  
<https://www1.ietf.org/mailman/listinfo/megaco>  
<https://www1.ietf.org/mailman/listinfo/megaco>  
<https://www1.ietf.org/mailman/listinfo/megaco>  

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

---

From: Carl Rutter <[email-masked]>
Date: Wed, 10 Jul 2002 09:25:05 -0400

This is a good discussion,
We have been debating some of these
MEGACO issues for large Media Gateways
internally for awhile.

We have a very high density MG and some of the MEGACO
issues I run into are related to the fact that we have many,many
terminations.  ie) The Huge Reply thread for Wildcard Audits etc
                   currently under discussion
20,000+ terminations 
with 100 Calls Per Second not uncommon.

Christian brings up a valid point,
Maybe the thinking on this should be 
If a failover time of less than  (Notify Reply Timeout + retries) is desired
then the MGC should implement hot-swap.

Carl

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 10:16 PM
To: [email-masked]
Subject: Re: [Megaco] MGC-MG dialogue failure detection

Hello,

This has been discussed on multiple occasions. As Kevin points out having a
secondary take over causes control conflicts and opens up the chance that a
secondary MGC fraudulently takes over control.

The current handoff mechanism doesn't rely on shared state as the secondary
MGC
can always audit the MG to build state information. If you are not
implementing
hot swap on the MGC then I think this software handover is not practical if
the
MGC goes down unannounced. The call control messages will have to be
rerouted to
the new MGC which takes time. If the MGC/MG interface has sufficient load
the MG
will detect failure in a short period of time. Therefore any new call
attempts
are likely to be minimal.

Perhaps what we need are some real (or likely) figures on number of calls
attempts and hour, number of messages sent across the MGC/MG interface and
likely delay across the MGC/MG interface to see what the magnitude of the
problem actually is.

Regards, Christian

Aleksandr Ryabin wrote:
> 
> Hi,
> 
>         I agree that it is useful, I mean leaving up to MGCs to decide.
> More over I do not think that secondary MGC taking over will be a problem
from
> 
> synchronization point of view with primary MGC. In order to correctly to
take
> over
> even with a regular handoff initiated by primary MGC, both MGCs must have
the
> same state information, thus they must have some kind of synchronization
> mechanism in the first place to perform a regular handoff. Thus they
should be
> 
> always aware of who is current active MGC.
> 
> Thanks
>         Aleks
> 
> At 04:39 PM 7/9/2002, Carl Rutter wrote:
> 
> > Yes,
> >
> >      Doesn't this open the possibility that a secondary MGC could take
over
> >      from a primary that isn't out of service, causing control
conflicts?
> >      If the primary is in service, do we really want a secondary taking
> >      over?
> >      Kevin
> >
> >               What I'm trying to find a solution for is a protocol
supported
> >               My proposals do not deal with "hot swap" mechanism since
"hot
> >      swap"
> >      already have a handoff mechanism which already works in most
scenarios.
> >      By
> >      the one that must initiate the control connection (specifically in
case
> >      of
> >               Of course this all can be defined as optional
functionality to
> >      be
> >      >For the problem you describe I assume that you are talking about a
> >      very large
> >      >o Design your MGC so that it hot swaps to another MGC without the
MG
> >      ever
> >      >knowing. ie. use the same connection to the MG. This assumes that
> >      there would
> >      >o Use a reliable transport ie. SCTP and set your timers quite
tightly.
> >      This
> >      >Through the development of Megaco/H.248 we stayed clear of using
it as
> >      a "hot
> >      > >          One problem that inactivity package does not solve is
a
> >      service
> >      > > interruption.
> >      > > That is if a primary MGC fails (crashes) such that it can not
send
> >      SC
> >      > > handoff to
> >      > > MG and secondary MGC takes over right away then currently there
is
> >      no
> >      > way for
> >      > > secondary MGC to let MG know that it is an active MGC now,
since SC
> >      has
> >      > to be
> >      > > package even if inactivity timer set to a minimum (10 msec)
there
> >      will be
> >      > > still a service
> >      > > interruption delay of at least Notify time-out period which
counted
> >      in
> >      > > seconds and
> >      > > which is a huge delay for real time systems. That is during
this
> >      time
> >      > > (seconds) an
> >      > > MGC acting as soft switch will not be able to establish new
calls
> >      as well
> >      > > etc.) to send SC handoff with its own MgcIdToTry at any point
of
> >      time to
> >      > > least will have control of maximum service outage a secondary
MGC
> >      should
> >      > > expect on
> >      > > a primary MGC permanent failure. More over it could be
specified if
> >      "nto"
> >      > > >If MGC detects that MG is not responding, just don't send any
> >      message
> >      > to it
> >      > > >Then when inactivity timer expires, MG send event, doesn't get
a
> >      response,
> >      > > >Then same will happen to every MG when the MGC goes down and
up
> >      again.
> >      > > >MG can send Notify with event=it/ito and chcek whether MGC
gives a
> >      > response.
> >      > > > From the MGC side the package suggest the use of Audit for
ROOT
> >      with
> >      > empty
> >      > > >descriptor.
> >      > > >
> >      > > >But there is another problem, the standard still does not
address.
> >      This is
> >      > > >more from a practicality
> >      > > >point of view. This is from the MGC side. Suppose the MGC
detect
> >      that
> >      > the MG
> >      > > >Now how can the MGC inform the MG that its registration is
removed
> >      ?
> >      > > >If the MG is actually down there is no problem because when
the MG
> >      > comes up
> >      > > >When it tries to initiate a call, it will get a response that
the
> >      MG
> >      > is not
> >      > > >registered.
> >      > > >Some MGs register again when they get this response, but some
MGs
> >      do not.
> >      > > >
> >      > > >Another scenario is where all the MGs are registered, but the
MGC
> >      go down
> >      > > >Is the MGC allowed to use the previous state of
registation(state
> >      > before it
> >      > > > > I would like to point out an issue which is as far as I
know is
> >      not
> >      > solved
> >      > > > > in RFC3015.
> >      > > > >
> >      > > > > I suppose that the  MG is registered to the MGC and that
there
> >      is no
> >      > > > > transaction on going.
> >      > > > > If the MGC fails, there is no way for the MG to detect it
when
> >      > using UDP.
> >      > > > >
> >      > > > > I have already seen two mechanisms implemented by stack
vendors
> >      to
> >      > solve
> >      > > > > 2- Use of a ServiceChange ROOT with termination = undefined
as
> >      > a  polling
> >      > > > >         from the MG. Inform the Call Control that  the
> >      terminations
> >      > are no
> >      > > > > more usable
> >      > > > >         to establish new calls
> >      > > > >
> >      > > > >      * on MG side if no response to the poll, return to
initial
> >      > state and
> >      > > > >         by sending ServiceChange to the primary MGC  or to
the
> >      > secondary
> >      > > > > I think that to avoid that everyone defines it own
mechanism
> >      which can

---

From: Carl Rutter <[email-masked]>
Date: Wed, 10 Jul 2002 13:36:55 -0400

I may have stated this before but
If you have a standby MGC ready to take over (hot-standby)
one approach would be, when the Primary dies & this is detected
by the standby, is to keep the same IP address at the Primary
but just do a gratuitous ARP with the Standbys MAC address.

I know this is outside the scope of the proctocol and
I realize Alex is trying to accomplish a timely failover within 
the scope of the protocol but I figured I'd suggest it anyway.

Carl

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 1:18 PM
To: Carl Rutter; 'Christian Groves'; [email-masked]
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Hi,

         I have to agree with Christian that secondary MGC can always
audit instead of synchronizing with primary MGC and thus secondary
incidentally taking over might not be good for such MGCs since
secondary is not aware of the state of primary MGC. So for such
configurations it does make sense not to allow "secondary handoff".

         But if we are taking about "high density" then MGCs must
have some synchronization mechanism as it will not be an acceptable
delay for such a system to wait for MGC to gather the state information
using audits (it might take a while).
         Also I do not agree that software based "fault tolerance" for MGC
is not practical. A properly designed system with software based
"fault tolerance" can be 4 nines. Thus if secondary MGC is in a
"stand by" mode it can take over immediately when it detects
primary MGC failure, and yet the protocol currently is a bottleneck
for this.

         Perhaps to satisfy both cases MG should have a read/write
"acceptSecondaryHandoff" ROOT termination property (for example,
in inactivity package) which will direct MG to accept, or not to accept
handoff initiated from secondary MGCs. This way MG can be configured
for a specific configuration depending on type of controlling MGCs.
Since this property will exist for MGs that support this package
this approach is backward compatible and will not break any current
implementation.

Comments, please?

Thanks
         Aleks

At 09:25 AM 7/10/2002, Carl Rutter wrote:
> > >               This still would not solve "software" fail over (e.g.
MGC
>with
> > >      different IP/port)
> > >      as it only will work for "hardware" (hot swap) fail over (e.g.
MGC
> > >      the primary MGC failure occurs. Only one will be "active", the
one
> > >      MGCs to send handoff for itself and/or for MG to establish
multiple
> > >      control
> > >      > > initiated from MG before any message is sent from new MGC.
Thus
> > >      using
> > >      > > Another way could be to extend inactivity timer package and
add
> > >      Notify
> > >      > > >When there is no response for some number of attempts, MG
can
> > >      initiate
> > >      > > > > 1- Use of ping to detect that the correspondent is no
more
> > >      reachable

---

From: Carl Rutter <[email-masked]>
Date: Wed, 10 Jul 2002 13:36:55 -0400

Carl

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 1:18 PM
To: Carl Rutter; 'Christian Groves'; [email-masked]
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Hi,

Comments, please?

Thanks
         Aleks

MGC
MGC
one
multiple
Thus
add
can
more

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 10 Jul 2002 15:37:39 -0400

If you are already talking about building in state synchronization, then why
don't you build it hot-swap capability too?  Then this isn't a problem.

Even if we did decide to allow autonomous takeover, the takeover will be
delayed as security keys are exchanged, the communications link is set up,
and network latency works its magic.  For a high-density system, this is a
non-trivial delay, and will result in the loss of lots of messaging, or
enough delay that end users will terminate calls (and then reoriginate to
complain to the telco!)  So, this suggestion still doesn't solve the
problem, which is to eliminate the recovery delay inherent in a failure of a
primary.

If you are really serious about eliminating the delay altogether, I don't
see any way to do so without doing some kind of hot-swap function.  I have
serious reservations about allowing autonomous takeover by a secondary MGC.
This seems to me to be asking for security problems.  And you can be assured
that if we can conceive of a hole, it exists and will be exploited by
someone.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 1:18 PM
To: Carl Rutter; 'Christian Groves'; [email-masked]
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Hi,

Comments, please?

Thanks
         Aleks

MGC
MGC
one
multiple
Thus
add
can
more

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 10 Jul 2002 15:37:39 -0400

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 1:18 PM
To: Carl Rutter; 'Christian Groves'; [email-masked]
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Hi,

Comments, please?

Thanks
         Aleks

MGC
MGC
one
multiple
Thus
add
can
more

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 17:32:51 -0400

>don't you build it hot-swap capability too?  Then this isn't a problem.

State synchronization and hot-swap are two different animals.
The first can depend only on software support, while the second
heavily depends on hardware support.

I'd like to stress that "why not this or that" is not a question here.
We are not trying to solve MGC implementation issue, but rather
MEGACO protocol limitation issue.

I'm not trying to difficult on anything, but if group does consider this to
be an issue, then we should try to work on it to find a feasible solution.
So I guess what I should have had started from is set the question strait:
does the folks consider this as a protocol flaw or not?
If not, I'd like a courtesy of explaining to me on why it is not the
protocol issue. If yes, then lets work together to solve it.

>problem, which is to eliminate the recovery delay inherent in a failure of a

Again, these delay reasons are non MEGACO protocol related and
also I would seriously doubt usage of any network that can even
remotely be considered public for MGC - MG link on high-density
systems exactly for security and latency reasons. That is such
systems will always have private network dedicated to MGC-MC
signalling and thus signalling link will most likely never use any
security mechanism (e.g nether IPSec or AH). In "stand by" mode
communications links are always up and just "etchings" to be used :)
That is the moment secondary MGC is given "green" light it is
running at 100%, no delays.

Also if you are taking about establishing secondary MGC - MG
physical control connection (for example, in case of TCP) I believe I did
also propose that MG can (optionally) possibly establish it at the time
it establishes control connection with primary MGC. This also can be
controlled by some "establishSecondaryLinks=yes|no" ROOT property
(which can be defined lets say in inactivity package).

>that if we can conceive of a hole, it exists and will be exploited by

I don't see how is it even remotely can be a security related problem.
Your security concerns seem to contradict your wording above in previous
paragraph about exchanging security keys, etc. If you are saying that
somebody can spoof IP/port and security keys of secondary MGC
why can't that same somebody do the same for primary MGC?
I can not understand what is in allowing secondary MGC initiate
a handoff can pose a security risk?

Again, if MG is allowed to be configured to accept handoff initiation
from secondary MGC then primary MGC can make an intelligent
choice ether to allow it to MG, or not based on security,
density and any other factors the system is provisioned with.

Cheers.
         Aleks

---

From: Carl Rutter <[email-masked]>
Date: Fri, 12 Jul 2002 10:13:55 -0400

In Alex defense I would argue that the Secondary MGC Handoff
might be a good addition to the protocol.

I know security is the big concern on this approach but if the 
Secondary must be registered with the MG, the MG should
be password etc protected, so not just any MG could take over.
So I don't see too much down side from that aspect.
On the MGC side you might keep the HW simplier ie) Sun boxes
with no specialized HW.  If the secondary detects through 
its replication LAN that the Primary craped out he could quickly 
switch over.   This would be if you wanted seperate IP Addresses.
If you keep the same IP you wouldn't need this mechanism.

I'm in the MG domain but figured I'd give my two-cents on this.
Valid points on both sides.

Carl

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 11:13 PM
To: Aleksandr Ryabin
Cc: [email-masked]; Kevin Boyle; Carl Rutter
Subject: Re: [Megaco] MGC-MG dialogue failure detection

G'Day Aleks,

No, I still believe this is a non issue for the reasons and questions that
have
been
raised before.

Christian

Aleksandr Ryabin wrote:
> 
> Hi Christian,
> 
>          Yes it is to stop calls being dropped as well as calls already
> in progress to be processed.
> 
> Does it mean we identified the problem to be an issue in the protocol?
> 
> Thanks
>          Aleks
> 
> At 02:35 AM 7/11/2002, Christian Groves wrote:
> >G'Day Aleks,
> >
> >Please see my responses below.
> >
> >Regards, Christian
> >
> >Aleksandr Ryabin wrote:
> > >
> >[CHG] Its not as easy as that. For this issue implementation and protocol
are
> >linked. Some are saying there is no problem. You (I assume) because of an
> >implementation
> >choice are saying that it is a protocol limitation issue. Before we put
> >something into the main protocol we have to understand why it is needed
and in
> >what situations. Carl has given a good explanation of his MGC/MG system
> >and what
> >call load he is managing and the fact that he has gone for a "hot swap"
> >system.
> >If the main aim of the addition is to stop calls being dropped then fine.
But
> >if the fact that call control redirection means we can't get new calls in
that
> >time then the problem is a non-issue.
> >
> >...snip..

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 12 Jul 2002 12:52:06 -0400

Terry has made several good points here.  Pursuant to the "Who do I trust?"
question is that adding this functionality now allows an MGC that, until
that point had no communication with the MG to command that the MG terminate
its current control association, and establish a new one with the secondary.
This is currently unprecedented -- while MGCs can tell an MG to attempt a
control association with a different MGC, MGCs cannot currently order MGs to
establish control assocations with themselves.  This, essentially, is in
violation of the maxim that MGs establish control associations.  Even if you
work around that by having the MG "reregister" with the secondary, for all
intents and purposes, the MGC established the communications relationship.

I have to agree with Terry.  If an implementation needs the reliability to
withstand an MGC failure, then that requirement should be taken into
consideration in the development of the implementation, whether it be
through hardware or software.  Many people have worked very hard to keep the
protocol implementation-independent, and I believe that adding this
functionality would be a step in the wrong direction.  The protocol provides
error detection and recovery mechanisms.  If they are not suitable for a
particular implementation, then an avenue outside the protocol needs to be
explored.  I believe this problem is outside the scope of the protocol.

Kevin

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: Carl Rutter
Cc: 'Christian Groves'; Aleksandr Ryabin; [email-masked]; Boyle, Kevin
[NCRTP:3R90:EXCH]

Security is only one concern.  There is still the issue that MG would 
have two or more masters and cannot know who to trust.  Ideally MGC2 
doesn't try to take over unless MGC1 is failed, but detection of failure 
is never perfect (unless MGC1 and MGC2 are tightly integrated in which 
case fault-tolerant methods can work invisibly to MG) and so there is 
always the chance that MGC2 decides MGC1 has failed even though MG is 
still getting messages and responses from MGC1.  Who does MG trust if 
both MGC1 and MGC2 claim to be controlling it.

It seems reasonable to expect a protocol such as H.248 to deal with 
failure detection and recovery with times on same order as message 
retransmissions/timeouts.  This is what H.248.14 (Inactivity Timer 
Package) is intended to do.  I would argue that failure detection and 
recovery on shorter times, while desirable for some systems, should use 
a different mechanism (SCTP, fault-tolerant hardware, ...) rather than 
expect that the protocol can be modified to do this.

Carl Rutter wrote:

>>>>>If you are already talking about building in state synchronization,
>>>>>          
>>>>>
>>>then why
>>>      
>>>
>>>>>don't you build it hot-swap capability too?  Then this isn't a
>>>>>          
>>>>>
>problem.
>  
>

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 12 Jul 2002 12:52:06 -0400

Kevin

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:19 AM
To: Carl Rutter
Cc: 'Christian Groves'; Aleksandr Ryabin; [email-masked]; Boyle, Kevin
[NCRTP:3R90:EXCH]

--

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 15 Jul 2002 23:48:34 -0400

Speaking as a referee on this thread (which deals with a recurring theme), I
believe your package approach would be legitimate.  It clearly involves new
behaviour, but no new protocol elements, and it is not a threat to
interoperability: MGs not supporting the package would have well-defined and
appropriate behaviour and the network would survive, though perhaps with
additional lost calls.  If I were designing the package, I would postulate
the following requirement: that no handover to secondary occurs without
either the permission of the primary MGC or determination that it is
unreachable.

Whether you can get other vendors to adopt the package is another question.

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Friday, July 12, 2002 1:01 PM
To: Christian Groves; [email-masked]; Boyle, Kevin [NCRTP:3R90:EXCH];
Carl Rutter

Hi Christian,

> > >If the main aim of the addition is to stop calls being dropped then
fine.

And so I agreed, but now you are saying non-issue. I guess I was
reading it wrong in the first place, right? Or not?
It seem that it is turning into a word game :)

So to give it another spin, lets follow the other thread direction and set
the
requirements (again, some are given, some optional, or even questionable):

1. on primary MGC unexpected failure provide mechanism to minimize
service outage due to failure detection delay
2. maintain security requirements mandated by protocol
3. maintain consistently the rule of "one primary/active MGC"
4. provide backward compatibility
5. provide unified solution for all versions of protocol
6. provide protocol based solution for MGCs with different IP interfaces

So far the proposals are:

1. Christian G.: use outside protocol solution (e.g. "IP/port hot swap") to
mask primary MGC failure thus making it transparent to MG;

2. Aleks R: add "establishSecondaryLinks" and "acceptSecondaryHandoff"
ROOT properties to inactivity package to direct MG to establish secondary
control connections on startup and to allow handoff to be initiated from
secondary MGC .

Analysis of solutions:

1. "hot swap":
#1 - #5 - conforms, since MGC failover is transparent to MG;
#6 - does not conform, solution is out of scope of the protocol,
requires hardware support for MGC capable of hot swap of IP interface.

2. "secondary handoff":
#1 - conforms, no delay;
#2 - conforms, physical connection is established by MG on startup
depending on "establishSecondaryLinks" property setting;
#3 - conforms, there is only one primary/active MGC at any point of time,
if case of "incidental" handoff initiation from secondary MGC, on detection
primary MGC can regain control by initiating handoff;
#4 - conforms, MGs supporting the package which has new additional
ROOT properties can be configured to use the mechanism, the other
MGs can follow regular procedures with no changes, or functionality loss;
#5 - conforms, new properties defined in a package which can be
implemented for any version of the protocol;
#6. - conforms, solution realized as package in scope of the protocol,
MGCs can have different IP interface.

Analysis summary:

1. "hot swap" - conforms all requirements, but #6.
2. "secondary handoff" conforms all requirements.

Comments please?

Thanks
         Aleks

I addressed (or at least that what I think) all issues with the solution

At 11:12 PM 7/11/2002, Christian Groves wrote:
> > >[CHG] Its not as easy as that. For this issue implementation and 
> protocol are
> > >something into the main protocol we have to understand why it is 
> needed and in
> > >If the main aim of the addition is to stop calls being dropped then 
> fine. But
> > >if the fact that call control redirection means we can't get new calls 
> in that

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 15 Jul 2002 23:48:34 -0400

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Friday, July 12, 2002 1:01 PM
To: Christian Groves; [email-masked]; Boyle, Kevin [NCRTP:3R90:EXCH];
Carl Rutter

Hi Christian,

fine.

Analysis of solutions:

1. "hot swap":

2. "secondary handoff":
#1 - conforms, no delay;

Analysis summary:

Comments please?

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 16 Jul 2002 11:17:24 -0400

Hi Tom and list,

         Yes, you have a perfect wording, this is exactly the intention:
"that no handover to secondary occurs without either the permission
of the primary MGC or determination that it is unreachable."
And it makes it even more sense to add these properties to the inactivity
timer package since it is the one that helps to detect "unreachable" case.

Does anybody else have comments and/or agree/disagree with it?
I'm sure that everybody kind of sick of this thread :) so I'd like to
bring it to some kind of consensus/agreement.

Thanks.
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 16 Jul 2002 18:28:16 -0400

Note: This is a resend, the list did not let email through because of its size.
I've truncated the end. My apologies if you are getting this twice.

Hi Kevin,

         Can you please clarify what "autonomous secondary takeover" 
exactly means?

I do not understand how handoff initiated by secondary MGC principally 
different from handoff
initiated by primary MGC assuming physical connections are already 
established between MG
and its MGCs (based on establishSecondaryLinks property)? The only 
difference is a time of
"authorization" to send SC handoff from MG to MGC.

In regular case (handoff initiated from primary MGC) this "authorization" 
is given at the point when
primary MGC sends SC handoff to MG, that is right before MG sends SC 
handoff to secondary MGC.

In this new proposal that "authorization" is still given by primary MGC, 
but at the point when
it sets acceptSecondaryHandoff  property. Thus when later secondary MGC 
initiates handoff
(that is it sends SC handoff with ServiceChangeMgcId set to itself) it 
merely serves as an
indication to MG to start handoff procedure (which is the same as SC 
handoff from primary MGC)
since "authorization" is already in place, thus MG starts handoff procedure 
and sends SC handoff
to secondary MGC.

In ether case MG establishes physical connections.
In ether case primary MGC controls handoff "authorization".
In ether case SC handoff is sent to secondary MGC from MG
and thus control connections in ether case established by MG.

Thanks
         Aleks

At 02:52 PM 7/16/2002, Kevin Boyle wrote:

>I still don't see how autonomous secondary takeover doesn't violate the 
>principle that MGs establish control associations, and not the other way 
>around.  That, alone, is a significant strike against this idea, let alone 
>the fact that, as Terry has pointed out, there doesn't seem to be any 
>outage reduction.
>
>Kevin
>
>From: Terry L Anderson [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Tuesday, July 16, 2002 2:37 PM
>To: Aleksandr Ryabin
>Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; Boyle, Kevin
>[NCRTP:3R90:EXCH]; Carl Rutter
>I am assuming that primary and secondary probe each other for liveness
>over the network (presumably more often than MG probes), and there is
>the case where MG can reach both MGCprim and MGCsec but due to some
>router failure MGCsec cannot reach MGCprim and so concludes that it is
>dead.  I believe that this case is possible but I suppose that it is not
>real common since a path between MGCprim and MGCsec must exist through
>MG's local router except when the paths are over half the max hop count
>limit (and if the hop count is that hight the network may be too poor of
>quality to be acceptible for VoIP anyway).
>
>In this case, however, each MGC believes the other is dead and will yank
>the MG back and forth unless, as you suggest, they detect this rapid
>alternation state and take some other corrective action.  Of course each
>may be very busy auditing its "new MG" to determine the state of all its
>calls.
>
>I just wonder how the MGCs monitor each other reliably significantly
>faster than the MGs can monitor.  Are you just counting on the number of
>monitors being much smaller (list of secondaries rather than all MGs) so
>that the polling frequency can be higher or are you primarily interested
>in the case where MGC are colocated and polling over LAN or even
>backplane connections?
>
>Aleksandr Ryabin wrote:
>
> > As previously was noted on this thread there is a possibility of
> > "unexpected"
> > (for primary MGC) handoff from secondary MGC. In this case primary MGC
> > will loose control (that is MG will reject messages with error 505).
> >
> > Ideally this would not happen since if the mechanism is used (e.g primary
> > MGC explicitly sets acceptSecondaryHandoff to yes) then MGCs better
> > have these "some means" to detect each other run status, otherwise
> > secondary MGC would not know when to initiate handoff in the first place.
> > But even if in this case "incidental" handoff is initiated by
> > secondary MGC,
> > primary MGC can regain control on the very next send since its very next
> > message to MG will fail with error 505, thus primary now has turned into
> > secondary and thus it can initiate handoff to regain control (if
> > necessary).
> > One can say this can then potentially turn into a race. The answer is in
> > word "incidental": that is normally MGCs will correctly identify each
> > other
> > run status and if "incidental" handoff detected MGCs will take steps
> > to report it via some management mechanism and correct as needed.
> > All this can be documented in "procedures" of the package.
> >
> >         Aleks
> >
> > At 01:27 PM 7/16/2002, Terry L Anderson wrote:
> >
> >> Oh.  I didn't catch that.  So that still does not solve the issue of
> >> whether the secondary's detection of primary's failure is correct.
> >> We still have the issue that the primary may still think it is in
> >> control and send transactions.  I assume that primary should not send
> >> acceptSecondaryHandoff unless it knows that it and the secondary can
> >> reliably agree about failure (through some means that I cannot
> >> imagine unless they are colocated) or is willing to tolerate false
> >> handoffs. Does the MG reject transactions from the primary (if they
> >> arrive) after such a handoff?
> >>
> >> Aleksandr Ryabin wrote:
> >>
> >>> "Permission of the primary" happens in advance by setting
> >>> acceptSecondaryHandoff
> >>> property from primary MGC on its startup, that is upon its initial
> >>> registration with MG.
> >>> Thus when later handoff is initiated by secondary MGC it is ether
> >>> allowed, or not
> >>> depending on current value of acceptSecondaryHandoff.
> >>>
> >>>         Aleks
> >>>
> >>> At 12:56 PM 7/16/2002, Terry L Anderson wrote:
> >>>
> >>>> I am not sure how this helps.  If the primary is dead (but not yet
> >>>> detected by the MG) and the MG receives some sort of indication
> >>>> from the secondary that it wants to take over, the suggested
> >>>> language would still require the MG to determing that the primary
> >>>> is "unreachable".  This would involve sending a message and waiting
> >>>> for it to timeout (or possibly getting an ICMP error).  If it must
> >>>> wait for a timeout then we have a delay very similar to that
> >>>> currently required in the Inactivity Timer package.  The only
> >>>> difference would be to stimulate something similar to the it/ito
> >>>> event immediately rather than waiting the normal mit time.  But is
> >>>> that really enough faster to be worth the effort? "unreachable"
> >>>> would still be determined only after T-MAX (see D.1) or about 6
> >>>> sec.  In a high rate MG, I would assume many would set the mit
> >>>> value to 1 sec or so and so we are only talking about 6 vs 7 sec or
> >>>> some similar small difference.  The only exception is where the
> >>>> connection to the primary has failed in such a way the the network
> >>>> will give a more immediate ICMP error (host unreachable) so that
> >>>> one does not have to wait for retransmisison timeout, but in
> >>>> practice I believe that this is not often the case.
> >>>>
> >>>> Aleksandr Ryabin wrote:
> >>>>
> >>>>> Hi Tom and list,
> >>>>>
> >>>>>> From: Aleksandr Ryabin 
> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 16 Jul 2002 18:28:16 -0400

Hi Kevin,

Thanks
         Aleks

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Jul 2002 09:41:57 -0400

Resend, because the message was too big for the list:

I still don't see how autonomous secondary takeover doesn't violate the
principle that MGs establish control associations, and not the other way
around.  That, alone, is a significant strike against this idea, let alone
the fact that, as Terry has pointed out, there doesn't seem to be any outage
reduction.

Kevin

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Jul 2002 12:46:49 -0400

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 6:04 PM
To: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]
Cc: Terry L Anderson; Taylor, Tom-PT [CAR:B602:EXCH]; Carl Rutter
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Hi Kevin,

        Can you please clarify what "autonomous secondary takeover" exactly
means?

[KBJII] This means exactly what you are proposing -- a secondary MGC taking
over control of an MG of its own volition.

[KJBII] So, an MG has to maintain two (or more) control associations at the
same time?  If an MG has one primary and four secondaries, does that mean it
needs 5 control associations?  How does the MGC know that it is a secondary
versus a primary?  If it is one of several secondaries, how does it know
that its turn has come to assume control?  What if two secondaries try to
take control at the same time?  How does an MG register with a secondary
without it assuming control at registration?

In regular case (handoff initiated from primary MGC) this "authorization" is
given at the point when
primary MGC sends SC handoff to MG, that is right before MG sends SC handoff
to secondary MGC.

In this new proposal that "authorization" is still given by primary MGC, but
at the point when
it sets acceptSecondaryHandoff  property. Thus when later secondary MGC
initiates handoff
(that is it sends SC handoff with ServiceChangeMgcId set to itself) it
merely serves as an 
indication to MG to start handoff procedure (which is the same as SC handoff
from primary MGC)
since "authorization" is already in place, thus MG starts handoff procedure
and sends SC handoff 
to secondary MGC.

[KJBII] This proposal mandates that an MG has to maintain more than one
control association.  This is additional overhead on the MG that hasn't
previously existed.  Why should I, as a hypothetical MG vendor, have to
expend the resources to be able to maintain two communications links, when
the protocol provides a method wherein I have redundant MGCs and only need
one link?  I think allowing more than one control association is a BAD idea
-- this allows the secondary to do anything it wants with the authority of
the primary.  This is asking for trouble.  If the MG doesn't have to
maintain multiple control associations, then the secondary MGC will have to
send unsolicited control messages to the MG.  This means that the MG becomes
an acceptor of control associations -- something that has been very
deliberately avoided to date.

[KJBII] Now, as Tom said, you can design a package if you like -- no one can
stop you from doing that.  But I feel this is not something that should be
in the base protocol, and should not be added to the current packages.  I
continue to have strong reservations about this idea.  Security continues to
be a concern, as does the lack of a guarantee that a secondary won't take
over for a primary that is still functioning.  The multiple control
association idea seems to me to be a fundamental shift in the way H.248
currently operates -- one that may have serious repercussions that are, as
yet, unexplored.

Thanks
        Aleks

Kevin

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Jul 2002 12:46:49 -0400

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 6:04 PM
To: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]
Cc: Terry L Anderson; Taylor, Tom-PT [CAR:B602:EXCH]; Carl Rutter
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Hi Kevin,

Thanks
        Aleks

Kevin

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 17 Jul 2002 14:54:39 -0400

Hi,

         I believe your original concern was that this new proposal is 
violating
"principle that MGs establish control associations". Thus my comments
and questions were directed to address that particular concern.

I'd like to clarify my understanding of "control association". Generally
speaking it is made up of two parts. Once part is a "physical" protocol
connection, if any, and another is "logical" (internal to Megaco) connection
(a tunnel) which is designated to provide a control. "Control association"
is not complete until both of its parts are in place.

With these basics the "principle that MGs establish control associations"
comes down to the fact that MG has to make physical connection (such
as TCP connection) as well as it has to make logical connection by sending
registration SC to MGC.

With this new proposal this is exactly the way it is done. Physical
connections  are established on startup (if requested) by MG. Logical
connection is established on startup only to primary MGC. Thus there
is only one established "control association" at any given time.

Once could ask: what about SC handoff sent from secondary MGC?
How can it send SC to MG without control connection?
My answer is even though it does look like it tries to send a command
without a "logical" connection established, but in its essence it is not a
control message to MG. It is simply an indication to MG that it can go
ahead and establish that "logical" connection. It is no more of a control then
MG deciding on its own to initiate handoff because of some other criteria
(e.g timer expired). In any case MG would have "decided" to send SC
handoff to that secondary MGC. If there are more then one secondary
MGC then the idea can be perfected and mastered to design an optimal
algorithm (but we are not at the point to do it yet).
This is my answer/opinion only and anybody can certainly disagree
(for whatever reason, and I'd like to hear it please).

With all that said the base line there is only one "control association"
at any point of time. No confusions from MG on this.
Maintaining multiple "physical" might be an additional resources, but
this is a implementation specific issue and thus out of scope.

With comments above and looking in to your comments below I believe
I have provided enough evidence that new proposal does not violate
"principle that MGs establish control associations" since control
associations are established by MG. Do we have consensus on that?

Regarding "Why should I, as a hypothetical MG vendor" do this or that.
It is up to an MG vendor to implement a proposed package.
Since it is package,  by its nature it is optional.
All a package provides is a protocol based solution to a
particular problem. If that problem is essential for a vendor then
the package has to be implemented with all its requirements.

The only reason I'm arguing for a package solution is from version
compatibility and vendor interoperability point of view. Every vendor
can choose to solve an issue using some other "non-standard"
means and thus will loose interoperability benefit. On the other
hand if we do have a protocol "approved" way then vendor "A"
can implement an MG, while vendor "B" can implement MGC
independently and yet work with each other (ideally) seamlessly.
That is a principle of a protocol.

Regarding security. Security concerns have been raised multiple
times and I do believe I have tried to address all of them and yet
you still imply that there is some "security problem" in the proposal.
Can you please clarify on where exactly do you see security flaws
in the proposal.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 17 Jul 2002 14:54:39 -0400

Hi,

Thanks
         Aleks

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 01:37:36 -0400

That isn't really what I had in mind.  Operating the way you propose is
really risky.  I speak from our early experience in a similar situation.

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 1:07 PM
To: Terry L Anderson
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; Christian Groves; [email-masked];
Boyle, Kevin [NCRTP:3R90:EXCH]; Carl Rutter
Subject: Re: [Megaco] MGC-MG dialogue failure detection

"Permission of the primary" happens in advance by setting 
acceptSecondaryHandoff
property from primary MGC on its startup, that is upon its initial 
registration with MG.
Thus when later handoff is initiated by secondary MGC it is ether allowed, 
or not
depending on current value of acceptSecondaryHandoff.

         Aleks

At 12:56 PM 7/16/2002, Terry L Anderson wrote:
>detected by the MG) and the MG receives some sort of indication from the 
>secondary that it wants to take over, the suggested language would still 
>require the MG to determing that the primary is "unreachable".  This would 
>involve sending a message and waiting for it to timeout (or possibly 
>getting an ICMP error).  If it must wait for a timeout then we have a 
>delay very similar to that currently required in the Inactivity Timer 
>package.  The only difference would be to stimulate something similar to 
>the it/ito event immediately rather than waiting the normal mit time.  But 
>is that really enough faster to be worth the effort? "unreachable" would 
>still be determined only after T-MAX (see D.1) or about 6 sec.  In a high 
>rate MG, I would assume many would set the mit value to 1 sec or so and so 
>we are only talking about 6 vs 7 sec or some similar small 
>difference.  The only exception is where the connection to the primary has 
>failed in such a way the the network will give a more immediate ICMP error 
>(host unreachable) so that one does not have to wait for retransmisison 
>timeout, but in practice I believe that this is not often the case.
>
>Aleksandr Ryabin wrote:
>
>>Hi Tom and list,
>>
>>> > > >linked. Some are saying there is no problem. You (I assume) because
of
>>>an

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 01:37:36 -0400

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 1:07 PM
To: Terry L Anderson
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; Christian Groves; [email-masked];

         Aleks

of

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 01:55:08 -0400

I agree that there is a problem at the transport level, to start with.  What
if the secondary uses the wrong kind of transport for the gateway?  That
said, if the secondary does get a message to the MG, that message has to be
viewed as a request for the MG to initiate a new control association, rather
than an initiation from the MGC end.  At the very least, it will require a
novel interpretation of (most likely) the ServiceChange command.

-----Original Message-----
From: Boyle, Kevin [NCRTP:3R90:EXCH] 
Sent: Tuesday, July 16, 2002 2:52 PM
To: Terry L Anderson; Aleksandr Ryabin
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; Carl Rutter
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Kevin

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 01:55:08 -0400

-----Original Message-----
From: Boyle, Kevin [NCRTP:3R90:EXCH] 
Sent: Tuesday, July 16, 2002 2:52 PM
To: Terry L Anderson; Aleksandr Ryabin
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; Carl Rutter
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Kevin

---

From: Carl Rutter <[email-masked]>
Date: Thu, 18 Jul 2002 09:59:03 -0400

Seems to me with all the objections to this approach
we should say, as stated before, If you want failover times less than 
the protocol timer timeouts
you need to implement a hotswap mechanism outside the scope of the 
protocol.
I don't think this is totally unreasonable because what we are saying
is,
"If for whatever reason a MGC or MG needs tighter time constaints than
the Protocol timers
it must resolve the issue outside the scope of the protocol."

Please don't shoot me but I wanted to bring up an issue that is somewhat
related to this thread.
We have run into several MGCs that have come from a MGCP backround and 
have implemented either
1) a "Multi-homed" MGC (They have one MGC with 2 IPaddresses)  They do
this for redundant routing purposes. Its 1 MGC not a primary and secondary.
or
2) Multiple MGCs with unique IP addresses that want to talk with 1 MG.
I know in the beginning of section 11 of the RFC its clearly stated this
is not currently supported.

I'm wondering would the group entertain supporting the notion of
multiple primary MGCs
talking to a MG in the future "again, please don't shoot me ;-)"

Thx,
Carl

-----Original Message-----
From: Boyle, Kevin [NCRTP:3R90:EXCH] 
Sent: Tuesday, July 16, 2002 2:52 PM
To: Terry L Anderson; Aleksandr Ryabin
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; Carl Rutter
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Kevin

---

From: Carl Rutter <[email-masked]>
Date: Thu, 18 Jul 2002 09:59:03 -0400

Thx,
Carl

-----Original Message-----
From: Boyle, Kevin [NCRTP:3R90:EXCH] 
Sent: Tuesday, July 16, 2002 2:52 PM
To: Terry L Anderson; Aleksandr Ryabin
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; Carl Rutter
Subject: RE: [Megaco] MGC-MG dialogue failure detection

Kevin