Subject: Re: ServiceChange

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 2 Feb 2000 11:00:32 -0600

Responses below.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:[email-masked]]
> Sent: Wednesday, February 02, 2000 10:48 AM
> To:   [email-masked]
> Subject:      ServiceChange
>
> 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."
        [[TomT]]
        Yes, the whole section got added at my suggestion, but some
shortcuts were taken.  I'll figure out what we should add/change in the
"error" category vs. the "clarification" category.
>
>
> 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?
        [[TomT]]
        I expect so.  The intent is to provide a means to convey
vendor-specific data on startup.  I suppose some text should be added in the
"clarification" category.
>
>
> "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.
        [[TomT]]
        Other notes today have made it clear: profile version is independent
of protocol version.

> 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?
        [[TomT]]
        Actually, the resolution of this item is in message RE: [Fwd: FW:
Application for port-number], sent by Brian Rosen, 19/01/00 8:15 AM.  The
MGC replies to the address from which the MG sent the ServiceChange message,
and continues to use that address (and port) for other messages of the
association.  Conclusion is that the MG does NOT use the address parameter
at all.  This requires fixes in the "error" category.
>
>
> 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 ****
>