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

From: [email-masked]
Date: Mon, 9 Jan 2006 12:04:13 +0200

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?
All have default state, which is In-Service, until otherwise announced
by the MGW?
This case has been earlier discussed on this list. 
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?
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?

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.
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?
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?

best regards Manfred

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 11 Jan 2006 14:28:08 -0500

Where is the contradiction?  When using the SCIncomplete flag, announce
the OOS terminations.  When not, announce the terminations that have
changed state.

Ultimately, the MGC has to be able to handle both.  What does it mean if
the termination is OOS and the MG announces that it is OOS again? This
is essentially a NOP.  What does it mean if the termination is IS, and
the MG announces that it is IS?  The MGC can audit to find out if
something changed, but it will be doing that anyway.  So, again, a NOP.

Kevin 

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

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 

>-----Original Message-----
>From: ext Kevin Boyle [mailto:[email-masked]]
>Sent: 10 January, 2006 17:37
>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]]
>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,
>>
>>after a MGW sends a Service Change with Service Change method restart 
>>or disconnect.
>>
>>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.
>>
>>[KJBII] Yes, all terminations are assumed to be InService.
>>
>>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.
>
>>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
>
>>[KJBII] See the answer for 2, above.
>>
>[KJBII] snip!
>