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