Subject: Re: Is ServiceChangeMgcId Optional on Cold Start?

From: Michael P DiGioia <[email-masked]>
Date: Mon, 28 Aug 2000 19:38:27 -0400

>> Note that this implies ServiceChangeMgcId is not optional.
>> I think this is incorrect and the text should state:
>> "...with the ServiceChangeMgcId omitted or set to itself."

Brian,

The first ServiceChange cmd from the MG is akin to a hello message and
nothing is required to be returned. Transaction accept from the PriMGC
indicates an add to MGC's table was complete. I therefore agree that
it should be omitted.

/mpd

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 29 Aug 2000 15:02:34 -0500

Please look at the words you quote again.  To me the two passages both say
the same thing, although the second one does it in roundabout fashion
through the use of negatives.  The interpretation is exactly as you say:
ServiceChangeMgcId is omitted when the MGC is willing to accept the
association.

> -----Original Message-----
> From: chennu [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2000 9:23 AM
> To: [email-masked]
> Subject: Re: Is ServiceChangeMgcId Optional on Cold Start?
>
>
> Hi Brian,
>
> The text explaining ServiceChangeMgcId is contradictory. I am
> giving the
> text in 7.2.8 of Megaco-merged-01 document
> "ServiceChangeMgcId provides an alternative address where the
> MG should
> seek to establish another association."
> I am giving some more lines under the same section
> "The return from ServiceChange is empty except when the Root
>    terminationID is used.  In that case it includes the following
>    parameters as required:
>    * ServiceChangeMgcId, if the responding MGC does not wish
> to sustain
>       an association with the MG "
> I think this text makes more meaning and the ServiceChangeMgcId should
> be omitted when MGC accepts the ServiceChange command from MG.
>
> Thanks,
> Chennu.
>
>
> "Rosen, Brian" wrote:
>
> > This is the first in what I expect will be a series of
> > issues that we discover at the Interop.  Yes, testing has not
> > begun yet, but we already have one.  The question is, what does
> > the MGC send in a ServiceChange reply?
> >
> > The text currently states:
> >    Upon a cold start of the MG, it will issue a
> >    ServiceChange command with a "Restart" method, on the Root
> >    Termination to its primary MGC.  If the MGC accepts the MG,
> >    it will send a Transaction Accept, with the ServiceChangeMgcId
> >    set to itself.
> >
> > Following the usual IETF dictum about "be strict in what you
> > send, liberal in what you accept", MGCs SHOULD set
> > ServiceChangeMgcId, MGs should NOT depend on it.
> >
> > Brian
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Aug 2000 16:37:40 -0400

The actual confusing wording is:
Upon a cold start of the MG, it will issue a
   ServiceChange command with a "Restart" method, on the Root
   Termination to its primary MGC.  If the MGC accepts the MG, it will
   send a Transaction Accept, with the ServiceChangeMgcId set to
   itself.  If the MG receives an ServiceChangeMgcId not equal to the
   MGC it contacted, it sends a ServiceChange to the MGC specified in
   the ServiceChangeMgcId.

This says that you must send it.

The ABNF makes it optional

ServiceChange Descriptor text says:
   The optional ServiceChangeAddress parameter specifies the address
   (e.g., IP port number for IP networks) to be used for subsequent
   communications.  It can be specified in the input parameter
   descriptor or the returned result descriptor.  ServiceChangeAddress
   and ServiceChangeMgcId parameters must not both be present in the
   ServiceChangeDescriptor or the ServiceChangeResultDescriptor.  The
   ServiceChangeAddress provides an address to be used within the
   context of the association currently being negotiated, while the
   ServiceChangeMgcId provides an alternate address where the MG should
   seek to establish another association.
So it doesn't say whether it's optional or not, but doesn't give any other
use other than when the MGC asks the MG to change.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2000 4:03 PM