How do I get on the SG16 mailing list? -Mart

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@alcatel.com] Sent: Thursday, February 22, 2001 1:00 PM To: ITU-SG16 Mail List Cc: megaco@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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com