Subject: RE: [Megaco] ServiceChangeReason parameter

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 3 Aug 2001 16:37:10 -0400

Comments inline.
 
-----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Friday, August 03, 2001 4:06 PM
To: [email-masked]
Subject: Re: [Megaco] ServiceChangeReason parameter

Kevin 
If you look at Annex L. 
Reason # : 901 Name: Cold Boot 
Definition: This indicates that the entity indicated with the TerminationID
is in serviceState "In-Service", and that it has gone through a start or
recovery action and all associated contexts except the null context have
been cleared. 
Reference: - 
Text in the Service Change extension: - 
Comment: This reason code only applies for TerminationID root and ALL. 
901 implies MGC does not have to sent Subtract to MG.
This only applies to ROOT and ALL.  I see no benefit to doing a Restart on
ALL -- why not just use ROOT?  Also, as previously established on the list,
a SC Restart on ROOT implies loss of state.  So this does not convey any
additional knowledge that is required by the MGC.
Reason # : 902 Name: Warm Boot 
Definition: This indicates that the entity indicated with the TerminationID
is in ServiceState "in-Service", and that it has gone through a start or
recovery action. All transactions in process may be lost, but otherwise all
state is preserved on the termination. 
902 implies that there are terminations in contexts which might or might
require MGC 
to Subtract thems. 
Restart on a termination has never meant that it is removed from a context
-- only that it has restarted.  It is up to the MGC to remove it from
context if appropriate.  Once again, no unknown information has been
conveyed.  In the case of ROOT, a Restart on ROOT implies loss of state.
So, once again, no behavior difference has been established.  I still
maintain that Reason should be optional.
It really depends on MG implementation. 
If MG has a processor that strictly handles Megaco signaling and it is just
this processor 
that gets rebooted, there is no reason for established calls to be teared
down. 
So MG can re-establish w/Warm boot. 
I know of one MG vendor that does actually send Restart w/Warm boot and 
the terminations are intact in the contexts. 
  
Yes, there are cases whether Method and Reason are redundant and confusing. 
Chuong 

  
Kevin Boyle wrote: 
  
I haven't seen any cases where Reason should be required.  I agree Method is
absolutely required, as it defines the behavior taken by the receiving
party. In what scenario does Reason alter the behavior that would occur for
a given Method?  Unless there are some concrete cases where the behavior is
completely different, I would think that Reason should be optional. 
Kevin 
 -----Original Message----- 
From:   Terry L Anderson [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent:   Friday, August 03, 2001 12:30 PM 
To:     Christian Groves 
Cc:     [email-masked]; [email-masked] 
Subject:        Re: [Megaco] ServiceChangeReason parameter 
 << File: Card for Terry L Anderson >> By "too subtle" I only meant a
parameter being mandatory being stated only in the body of 
H.248 and not in the syntax spec (when other similar
restrictions/requirements ARE stated 
in the syntax spec).  You seem to agree that adding a comment in the ABNF is
good. 
The IG has already added two comments before serviceChangeParm 
(6.5) ; each parameter at-most-once 
(6.72) ;at most one of either serviceChangeAddress or serviceChangeMgcId but
not both 
I propose we add one additional comment 
; serviceChangeMethod and serviceChangeReason are REQUIRED 
Christian Groves wrote: 
> No I don't believe its too subtle. The binary has Service Change Reason 
> and Method as mandatory as per the text. The ABNF because of its 
> specification can't enforce this, so yes a comment is needed. If the 
> reason is neglected what does the MGC do? The reasons were given to add 
> some meaning to the Methods. 
> 
> Christian 
> 
> Terry L Anderson wrote: 
> > 
> > Christian Groves wrote: 
> > 
> > > Hello Terry, 
> > > 
> > > I believe the ASN.1 is correct if you read the procedural text in 
> > > ch7.2.8 every element says "The optional", ServiceChangeMethod and 
> > > ServiceChangeReason does not have this qualification. 
> > 
> > Isn't that a bit too subtle and shouldn't this be in the ABNF comments. 
> > 
> > > 
> > > 
> > > Christian 
> > > 
> > > Terry L Anderson wrote: 
> > > > 
> > > > This is another difference between the text and binary versions.
The ASN.1 
> > > > clearly requires serviceChangeMethod and serviceChangeReason in each

> > > > ServiceChange command with all other parameters optional, but the
ABNF simply 
> > > > states (in comments added in IG 6.5 and 6.72) that each item can
appear at most 
> > > > once and only one of ServiceChangeAddress and ServiceChangeMgcId -
no element 
> > > > is required. 
> > > > 
> > > > I am not sure that this difference was intentional but that is the
current 
> > > > state of the spec.  Do we want the ABNF to also require
ServiceChangeMethod and 
> > > > ServiceChangeReason?  The registration in the text-based example in
A.1.1 
> > > > contains a Method but not a Reason. 
> > > > 
> > > > IPEK SARAC wrote: 
> > > > 
> > > > > Hello, 
> > > > > 
> > > > > RFC3015 doesn't mention if ServiceChangeReason for ServiceChange
command is 
> > > > > mandatory or optional (it doesn't say optional so i take it as
required). 
> > > > > Megaco Call Flow Examples draft doesn't include a
ServiceChangeReason in 
> > > > > cold start scenario. Which one is true? 
> > > > > 
> > > > > Thanks in advance. 
> > > > > 
> > > > > Ipek Sarac 
> > > > > 
> > > > > _______________________________________________ 
> > > > > Megaco mailing list 
> > > > > [email-masked] 
> > > > > http://www.ietf.org/mailman/listinfo/megaco
<http://www.ietf.org/mailman/listinfo/megaco>  
> > > > 
> > > > -- 
> > > > Waiting for the other shoe to drop but hoping its a one legged man. 
> > > > ------------------------------------------------------------ 
> > > > Terry L Anderson             mailto:[email-masked]
<mailto:[email-masked]>  
> > > > Tel:908.582.7013   Fax:908.582.6729 
> > > > Lucent Technologies/INS/Voice Over IP Access Networks 
> > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 
> > > > http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent
internal) http://www.gti.net/tla <http://www.gti.net/tla>  
> > 
> > -- 
> > Waiting for the other shoe to drop but hoping its a one legged man. 
> > ------------------------------------------------------------ 
> > Terry L Anderson             mailto:[email-masked]
<mailto:[email-masked]>  
> > Tel:908.582.7013   Fax:908.582.6729 
> > Lucent Technologies/INS/Voice Over IP Access Networks 
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 
> > http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent
internal) http://www.gti.net/tla <http://www.gti.net/tla>  
-- 
Waiting for the other shoe to drop but hoping its a one legged man. 
------------------------------------------------------------ 
Terry L Anderson             mailto:[email-masked] <mailto:[email-masked]>  
Tel:908.582.7013   Fax:908.582.6729 
Lucent Technologies/INS/Voice Over IP Access Networks 
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 
http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent internal)
http://www.gti.net/tla <http://www.gti.net/tla> 
-- 
  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: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 03 Aug 2001 18:22:49 -0500

It is a mood point anyway.

Cleary it is not an error there IG can't
the Standard.

Even if it is changed in v2, it is sort of
pointless too since v2 has to be backward

compatible w/v1 implementation.

See comments below:

If
you look at Annex L.

Reason
# : 901 Name: Cold Boot

Definition:
This indicates that the entity indicated with the TerminationID is in serviceState
"In-Service", and that it has gone through a start or recovery action and
all associated contexts except the null context have been cleared.

Reference:
-

Text in the
Service Change extension: -

Comment: This
reason code only applies for TerminationID root and ALL.

901
implies MGC does not have to sent Subtract to MG.

This
only applies to ROOT and ALL.I see
no benefit to doing a Restart on ALL -- why not just use ROOT?Also,
as previously established on the list, a SC Restart on ROOT implies loss
of state.So this does not convey
any additional knowledge that is required by the MGC.

<cnn>
I have to dig up the discussion but I remember the discussion

did distinguish between Cold and Warm boot.

Reason
# : 902 Name: Warm Boot

Definition:
This indicates that the entity indicated with the TerminationID  is
in ServiceState "in-Service", and that it has gone through a start or recovery
action. All transactions in process may be lost, but otherwise all state
is preserved on the termination.

902
implies that there are terminations in contexts which might or might require
MGC

to
Subtract thems.

Restart
on a termination has never meant that it is removed from a context -- only
that it has restarted.It is up to
the MGC to remove it from context if appropriate.Once
again, no unknown information has been conveyed.In
the case of ROOT, a Restart on ROOT implies loss of state.So,
once again, no behavior difference has been established.I
still maintain that Reason should be optional.

<cnn>  I skipped some text from Annex L

Comment: This reason code only applies for TerminationID root.

It is talking about ROOT and not individual termination.