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

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 10 Jan 2006 10:37:07 -0500

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2006 9:36 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: RE: [Megaco] Service Change Method = restart/disconnect,Service
Change Reason combination questions

Hi Kevin,

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

br manfred 

>-----Original Message-----
>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
>
>-----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.
>
[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.

[KJBII] The MG would announce those that have changed state, since the
MGC assumes previous state on the Warm Boot.

>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.
>
[KJBII] snip!

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

---

From: [email-masked]
Date: Wed, 11 Jan 2006 15:38:04 +0200

Hi Kevin, 

Isn't there now a contradiction between your answer to point 2 and your
answer to point 6? 

For point 2 you said "The MG would announce those that have changed
state, 
since the MGC assumes previous state on the Warm Boot".
But for point 6 (the same case warm boot, but now with Service Change
Incomplete flag use)
you said "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."

So depending if the MGW decides to use the Service Change Incomplete
flag, MGW's behaviour would be different;
without use of the Service Change Incomplete Flag the MGW would announce
the terminations which changed state, 
with use of the Service Change Incomplete Flag the MGW would announce
the terminations which are out of service?

br manfred 

>Sent: 10 January, 2006 17:37
>[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?
>[KJBII] The MG would announce those that have changed state, 
>since the MGC assumes previous state on the Warm Boot.
>