Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t Ca ll - MGC failure)

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 May 2001 07:48:58 -0400

I don't think a restart of an already in service termination can imply loss
of state;
you would have to take it down and then bring it up to have loss of state.
 
I do think we want a real no-op, and not something that generates an error.
If you insist in can't be restart of an inservice termination, then we
should
add the no-op method.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 3:59 AM
To: Kevin Boyle; Dan Elbert
Cc: [email-masked]; 'Chuong Nguyen'
Subject: Polls of MGC (was RE: Implementors' Guide Update Editor's last Ca
ll - MGC failure)

Let's follow through the logic here.  A restart implies loss of state.  I
don't care whether you're talking ROOT or a real termination.  It would be
inconsistent to declare restart of the latter a no-op.

I'd suggest the safest poll would be a NOTIFY with no events and a bogus
requestID in it.  The MGC has to answer, even if only to return an error,
but the NOTIFY doesn't change anything.

> -----Original Message----- 
> From: Boyle, Kevin [NCRTP:3Z70:EXCH] 
> Sent: Monday, May 14, 2001 12:50 PM 
> To: Dan Elbert 
> Cc: [email-masked]; 'Chuong Nguyen' 
> Subject: Re: Implementors' Guide Update Editor's last Call - 
> MGC failure 
> 
> 
> Yes.  Root is a special case.  Restart on Root, if it is already in 
> service, implies that the MG has gone out of service and returned, and 
> that anything that was happening previously is lost.  This 
> was discussed 
> on an earlier thread. 
> 
> Kevin 
> 
> Dan Elbert wrote: 
> 
> > Well I was just following the logic that a restart of a termination 
> > already in service is a noop. Is the root termination a 
> special case ? 
> > . The problem with poll vs restart is the same in any case. 
> > 
> > -----Original Message----- 
> > From: Chuong Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Monday, May 14, 2001 12:22 PM 
> > To: [email-masked] 
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > 
> > To me definitely NOT. 
> > How will MGC knows that it is a registration restarts vs a poll? 
> > Don't tell me that one can use Reason Code since Reason 
> Code has to be 
> > IANA registered 
> > before it can be widely used. 
> > But since anyone can register w/IANA at any time, it only means that 
> > it might not be supported by 
> > everyone. 
> > 
> > Chuong 
> > 
> > Dan Elbert wrote: 
> > 
> > Another thing : Can I then use a restart of the "root" 
> termination to 
> > poll the MGC ? It seems to me more clean that to just use any 
> > termination. 
> > 
> > -----Original Message----- 
> > From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Monday, May 14, 2001 12:00 PM 
> > To: 'Dan Elbert'; [email-masked]'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > I think that a restart of a termination that is already in service 
> > should be treated 
> > 
> > as a nop by an MGC. 
> > 
> > I have no objection to adding an explicit no-op method, but I don't 
> > think it is needed. 
> > 
> > Brian 
> > -----Original Message----- 
> > 
> > From: Dan Elbert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Friday, May 11, 2001 5:57 PM 
> > To: [email-masked]'; 'Chuong Nguyen' 
> > Subject: RE: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > Using a fully specified terminationID can disrupt the 
> operation of the 
> > termination (for example if the termination is in a call). 
> > 
> > It's not clear what a "bogus" termination is, if the MGC receives a 
> > SVC from an MG termination it can assume that this 
> termination is real 
> > and start sending audits or commands. 
> > 
> > Yes, by poll I mean some type of heartbeat as the MG needs 
> to know if 
> > the MGC is alive. 
> > 
> > Brian Rosen suggested in the past to use SVC with Restart method for 
> > this purpose, I don't think that there was any mantion if 
> this should 
> > be done with id=root or other. 
> > 
> > Dan 
> > -----Original Message----- 
> > 
> > From: Chuong Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Friday, May 11, 2001 5:38 PM 
> > To: [email-masked] 
> > Subject: Re: Implementors' Guide Update Editor's last Call - MGC 
> > failure 
> > 
> > The intend was not to use ROOT but a fully specified 
> terminationID or 
> > even better a 
> > known invalid terminationID (A bogus terminationID that the sender 
> > knows is not valid and is 
> > used specifically for heartbeat purpose).  The idea is to get some 
> > kind of responses. 
> > 
> > "poll" do you mean heartbeat like msg to from MG to MGC or something 
> > else here. 
> > 
> > Where did you see that Restart w/ROOT is used as a heartbeat/poll? 
> > 
> > Chuong 
> > 
> > Dan Elbert wrote: 
> > Hi 
> > 
> > After reviewing the issue of MGC failure ( when the MG is connected 
> > trough UDP ) I believe that there is no satisfactory way 
> for the MG to 
> > poll the MGC to see if the MGC is still alive. Using a ServiceChange 
> > with "Restart" method and termination id of "root" may cause the MGC 
> > to assume that the MG restarted and can affect the state of 
> a call in 
> > progress. 
> > 
> > I think that it would be good to add a ServiceChange method "noop" : 
> > 
> > Noop : Can be used by the MG (with unreliable protocols) to obtain a 
> > response from the MGC or detect a communication failure. When 
> > receiving this SVC the MGC should take no action other that reply. 
> > 
> > If this is not acceptable, then I think that some clarification is 
> > needed as when a SVC with restart method should be considered "noop" 
> > by the MGC. 
> > 
> > Dan Elbert 
> > 
> > RADVISION 
> > 
> > -- 
> > 
> >   Alcatel USA, Inc             Internet: 
> [email-masked] 
> > 
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613 
> > 
> >   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> > -- 
> > 
> >   Alcatel USA, Inc             Internet: 
> [email-masked] 
> > 
> >   1000 Coit Road Plano, Texas 75075           Phone:    
> (972) 519-4613 
> > 
> >   **** The opinions expressed are not those of Alcatel USA, Inc **** 
> > 
> 
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 16 May 2001 02:47:21 -0400

I started to formulate a response along these lines myself yesterday.  I was
worried about event side-effects: they stop signals, and if you're in
Lockstep mode reporting of other events is delayed.  But there's a simple
answer to that: have the event reported from ROOT or from a special
termination like my NAS outgoing call termination. 

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2001 7:57 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]; Boyle, Kevin [NCRTP:3Z70:EXCH];
> Dan Elbert
> Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's
> las t Ca ll - MGC failure)
> 
> 
> If you don't want to create the noop method, we can go 
> back to a package.
> 
>    
>    PackageID: nop (0x00xx) 
>    Version: 1 
>    Extends: None 
>     
>    Description: No op event.  Can be used for testing or MG 
> poll of MGC. 
>     
> Properties 
>     
>    None 
>     
> Events 
>     
>    noop 
>    ----- 
>    EventID:     noop (0x0001) 
>     
>    No op event 
>     
>    Events Descriptor Parameters: 
>     
>         Interval 
>         ------------- 
>         ParameterID: delay (0x0001) 
>          
>         Description: delay in milliseconds to generate event.
> 	      if not specified, MG may choose any value. 0 implies
> 		 immediate response.  
>         Possible Values: INTEGER
> 
> Brian 
> 
> > > From: Chuong Nguyen [mailto:[email-masked]] 
> > > From: Rosen, Brian [mailto:[email-masked]] 
> > > From: Dan Elbert [mailto:[email-masked]] 
> > > From: Chuong Nguyen [mailto:[email-masked]]

---

From: [email-masked]
Date: Thu, 17 May 2001 09:42:26 +0530

Hi Tom, Brian

Following this thread of discussion.....
If we introduce an event "noop"...the MG is dependent upon MGC to enable this
event (by sending the event descriptor with noop event).
The very basic reason, as Dan and Chuong earlier pointed was that MG should be
able to "poll" MGC.
According to my understanding (please correct me if I am wrong) "polling" means
an action to be initiated by the MG independent of MGC enabling an event or not.
Hence, SVC (method - noop on root) seems to be a better idea than an event (noop
on root).

-Kapil Nayar
Hughes Software Systems

"Tom-PT Taylor" <[email-masked]> on 05/16/2001 12:17:21 PM

To:   "'Rosen, Brian'" <[email-masked]>, "Kevin Boyle"
      <[email-masked]>, Dan Elbert <[email-masked]>
cc:   [email-masked], "'Chuong Nguyen'" <[email-masked]> (bcc:
      Kapil Nayar/HSS)

Subject:  RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t Ca
      ll - MGC failure)

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 17 May 2001 04:22:24 -0400

It is essential that the MGC be able to control the process -- typically it
will have many MGs to manage, and must be able to keep the polling load down
to a tolerable level.  That's why I favour an event-based approach.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 12:12 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; Boyle, Kevin [NCRTP:3Z70:EXCH]; Dan Elbert;
> [email-masked]; 'Chuong Nguyen'

---

From: [email-masked]
Date: Thu, 17 May 2001 18:56:27 +0530

Hi Tom

I agree to your concern about keeping the polling load down to a tolerable
level.
But, I suppose the MG would send a "noop" SVC to MGC under the following
scenarios:
1.   MG timedout waiting for a reply from MGC.
     Normally, this case is handled by retransmission of the request before
interpretting that the MGC communication is lost.
     Some MG implementations might not want to resort to "noop" SVC at this
point and simply go on with recovery process after losing an MGC.
2.   MGC didnot send any request for a long time.
     MGC is not talking to this MG for a long time.....so anyhow this "noop"
should not contribute to load at MGC from this MG.
     Moreover, we can define a Base Root package property...."normalMGCIdleTime"
which indicates the timeout value for polling the MGC.
     This value would be read-write...provisioned at MG initially as well as
settable by MGC at run time....
     this will help MGC to indicate to MG whenever MGC wants to go idle so that
MG doesnot bother MGC by sending "noop" SVC.
3.......I could not think of any other scenario....

Well actually there is another positive feature....if we extend this "noop" SVC
to be sent by MGC to MG (and not just MG to MGC), we might be able to device a
method of polling MG from MGC perspective.....

-Kapil Nayar
Hughes Software Systems

---

From: Dan Elbert <[email-masked]>
Date: Thu, 17 May 2001 13:23:46 -0500

I think that using the "noop" SVC and having a Base Root package property to
control the polling is a good idea .

Dan Elbert
RADVISION

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 9:26 AM
To: Tom-PT Taylor
Cc: 'Rosen, Brian'; Kevin Boyle; Dan Elbert; [email-masked]; 'Chuong
Nguyen'
Subject: RE: Polls of MGC (was RE: Implementors' Guide Update Editor's las t
Ca ll - MGC failure)

Hi Tom

     Moreover, we can define a Base Root package
property...."normalMGCIdleTime"
     this will help MGC to indicate to MG whenever MGC wants to go idle so
that

Well actually there is another positive feature....if we extend this "noop"
SVC
to be sent by MGC to MG (and not just MG to MGC), we might be able to device
a
method of polling MG from MGC perspective.....

-Kapil Nayar
Hughes Software Systems