Subject: [Megaco] ServiceChange on Root termination

From: Raphael Tryster <[email-masked]>
Date: Mon, 4 Feb 2002 18:08:11 +0200

There seem to be some restrictions on valid combinations of ServiceChange
parameters, but I don't see it spelled out systematically.  For example, I
am interested in what methods are valid for a ServiceChange on Root sent
from MGC to MG.  Can the MGC send Restart, Graceful or Forced method for the
Root termination?  If so, what do they mean for individual terminations?

Raphael Tryster

---

From: [email-masked]
Date: Mon, 4 Feb 2002 22:56:11 +0530

Hi Raphael

We have tried to address some of the related issues in an internet draft. The
draft captures most of the scenarios involving handling of service change on
ROOT termination, The draft also conveys the semantics of the parameters of the
service change descriptor as asked by you.

The draft is placed on ietf site
http://search.ietf.org/internet-drafts/draft-hss-megaco-control-association-state-machine-00.txt

Regards
Vivek
HSS
www.hssworld.com

Raphael Tryster <[email-masked]> on 02/04/2002 09:38:11 PM

To:   [email-masked]
cc:    (bcc: Vivek Bansal/HSS)

Subject:  [Megaco] ServiceChange on Root termination

Raphael Tryster

---

From: [email-masked]
Date: Mon, 4 Feb 2002 22:56:11 +0530

Hi Raphael

Regards
Vivek
HSS
www.hssworld.com

To:   [email-masked]

Raphael Tryster

---

From: Raphael Tryster <[email-masked]>
Date: Tue, 5 Feb 2002 18:00:26 +0200

Hello Vivek,

This document looks like a very useful implementation guide.  What is its
status with respect to adoption by the Megaco community?  I have a few
comments and questions.

1.	Restart from MGC to MG is supported but not shown in the table at
the end of section 8.
2.	In sections 10.2.1.1 item 3, 10.2.5.1, and 10.3.8.1, when the MG
attempts registration with an alternative MGC, should it start the restart
delay timer again?
3.	In section 10.2.2.1, is it possible that any contexts are active
during the Restart in Progress state?
4.	In section 10.2.4, why should the likelihood at MG failover depend
on the existence of call-related activity?
5.	Is MG behaviour on Restart from MGC the same as the behaviour on
cold start except that it skips the avalanche timer?
6.	Am I correct in understanding that on a graceful or forced shutdown
of the Root, the MG deletes all contexts itself, whereas on a graceful or
forced shutdown of individual terminations, the MG leaves the contexts
intact, and waits for the MGC to perform Subtract operations if it wishes?
7.	In sections 10.4.1 and 10.4.2, the concept of the primary MG asking
the primary MG to do something looks strange.  You seem to be describing
different modules in the MG.
8.	In section 10.4.2.2, do you really mean the new state to be
Association in service, or should it be Inactive?
9.	In section 10.4.5.1 item 2, which MG sends the Handoff message?
10.	I think a paragraph about registration response from peer is missing
in section 10.5.
11.	Forced shutdown of the Root may be initiated by either MG or MGC,
whereas Graceful shutdown of the Root may only be initiated by the MG.  Is
this also true for individual terminations?

Thank you,

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Monday, 04 February, 2002 7:26 PM
	To:	Raphael Tryster
	Cc:	[email-masked]
	Subject:	Re: [Megaco] ServiceChange on Root termination

	Hi Raphael

	We have tried to address some of the related issues in an internet
draft. The
	draft captures most of the scenarios involving handling of service
change on
	ROOT termination, The draft also conveys the semantics of the
parameters of the
	service change descriptor as asked by you.

http://search.ietf.org/internet-drafts/draft-hss-megaco-control-association-
state-machine-00.txt

	Regards
	Vivek
	HSS
	www.hssworld.com

	To:   [email-masked]

	There seem to be some restrictions on valid combinations of
ServiceChange
	parameters, but I don't see it spelled out systematically.  For
example, I
	am interested in what methods are valid for a ServiceChange on Root
sent
	from MGC to MG.  Can the MGC send Restart, Graceful or Forced method
for the
	Root termination?  If so, what do they mean for individual
terminations?

	Raphael Tryster

	*** eSafe scanned this email for malicious content ***
	*** IMPORTANT: Do not open attachments from unrecognized senders
*** << File: Internet HTML >>

---

From: Raphael Tryster <[email-masked]>
Date: Tue, 5 Feb 2002 18:00:26 +0200

Hello Vivek,

Thank you,

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Monday, 04 February, 2002 7:26 PM
	To:	Raphael Tryster
	Cc:	[email-masked]
	Subject:	Re: [Megaco] ServiceChange on Root termination

	Hi Raphael

	

	Regards
	Vivek
	HSS
	www.hssworld.com

	To:   [email-masked]

	Raphael Tryster

---

From: [email-masked]
Date: Thu, 7 Feb 2002 00:47:52 +0530

Hello Raphael,
Thanks a lot for reading the complete document so throughly.

We are currently updating the document as per v2 requirements and that as per
the recent discussions going on over the mailing list over the related topics.
We would also incorporate your valuable comments in that as clarifications, at
the same time answering your questions over the list in the next three-four
days.

Thanks and Regards,
MEGACO Team,
www.hssworld.com

Raphael Tryster <[email-masked]> on 02/05/2002 09:00:26 PM

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked] (bcc: Prashant Jain/HSS)

Subject:  RE: [Megaco] ServiceChange on Root termination

Hello Vivek,

Thank you,

Raphael Tryster

     -----Original Message-----
     From:     [email-masked] [SMTP:[email-masked]]
     Sent:     Monday, 04 February, 2002 7:26 PM
     To:  Raphael Tryster
     Cc:  [email-masked]
     Subject:  Re: [Megaco] ServiceChange on Root termination

     Hi Raphael

     Regards
     Vivek
     HSS
     www.hssworld.com

     To:   [email-masked]

     Raphael Tryster

---

From: [email-masked]
Date: Thu, 7 Feb 2002 00:47:52 +0530

Hello Raphael,

Thanks and Regards,
MEGACO Team,
www.hssworld.com

To:   Vivek Bansal/HSS@HSS

Hello Vivek,

Thank you,

Raphael Tryster

     -----Original Message-----
     From:     [email-masked] [SMTP:[email-masked]]
     Sent:     Monday, 04 February, 2002 7:26 PM
     To:  Raphael Tryster
     Cc:  [email-masked]
     Subject:  Re: [Megaco] ServiceChange on Root termination

     Hi Raphael

     Regards
     Vivek
     HSS
     www.hssworld.com

     To:   [email-masked]

     Raphael Tryster

---

From: [email-masked]
Date: Mon, 11 Feb 2002 01:24:41 +0530

Hello Raphael/list,
Please find attached our replies below.

Thanks and Regards,
MEGACO Team,
www.hssworld.com

Raphael Tryster <[email-masked]> on 02/05/2002 09:30:26 PM

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked]

Hello Vivek,

 - The table needs to be corrected. We have anyway discussed in the MG state
machine (section 10) that MG can receive Restart from MGC and in section 11 for
MGC state machine that MGC can send Restart to MG.

 - The protocol is very unclear about the use of the restart delay timer. For
such a scenario where MG has some Restart Delay and if during the delay period,
for some reason, it is redirected towards the new MGC (Handed Off/Secondary
MGC), MG should ideally restart the Restart Delay timer.

 - Restart in Progress is the state where MG is trying to get registered with
the MGC. MG is in this state because it has undergone reboot at its end. The
level of boot would indicate (i.e. service change reason - "Warm Boot") if there
are any active contexts at MG.

- we would correct this assumption. Anyway from the control association point of
view, this would not make any difference.

 - Yes

- In case of Forced shutdown on ROOT termination, MG deletes all contexts by
itself. Where in case of Graceful shutdown on ROOT termination, during the
graceful delay period it is the MGC responsibility to clear the call context and
after Graceful delay time-out, it is again the MG responsibility to clear the
call contexts. And on individual termination whatever be the service change
method (GRACEFUL or FORCED), it always the MGC responsibility to clear the call
context by Subtract operation.

- It has been assumed that in the entire MG, there are three basic components.
One manages Control Association, the other manages the Call Contexts and the
third is the system management entity which is controlling all the components of
the MG. In this state we are discussing about a scenario, where the primary MG
is about to switchover to the redundant, but the System Management entity
detected that the redundant MG is unable to come up. So it is trying to control
the primary MG with whatever it is capable of doing at this moment i.e., FORCED
shutdown, if it cannot manage at all, and GRACEFUL shutdown, if it is in the
position to handle to existing calls but cannot take up any new calls.

- Graceful shutdown at any stage means, that the MG is capable for handling
calls and MGC should refrain from establishing new calls. From the control
association point of view, MG is active with the expire of Graceful timer. So
this is the reason why the state of MG is "Association in service" and not
"Inactive".

- In this case since the active MG is going down, therefore it communicates the
information of the Hand-off from MGC to the redundant MG. And it now the
responsibility of the redundant MG to send Hand-off message to the Handed off
MGC.

- May be we didn't cover that aspect because it is highly unlikely to receive
registration response from peer which you are about to go down.

- Yes, because Graceful shutdown is an indication from MG to MGC to stop
establishing any new calls on the specified termination. The termination
specified in the service change command is about to go out of service. But if
the MGC wants the graceful shutdown of any termination, it would stop
establishing new calls on that termination. MGC does not need to indicate the MG
of its Graceful shutdown.

Thank you,

Raphael Tryster

     -----Original Message-----
     From:     [email-masked] [SMTP:[email-masked]]
     Sent:     Monday, 04 February, 2002 7:26 PM
     To:  Raphael Tryster
     Cc:  [email-masked]
     Subject:  Re: [Megaco] ServiceChange on Root termination

     Hi Raphael

     Regards
     Vivek
     HSS
     www.hssworld.com

     To:   [email-masked]

     Raphael Tryster

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual  to whom it is
addressed. It may contain  privileged or confidential information  and should
not be circulated or used for any purpose other than for what it is intended. If
you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that you
are strictly prohibited from using, copying, altering, or disclosing the
contents of this message. HSS accepts no responsibility for loss or damage
arising from the use of the information transmitted by this email including
damage from virus."

---

From: [email-masked]
Date: Mon, 11 Feb 2002 01:24:41 +0530

Hello Raphael/list,

Thanks and Regards,
MEGACO Team,
www.hssworld.com

To:   Vivek Bansal/HSS@HSS
cc:   [email-masked]

Hello Vivek,

 - Yes

Thank you,

Raphael Tryster

     -----Original Message-----
     From:     [email-masked] [SMTP:[email-masked]]
     Sent:     Monday, 04 February, 2002 7:26 PM
     To:  Raphael Tryster
     Cc:  [email-masked]
     Subject:  Re: [Megaco] ServiceChange on Root termination

     Hi Raphael

     Regards
     Vivek
     HSS
     www.hssworld.com

     To:   [email-masked]

     Raphael Tryster

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 11 Feb 2002 10:47:18 +0200

Hello HSS team and list,

Thank you for your replies.  I have one comment interleaved with your
answers, marked [FSRT].  In addition, I would like to clarify a concept.  A
couple of months ago, I raised the issue of the MG and MGC possibly having
different views of a termination's service state.  It was resolved by Tom
Taylor as follows:

The answer to all your quandaries is indeed to require both sides to track 
two state variables.  However, this only requires one explicit state value 
in the messages exchanged between them, as I'll explain below.  Thinking 
this out, I've changed my mind a bit on how it all should work.  I came to 
this point in considering what would happen in the case of SewrviceChange 
'glare', where both sides simultaneously announce that the termination is 
out of service.  We don't need a visible change in the protocol to take care

of this, but we do need to specify some behaviour.  We could specify backoff

