Subject: RE: [Megaco] Version negotiation

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 27 Apr 2005 12:57:02 -0400

Indeed, Version is required on the initial registration message.  Version is
only required on the response if the MGC does not accept the version
proposed by the MG.  I will see that V3 is updated with this fix, and an IG
item is added to address this in V1 and V2.

Note also that the initial registration message must ALWAYS be encoded as
V1.

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, April 27, 2005 3:41 AM
To: Gillian Wang
Cc: [email-masked]
Subject: Re: [Megaco] Version negotiation

Hi,

H.248.1  v2  Corrigendum  1  (03/2004) has service change version parameter
present in the service change request in example call flow.

       "1)   An MG registers with an MGC using the ServiceChange command:

     MG1 to MGC:

     MEGACO/1 [124.124.124.222]
     Transaction = 9998 {
         Context = - {
             ServiceChange = ROOT {Services {
                 Method=Restart, Version=2,
                 ServiceChangeAddress=55555, Profile=ResGW/1}
             }
         }
     }"

Following is an extract from H.248.1 (05/2002).
      "11.3 Negotiation of protocol version

       A  ServiceChange  command from a MG that registers with an MGC shall
contain the version

       number    of   the   protocol   supported   by   the   MG   in   the
ServiceChangeVersion parameter. Regardless of

       the  version  placed  in  the  ServiceChangeVersion  parameter,  the
message containing the command

       shall be encoded as a version 1 message."

It makes service change version in the first service change request
mandatory. And message header will contain version 1 here regardless of
service change version parameter. If the MGC receives registration message
with Megaco message header 2 or service change version parameter absent,
then the MGC should report protocol error.

-------------------------------------------------

How ever there is another discrepancy in the ABNF specification of protocol.
It should not make service change version mandatory on the first service
change response.

Fllowing is extract of H.248.1 v2 Corrigendum 1 (03/2004) (B.2    ABNF
specification).
     "; at-most-once. Version is REQUIRED on first ServiceChange response
     ; at most one of either serviceChangeAddress or serviceChangeMgcId but
     ; not both
     servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
                            serviceChangeProfile / serviceChangeVersion /
                            TimeStamp)"

It implies that version is required in the first service change response.
But neither H.248.1 (05/2002) nor H.248.1 v2 Corrigendum 1 (03/2004) contain
the version in service change reply.

       "2)   The MGC sends a reply:

     MGC to MG1:
     MEGACO/1 [123.123.123.4]:55555
     Reply = 9998 {
        Context = - {ServiceChange = ROOT {
          Services {ServiceChangeAddress=55555, Profile=ResGW/1} } }
     }"

and H.248.1 v2 Corrigendum 1 (03/2004) section 11.3 indicates that service
change version is optional in first service change reply from MGC.
Following is extract of H.248.1 v2 Corrigendum 1 (03/2004)
      "If the MGC supports the version indicated by the MG, it shall conform
to that version in all
      subsequent messages. In this case, it is optional for the MGC to
return a version in the
      ServiceChangeReply."

Regards,
Sudhanshu
Flextronics Software Systems
www.hssworld.com

"Gillian Wang" <[email-masked]>@ietf.org on 04/26/2005 12:49:30 PM

Sent by:    [email-masked]

To:    <[email-masked]>
cc:

Subject:    [Megaco] Version negotiation

Hi all,

Section 11.3 of H.248.1 provides a method of version negotiation in
ServiceChange command. But the example call flows show a simple way without
version negotiation.

My question is:

Is this ServiceChangeVersion parameter mandatory in the MG REGISTRATION
time? If no ServiceChangeVersion indicated in the serviceChange command from
MG (as the example does in Appendix I), what should MGC do? Suppose that MGC
can support the version indicated in the message header (MEGACO/2 [....])?
Follow the version received from the header of serviceChange command or
report an error?

Thanks for the clarifications.

Regards
Gillian

_______________________________________________
Megaco mailing list
[email-masked]
 https://www1.ietf.org/mailman/listinfo/megaco
 IMPORTANT: HUGHES SOFTWARE SYSTEMS LTD. (HSS) IS NOW FLEXTRONICS SOFTWARE
SYSTEMS LTD. (FSS)

 *****************    FSS-Private    *************

"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the individual to whom
it is addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in  error, please notify the
originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing the
contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted by this email
including damage from virus."

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco