AVD-2085 uploaded

[Folts, Harold]

Brian,

How do we add features to the protocol?

I think you missed one point: "How does a NON-redundant MG upgrade to a
new version of the protocol?"

Can the MG Failover to itself? Will this cause any problems in the MGC?

To allow this requires only a few changes to the text in RFC3015 as
follows:
Section 7.2.8 ServiceChange
Modify text: "6) Failover - sent from MG to MGC to indicate the primary
MG is out of service and a secondary is taking over, or to indicate a
version negotiation from the MG."
Add a Reason: "Version Negotiation" or a more generic "MG Directed
Change".
Add text: "The MG may initiate a version negotiation with a
ServiceChange Command specifying the "Root" for the TerminationID,
ServiceChangeMethod equal to Failover and ServiceChangeReason equal to
"Version Negotiation"."

Cheers,
Paul

"Rosen, Brian" wrote:
> 
> It's unlikely that we will do anything that adds
> new features by edits to the implementor's guide.
> It's reasonable to have explanatory text in such a
> document that is not normative.
> 
> I think you failover, upgrade, and failover back
> with this version of the protocol.
> 
> Brian
> 
> > -----Original Message-----
> > From: Paul Rheaume [mailto:paul.rheaume at alcatel.com]
> > Sent: Thursday, February 22, 2001 1:00 PM
> > To: ITU-SG16 Mail List
> > Cc: megaco at fore.com
> > Subject: Re: Protocol version re-negotiation
> >
> >
> > Folks,
> >
> > Where is the appropriate list to discuss this issue?
> >
> > We feel that version negotiation and the version upgrade
> > process is not
> > well specified and needs to be discussed and properly defined at the
> > latest in version 2 of the specification. That means looking at this
> > very soon.
> >
> > I think this issue belongs to the next version of the Implementor's
> > Guide.
> >
> > Regards,
> > Paul
> >
> > Nancy Devin wrote:
> > >
> > > How does a non-redundant MG upgrade to a new
> > > Megaco version without affecting service?  How
> > > does a redundant MG upgrade to a new Megaco
> > > version without affecting service?
> > >
> > > It is mentionned in RFC3015 that Protocol version
> > > negotiation can be done at Restart, Failover, and
> > > Handoff serviceChanges.  It is not mentionned
> > > explicitly how version protocol re-negotiation is
> > > done after the MG has registered with the MGC. in
> > > both situation
> > >
> > > This could be done in at least two different ways
> > > as listed bellow.
> > >
> > > 1-    Protocol version negotiation could be
> > > initiated using the Failover serviceChange.  A
> > > Failover serviceChange with a protocol version
> > > would indicate that the MG has been configured
> > > with a new H.248 protocol version.  Sent from the
> > > MG to the MGC, it indicates that the MG has been
> > > configured with a new H.248 protocol version.
> > > This serviceChange shall not indicate Failure of
> > > the working MG.  This would require that for
> > > non-redundant MGs, both the primary IP address and
> > > the secondary IP address be the same.
> > >
> > > 2-    Protocol version negotiation could be
> > > intiated using a new serviceChange method:
> > > VersionNegotiation (Method 7 of the serviceChange
> > > command as defined in RFC3015) This serviceChange
> > > would be sent from the MG to the MGC to initiate
> > > protocol version initiation.  It indicates that
> > > the MG has been configured with a new H.248
> > > protocol version.  Sent from the MGC to the MG, it
> > > indicates that the MGC has been configured with a
> > > new H.248 protocol version.
> > >
> > > Comments please.
> > > Nancy
> >