Subject: RE: [Megaco] Service Change Method = restart/disconnect, Service Change Reason combination questions

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 9 Jan 2006 11:09:01 -0500

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, January 09, 2006 5:04 AM
To: [email-masked]
Subject: [Megaco] Service Change Method = restart/disconnect,Service
Change Reason combination questions

Hi,

I have some questions concerning the state of physical terminations
after a MGW sends a Service Change with Service Change method restart or
disconnect.

For H.248 Version 1 or 2.
1.) MGW sends Service Change with Method = Restart and Service Change
Reason = Cold Boot What should the MGC assume about the state of the
physical Terminations?

[KJBII] I am assuming you are asking about a ServiceChange Command on
the Root Termination.  If so, all physical terminations can be assumed
to be in NULL and no contexts are present.

All have default state, which is In-Service, until otherwise announced
by the MGW?
This case has been earlier discussed on this list.

[KJBII] Yes, all terminations are assumed to be InService.

2.) MGW sends Service Change with Method = Restart and Service Change
Reason = Warm Boot Should in this case the MGC also assume that all
physical Terminations have the default state In-service or should it
assume that nothing has changed in the state of the Terminations?

[KJBII] All terminations remain in the context they are in.  There is no
assumption that anything has changed in this case -- the MGC will have
to audit to determine if anything changed.

3.) MGW sends Service Change with Method = Restart and Service Change
Reason = Service Restored Should in this case the MGC also assume that
all physical Terminations have the default state In-service or should it
assume that nothing has changed in the state of the Terminations?

[KJBII] See the answer for 2, above.

4.) MGW sends Service Change with Method = Disconnect and Service Change
Reason = Service Restored Should in this case the MGC also assume that
all physical Terminations have the default state In-service or should it
assume that nothing has changed in the state of the Terminations?

[KJBII] See the answer for 2, above.

For H.248 Version 3 with use of Service Change Incomplete Flag.
5.) MGW sends Service Change with Method = Restart and Service Change
Reason = Cold Boot and Service Change Incomplete flag set.
I assume that the MGW should at least announce all physical Terminations
which are in state out of service before it sends a Service Change with
Service Incomplete flag reset.

[KJBII] Correct.

6.) MGW sends Service Change with Method = Restart and Service Change
Reason = Warm Boot and Service Change Incomplete flag set Should the MGW
in this case at least announce all physical Terminations which are in
state out of service before it sends a Service Change with Service
Incomplete Flag reset? 
Or should it announce at least all the physical Terminations which
changed state during the connection break between the  MGC and MGW
before it sends a Service Change with Service Incomplet Flag reset?

[KJBII] The intent of the SCIncomplete flag was to allow a very large MG
to inform the MGC of its OOS terminations prior to the MGC bringing the
MG into live service after a boot.  This is because it could take quite
a number of messages to inform the MGC of the OOS terminations.  In the
case of a Warm Boot of a previously inservice MG, the MGC is not going
to assume any change.  In order to provide continuity with a previously
OOS MG, I believe the MG should report all the OOS terminations.

7.) MGW sends Service Change with Method = Restart and Service Change
Reason = Service Restored and Service Change Incomplete flag set Should
the MGW in this case at least announce all physical Terminations which
are in state out of service before it sends a Service Change with
Service Incomplete Flag reset? 
Or should it announce at least all the physical Terminations which
changed state during the connection break between the  MGC and MGW
before it sends a Service Change with Service Incomplet Flag reset?

[KJBII] See the answer for 6, above.

best regards Manfred

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

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

---

From: [email-masked]
Date: Tue, 10 Jan 2006 16:35:33 +0200

Hi Kevin,

Thanks for your answer. I have one additional question inline [MVo].

br manfred 

>From: ext Kevin Boyle [mailto:[email-masked]] 
>Sent: 09 January, 2006 18:09
>To: Volz Manfred (Nokia-NET/Helsinki); [email-masked]
>Subject: RE: [Megaco] Service Change Method = 
>restart/disconnect,Service Change Reason combination questions
>
>Comments inline. [KJBII]
>
>Kevin 
>
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of [email-masked]
>Subject: [Megaco] Service Change Method = 
>restart/disconnect,Service Change Reason combination questions
>
>Hi,
>
>I have some questions concerning the state of physical 
>terminations after a MGW sends a Service Change with Service 
>Change method restart or disconnect.
>
>1.) MGW sends Service Change with Method = Restart and Service 
>Change Reason = Cold Boot What should the MGC assume about the 
>state of the physical Terminations?
>
>[KJBII] I am assuming you are asking about a ServiceChange 
>Command on the Root Termination.  If so, all physical 
>terminations can be assumed to be in NULL and no contexts are present.
>
>All have default state, which is In-Service, until otherwise 
>announced by the MGW?
>2.) MGW sends Service Change with Method = Restart and Service 
>Change Reason = Warm Boot Should in this case the MGC also 
>assume that all physical Terminations have the default state 
>In-service or should it assume that nothing has changed in the 
>state of the Terminations?
>
>[KJBII] All terminations remain in the context they are in.  
>There is no assumption that anything has changed in this case 
>-- the MGC will have to audit to determine if anything changed.
>
[MVo] Should in this case the MGW announce the physical terminations
which are Out of Service?
Or should the MGW announce the physical terminations which changed
service state during the connection break 
between MGC and MGW? Or should the MGW do nothing, meaning it will rely
on a possible audit from the MGC?
Same question for point 3 and 4.

>3.) MGW sends Service Change with Method = Restart and Service 
>Change Reason = Service Restored Should in this case the MGC 
>also assume that all physical Terminations have the default 
>state In-service or should it assume that nothing has changed 
>in the state of the Terminations?
>
>4.) MGW sends Service Change with Method = Disconnect and 
>Service Change Reason = Service Restored Should in this case 
>the MGC also assume that all physical Terminations have the 
>default state In-service or should it assume that nothing has 
>changed in the state of the Terminations?
>
>5.) MGW sends Service Change with Method = Restart and Service 
>Change Reason = Cold Boot and Service Change Incomplete flag set.
>I assume that the MGW should at least announce all physical 
>Terminations which are in state out of service before it sends 
>a Service Change with Service Incomplete flag reset.
>
>[KJBII] Correct.
>
>6.) MGW sends Service Change with Method = Restart and Service 
>Change Reason = Warm Boot and Service Change Incomplete flag 
>set Should the MGW in this case at least announce all physical 
>Terminations which are in state out of service before it sends 
>a Service Change with Service Incomplete Flag reset? 
>Or should it announce at least all the physical Terminations 
>which changed state during the connection break between the  
>MGC and MGW before it sends a Service Change with Service 
>Incomplet Flag reset?
>
>[KJBII] The intent of the SCIncomplete flag was to allow a 
>very large MG to inform the MGC of its OOS terminations prior 
>to the MGC bringing the MG into live service after a boot.  
>This is because it could take quite a number of messages to 
>inform the MGC of the OOS terminations.  In the case of a Warm 
>Boot of a previously inservice MG, the MGC is not going to 
>assume any change.  In order to provide continuity with a 
>previously OOS MG, I believe the MG should report all the OOS 
>terminations.
>
>7.) MGW sends Service Change with Method = Restart and Service 
>Change Reason = Service Restored and Service Change Incomplete 
>flag set Should the MGW in this case at least announce all 
>physical Terminations which are in state out of service before 
>it sends a Service Change with Service Incomplete Flag reset? 
>Or should it announce at least all the physical Terminations 
>which changed state during the connection break between the  
>MGC and MGW before it sends a Service Change with Service 
>Incomplet Flag reset?
>