Subject: RE: [Megaco] ServiceChangeReason parameter

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 3 Aug 2001 13:50:18 -0400

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]] 
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
> > > >
> > > > --
> > > > Waiting for the other shoe to drop but hoping its a one legged man.
> > > > ------------------------------------------------------------
> > > > Terry L Anderson              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 (Lucent internal) 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]
> > 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 (Lucent internal) 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]
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 (Lucent internal) http://www.gti.net/tla

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 03 Aug 2001 15:05:39 -0500

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.

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.

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
>
> in the syntax spec).  You seem to agree that adding a comment in the
> ABNF is good.
>
> (6.72) ;at most one of either serviceChangeAddress or
> serviceChangeMgcId but not both
>
> > > > > This is another difference between the text and binary
> versions.  The ASN.1
> > > > > 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
> > > > > ServiceChangeReason?  The registration in the text-based
> example in A.1.1
> > > > > > RFC3015 doesn't mention if ServiceChangeReason for
> ServiceChange command is
> > > > > > mandatory or optional (it doesn't say optional so i take it
> as required).

--
  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 ****