Subject: ServiceChange

From: Chuong Nguyen <[email-masked]>
Date: Wed, 2 Feb 2000 09:48:17 -0600

Hi

Section 7.2.8 ServiceChange

"The return from ServiceChange has the same parameters as the input
except that
ServiceChange Method and ServiceChangeReason are optional.  If provided
they shall
be the same as those specificied in the command."

Does this statement apply to a ServiceChange Reply?
If yes:
1) If the command contains a ServiceChangeDelay, does the reply also
contains a ServiceChangeDelay?
     If yes, ABNF does not allow it?
          serviceChgReplyParam = (serviceChangeAddress /
serviceChangeMgcId /

serviceChangeProfile / serviceChangeVersion)
     I think the ABNF is correct and the intend is correct except for
the wording:
     "The return from ServiceChange has the same parameters as the input
..."
2) It looks like the paragraph with
     "Summarizing use of properties in the ServiceChange Descriptor"
needs to be clarified
     with something like "Summarizing use of properties in the
ServiceChange Descriptor
      for a ServiceChange Request".
     Then another paragraph for "Summarizing use of properties in the
ServiceChange Descriptor
      for a ServiceChange Reply."

The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod can
have
extension.  Section 7.1.13 and 7.2.8 do not mention this.
Do these 2 extensions go hand in hand?  That is, can one have just a
ServiceChangeMethod
extension but not a ServiceChange Descriptor extension?

"The optional Profile parameter specifies the Profile (if any) of the
protocol supported.  The
Profile includes the version of the profile supported."

Is the Profile version just the version of the Profile regardless of
Megaco protocol version?
Said the MG IP phone example given by Abdallah, IpPhone/1 and IpPhone/2.

Are these 2 version # intended to imply IpPhone/1 supports Megaco v1 and
IpPhone/2
supports Megaco v2?  Or the version # is a release of different IpPhone
version w/o
regard to Megaco protocol version?
If version # has no relationship to Megaco protocol version #, can "of
the protocol supported" be
removed?
If yes, I hope no one needs to have several release of IpPhone Profile
that supports Megaco
protocol v1 because the ABNF "version" syntax does not support it.

Section 9 Transport
"The MG specifies the address (e.g. TCP/UDP port number) it wished the
MGC to use for
communication.  The MGC replies ..."
Some clarification wording might need to added to specify that
ServiceChangeAddress only
applies to UDP.  For TCP, ServiceChangeAddress is ignored or not even
supposed to be in
the ServiceChange Descriptor.  Is this what the consensus is from prior
discussion on the List?

Chuong

--
  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: Abdallah Rayhan <[email-masked]>
Date: Wed, 2 Feb 2000 12:21:09 -0500

See comments below.

Abdallah

Chuong Nguyen wrote:

> ServiceChange Method and ServiceChangeReason are optional.  If
> provided they shall

This does not seem correct. It should read like this:
"The values of ServiceChangeReply parameters are the same as the values
of
ServiceChange parameters if parameters processed successfully, e.g.,
sevicechange has new profile, the reply would have the profile parameter
with
the same values. Otherwise, errorDescriptor is used within the
serviceChangeReply
to convey the unsuccessful processing of the parameter, e.g., profile
not supported.
All the parameters in serviceChangeReply are optional. If
serviceChangeReply has
no parameters, it means all the parameters have been processed
successfully."

Also, errorDescriptor should be part of the servChangeReplyParm in
addition
to serviceChangeMethod, serviceChangeReason, serviceChangeDelay,
extension, TimeStamp. Also, the parameters in serviceChangeReply should
be
made optional.

>      "The return from ServiceChange has the same parameters as the
> input ..."
> The ABNF shows that ServiceChange Descriptor and ServiceChangeMethod
> can have

These two extensions are independent.

> Are these 2 version # intended to imply IpPhone/1 supports Megaco v1
> and IpPhone/2
> supports Megaco v2?  Or the version # is a release of different
> IpPhone version w/o

I dont believe that profile version has a relationship with regard to
protocol version. However,
that does not mean that Profile/1 must work with MEGACO/2. It all
depends on how
compatible Profile/1 with MEGACO/2 which is something we dont know
because we
dont know what MEGACO/2 is like. IMO, if the functionality that the
profile requires and
that the protocol supports differ in the new release of the protocol,
then all those profiles
that are affected need to be updated if they are to use the new release.
At the same
time profiles might be updated at a different rate than the protocol,
e.g., an application can
have two releases of its profile for the same protocol version.

> the ServiceChange Descriptor.  Is this what the consensus is from
> prior discussion on the List?
>
>
> Chuong
>
> --