rules, but I think the proposal I give below is simpler. 

I would remark that the two states are not "fault" versus "administrative", 
but rather "MG view" vs. "MGC view".  Administration could act directly on 
the MG rather than through the MGC, or the MGC could detect a fault in the 
provisioned data for the termination.  Each entity has to track its peer's 
view as well as its own. 

The necessary coordination can still be achieved through a single state 
property in the messages exchanged.  The key point is in the interpretation 
of that property.  Instead of a single shared view of state, it represents 
the sender's view of state.  The required description of behaviour is 
therefore as follows (text to go in the ServiceChange section 7.2.8: 
 - either entity in the control association may send a ServiceChange 
indicating a change in the state of a termination at any time 
 - a termination is available for general use only if neither the MG nor the

MGC have most recently indicated that it is out of service 
 - in other cases use of the termination is restricted. 

The above defines language we can now use to replace current restrictions on

applying other commands when a termination is out of service.  We say 
instead, that the commands cannot be applied when use of the termination is 
restricted in accordance with the definition given in section 7.2.8. 
[End of quote from Tom Taylor]

I have the impression that this dual view of the service state applies only
to terminations, and not to the root.  For the root, there is only one
service state, and when the MGC sends a ServiceChange affecting the root, it
is telling the MG to do something, rather than communicating its view of the
Root state.  There are practical implications of this.  For example, suppose
the MG application orders a Forced shutdown of the Root.  If both the MGC
and MG view of the Root state mattered, the MG would ignore a Restart from
the MGC, because the MG view is still OOS.  However, the HSS draft suggests
that there is only a single Root state, and a Restart from the MGC is an
instruction to go in-service.  Is the latter interpretation correct?

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Sunday, 10 February, 2002 9:55 PM
	To:	[email-masked]; [email-masked]
	Subject:	RE: [Megaco] ServiceChange on Root termination

	Hello Raphael/list,

	Thanks and Regards,
	MEGACO Team,
	www.hssworld.com

	To:   Vivek Bansal/HSS@HSS
	cc:   [email-masked]

	Hello Vivek,

	This document looks like a very useful implementation guide.  What
is its
	status with respect to adoption by the Megaco community?  I have a
few
	comments and questions.

	1.   Restart from MGC to MG is supported but not shown in the table
at
	the end of section 8.

	 - The table needs to be corrected. We have anyway discussed in the
MG state
	machine (section 10) that MG can receive Restart from MGC and in
section 11 for
	MGC state machine that MGC can send Restart to MG.

	2.   In sections 10.2.1.1 item 3, 10.2.5.1, and 10.3.8.1, when the
MG
	attempts registration with an alternative MGC, should it start the
restart
	delay timer again?

	 - The protocol is very unclear about the use of the restart delay
timer. For
	such a scenario where MG has some Restart Delay and if during the
delay period,
	for some reason, it is redirected towards the new MGC (Handed
Off/Secondary
	MGC), MG should ideally restart the Restart Delay timer.

	3.   In section 10.2.2.1, is it possible that any contexts are
active
	during the Restart in Progress state?

	 - Restart in Progress is the state where MG is trying to get
registered with
	the MGC. MG is in this state because it has undergone reboot at its
end. The
	level of boot would indicate (i.e. service change reason - "Warm
Boot") if there
	are any active contexts at MG.

	4.   In section 10.2.4, why should the likelihood at MG failover
depend
	on the existence of call-related activity?

	- we would correct this assumption. Anyway from the control
association point of
	view, this would not make any difference.

	5.   Is MG behaviour on Restart from MGC the same as the behaviour
on
	cold start except that it skips the avalanche timer?

	 - Yes

	6.   Am I correct in understanding that on a graceful or forced
shutdown
	of the Root, the MG deletes all contexts itself, whereas on a
graceful or
	forced shutdown of individual terminations, the MG leaves the
contexts
	intact, and waits for the MGC to perform Subtract operations if it
wishes?

	- In case of Forced shutdown on ROOT termination, MG deletes all
contexts by
	itself. Where in case of Graceful shutdown on ROOT termination,
during the
	graceful delay period it is the MGC responsibility to clear the call
context and
	after Graceful delay time-out, it is again the MG responsibility to
clear the
	call contexts. And on individual termination whatever be the service
change
	method (GRACEFUL or FORCED), it always the MGC responsibility to
clear the call
	context by Subtract operation.

	7.   In sections 10.4.1 and 10.4.2, the concept of the primary MG
asking
	the primary MG to do something looks strange.  You seem to be
describing
	different modules in the MG.

	- It has been assumed that in the entire MG, there are three basic
components.
	One manages Control Association, the other manages the Call Contexts
and the
	third is the system management entity which is controlling all the
components of
	the MG. In this state we are discussing about a scenario, where the
primary MG
	is about to switchover to the redundant, but the System Management
entity
	detected that the redundant MG is unable to come up. So it is trying
to control
	the primary MG with whatever it is capable of doing at this moment
i.e., FORCED
	shutdown, if it cannot manage at all, and GRACEFUL shutdown, if it
is in the
	position to handle to existing calls but cannot take up any new
calls.

	- Graceful shutdown at any stage means, that the MG is capable for
handling
	calls and MGC should refrain from establishing new calls. From the
control
	association point of view, MG is active with the expire of Graceful
timer. So
	this is the reason why the state of MG is "Association in service"
and not
	"Inactive".

	[FSRT] I think what your document describes is not a complete state
machine, in the sense that in order to turn it into a program, additional
states and events would be needed.  For example, a real program would need
to treat expiry of the graceful timer as a separate event, and the period
when the graceful timer is running as a separate state.  So, am I correct
that what you really mean here is that the state remains Association in
Service while the timer is running, and goes to Inactive when the timer
expires?

	- In this case since the active MG is going down, therefore it
communicates the
	information of the Hand-off from MGC to the redundant MG. And it now
the
	responsibility of the redundant MG to send Hand-off message to the
Handed off
	MGC.

	10.  I think a paragraph about registration response from peer is
missing
	in section 10.5.

	- May be we didn't cover that aspect because it is highly unlikely
to receive
	registration response from peer which you are about to go down.

	11.  Forced shutdown of the Root may be initiated by either MG or
MGC,
	whereas Graceful shutdown of the Root may only be initiated by the
MG.  Is
	this also true for individual terminations?

	- Yes, because Graceful shutdown is an indication from MG to MGC to
stop
	establishing any new calls on the specified termination. The
termination
	specified in the service change command is about to go out of
service. But if
	the MGC wants the graceful shutdown of any termination, it would
stop
	establishing new calls on that termination. MGC does not need to
indicate the MG
	of its Graceful shutdown.

	Thank you,

	Raphael Tryster

	     -----Original Message-----
	     From:     [email-masked] [SMTP:[email-masked]]
	     Sent:     Monday, 04 February, 2002 7:26 PM
	     To:  Raphael Tryster
	     Cc:  [email-masked]
	     Subject:  Re: [Megaco] ServiceChange on Root termination

	     Hi Raphael

	     We have tried to address some of the related issues in an
internet
	draft. The
	     draft captures most of the scenarios involving handling of
service
	change on
	     ROOT termination, The draft also conveys the semantics of the
	parameters of the
	     service change descriptor as asked by you.

	     Regards
	     Vivek
	     HSS
	     www.hssworld.com

	     To:   [email-masked]

	     There seem to be some restrictions on valid combinations of
	ServiceChange
	     parameters, but I don't see it spelled out systematically.  For
	example, I
	     am interested in what methods are valid for a ServiceChange on
Root
	sent
	     from MGC to MG.  Can the MGC send Restart, Graceful or Forced
method
	for the
	     Root termination?  If so, what do they mean for individual
	terminations?

	     Raphael Tryster

	     *** eSafe scanned this email for malicious content ***
	     *** IMPORTANT: Do not open attachments from unrecognized
senders
	*** << File: Internet HTML >>

	*** eSafe scanned this email for malicious content ***
	*** IMPORTANT: Do not open attachments from unrecognized senders
*** << File: Internet HTML >>  << File: ATT01450.txt >>

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 11 Feb 2002 10:47:18 +0200

Hello HSS team and list,

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Sunday, 10 February, 2002 9:55 PM
	To:	[email-masked]; [email-masked]
	Subject:	RE: [Megaco] ServiceChange on Root termination

	Hello Raphael/list,

	Thanks and Regards,
	MEGACO Team,
	www.hssworld.com

	To:   Vivek Bansal/HSS@HSS
	cc:   [email-masked]

	Hello Vivek,

	 - Yes

	Thank you,

	Raphael Tryster

	     -----Original Message-----
	     From:     [email-masked] [SMTP:[email-masked]]
	     Sent:     Monday, 04 February, 2002 7:26 PM
	     To:  Raphael Tryster
	     Cc:  [email-masked]
	     Subject:  Re: [Megaco] ServiceChange on Root termination

	     Hi Raphael

	     Regards
	     Vivek
	     HSS
	     www.hssworld.com

	     To:   [email-masked]

	     Raphael Tryster

---

From: "Kevin Boyle"<[email-masked]>
Date: Mon, 11 Feb 2002 07:52:23 -0500

All,

Those of us in the SG16 meeting have taken a great interest in clearing up
the murky SC waters.  This will be quite a large effort, however, so it will
not be accomplished at this meeting.  As soon as I get back state-side, I
will put together a group to attempt to develop a contribution for the
upcoming Rapporteur's meeting which can then be carried forward to the next
full Study Group meeting for inclusion into the protocol.

I will contact you all via email in the next couple of weeks to arrange a
side group to pound this out, draft some recommendations, and bring them
back to the list before producing a contribution for Q.3/16.

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Monday, February 11, 2002 3:47 AM
To: [email-masked]; [email-masked]
Cc: Taylor, Tom-PT [CAR:B800:EXCH]
Subject: RE: [Megaco] ServiceChange on Root termination

Hello HSS team and list, 

-----Original Message----- 
From:   [email-masked] [SMTP:[email-masked]] 
Sent:   Sunday, 10 February, 2002 9:55 PM 
To:     [email-masked]; [email-masked] 
Subject:        RE: [Megaco] ServiceChange on Root termination 

Hello Raphael/list, 

Raphael Tryster <raphael@tdsoft 
To:   Vivek Bansal/HSS@HSS 
cc:   [email-masked] 
Subject:  RE: [Megaco] ServiceChange on Root termination 

Hello Vivek, 

machine (section 10) that MG can receive Restart from MGC and in section 11
for 
MGC state machine that MGC can send Restart to MG. 

2.   In sections 10.2.1.1 item 3, 10.2.5.1, and 10.3.8.1, when the MG 
attempts registration with an alternative MGC, should it start the restart 
delay timer again? 
 - The protocol is very unclear about the use of the restart delay timer.
For 
such a scenario where MG has some Restart Delay and if during the delay
period, 
for some reason, it is redirected towards the new MGC (Handed Off/Secondary 
MGC), MG should ideally restart the Restart Delay timer. 

3.   In section 10.2.2.1, is it possible that any contexts are active 
during the Restart in Progress state? 
 - Restart in Progress is the state where MG is trying to get registered
with 
the MGC. MG is in this state because it has undergone reboot at its end. The

level of boot would indicate (i.e 
are any active contexts at MG. 

4.   In section 10.2.4, why should the likelihood at MG failover depend 
on the existence of call-related activity? 
- we would correct this assumption 
view, this would not make any difference. 

itself. Where in case of Graceful shutdown on ROOT termination, during the 
graceful delay period it is the MGC responsibility to clear the call context
and 
after Graceful delay time-out, it is again the MG responsibility to clear
the 
call contexts. And on individual termination whatever be the service change 
method (GRACEFUL or FORCED), it always the MGC responsibility to clear the
call 
context by Subtract operation. 

third is the system management entity which is controlling all the
components of 
the MG. In this state we are discussing about a scenario, where the primary
MG 
is about to switchover to the redundant, but the System Management entity 
detected that the redundant MG is unable to come up. So it is trying to
control 
the primary MG with whatever it is capable of doing at this moment i.e.,
FORCED 
shutdown, if it cannot manage at all, and GRACEFUL shutdown, if it is in the

8.   In section 10.4.2.2, do you really mean the new state to be 
Association in service, or should it be Inactive? 
- Graceful shutdown at any stage means, that the MG is capable for handling 
calls and MGC should refrain from establishing new calls. From the control 
association point of view, MG is active with the expire of Graceful timer.
So 
this is the reason why the state of MG is "Association in service" and not 
"Inactive". 
[FSRT] I think what your document describes is not a complete state machine,
in the sense that in order to turn it into a program, additional states and
events would be needed.  For example, a real program would need to treat
expiry of the graceful timer as a separate event, and the period when the
graceful timer is running as a separate state.  So, am I correct that what
you really mean here is that the state remains Association in Service while
the timer is running, and goes to Inactive when the timer expires?
9.   In section 10.4.5.1 item 2, which MG sends the Handoff message? 
- In this case since the active MG is going down, therefore it communicates
the 
information of the Hand-off from MGC to the redundant MG. And it now the 
responsibility of the redundant MG to send Hand-off message to the Handed
off 
MGC. 

10.  I think a paragraph about registration response from peer is missing 
in section 10.5. 
- May be we didn't cover that aspect because it is highly unlikely to
receive 
registration response from peer which you are about to go down. 

11.  Forced shutdown of the Root may be initiated by either MG or MGC, 
whereas Graceful shutdown of the Root may only be initiated by the MG.  Is 
this also true for individual terminations? 
- Yes, because Graceful shutdown is an indication from MG to MGC to stop 
establishing any new calls on the specified termination. The termination 
specified in the service change command is about to go out of service. But
if 
the MGC wants the graceful shutdown of any termination, it would stop 
establishing new calls on that termination. MGC does not need to indicate
the MG 
of its Graceful shutdown. 

Thank you, 
Raphael Tryster 

     -----Original Message----- 
     From:     [email-masked] [SMTP:[email-masked]] 
     Sent:     Monday, 04 February, 2002 7:26 PM 
     To:  Raphael Tryster 
     Cc:  [email-masked] 
     Subject:  Re: [Megaco] ServiceChange on Root termination 

     Hi Raphael 

state-machine-00.txt 
     Regards 
     Vivek 
     HSS 
     www.hssworld.com 

     Raphael Tryster 

*** eSafe scanned this email for malicious content *** 
*** IMPORTANT: Do not open attachments from unrecognized senders  *** <<
File: Internet HTML >>  << File: ATT01450.txt >>

---

From: "Kevin Boyle"<[email-masked]>
Date: Mon, 11 Feb 2002 07:52:23 -0500

All,

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Monday, February 11, 2002 3:47 AM
To: [email-masked]; [email-masked]
Cc: Taylor, Tom-PT [CAR:B800:EXCH]
Subject: RE: [Megaco] ServiceChange on Root termination

Hello HSS team and list, 

-----Original Message----- 
From:   [email-masked] [SMTP:[email-masked]] 
Sent:   Sunday, 10 February, 2002 9:55 PM 
To:     [email-masked]; [email-masked] 
Subject:        RE: [Megaco] ServiceChange on Root termination 

Hello Raphael/list, 

Hello Vivek, 

Thank you, 
Raphael Tryster 

     -----Original Message----- 
     From:     [email-masked] [SMTP:[email-masked]] 
     Sent:     Monday, 04 February, 2002 7:26 PM 
     To:  Raphael Tryster 
     Cc:  [email-masked] 
     Subject:  Re: [Megaco] ServiceChange on Root termination 

     Hi Raphael 

state-machine-00.txt 
     Regards 
     Vivek 
     HSS 
     www.hssworld.com 

     Raphael Tryster