Subject: RE: Protocol version re-negotiation

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 22 Feb 2001 16:38:41 -0500

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:[email-masked]]
> Sent: Thursday, February 22, 2001 1:00 PM
> To: ITU-SG16 Mail List
> Cc: [email-masked]
> 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
>

---

From: Paul Rheaume <[email-masked]>
Date: Fri, 23 Feb 2001 11:34:28 -0500

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