February 2001 - sg16-avd - lists.packetizer.com

RE: Protocol version re-negotiation
by Michael Brown 03 Mar '01

03 Mar '01

Nancy, The parameter that would be used is be the ServiceChangeAddress. As far as the assumption that the MGC would be provisioned with the primary and secondary MGs, certainly it could be done that way (and the text in 11.4 does imply this), but I do think that passing the address is an acceptable approach and should certainly be allowed. IMO we don't really need a new method for this. I don't see how adding a new method is more efficient. I still would contend that adding a ServiceChangeReason is sufficient and that it is desirable to do so (at least in V.2). Michael -----Original Message----- From: Nancy Devin [mailto:nancy.devin@alcatel.com] Sent: Tuesday, February 27, 2001 1:07 PM To: Brown, Michael [NC1:GW10:EXCH] Cc: ITU-SG16 Mail List; megaco(a)fore.com Subject: Re: Protocol version re-negotiation Hi Mike, I don't understand why your are talking about passing the address of the secondary MG to the MGC during a Failover. My understanding is that the MGC is configured with both the primary MG address and the secondary MG address (even though I did not find any text on that). If that is not the case then which parameter is used to transmit the address the the MGC. Also, I think the idea of having to Handoff to another MG or Failover to the other MG may not be the most efficient one. If we are to add a new reason then why not also add a new method which would be "VersionNegotiation" Method: VersionNegotiation TerminationID: Root Reason: MG directed change / MGC directed change Description: Sent from the MG to the MGC, the MG initiates a protocol version negotiation. Sent from the MGC to the MG, the MGC initiates a protocol version negotiation. Nancy Michael Brown wrote: > Comments inline. > > Michael > > "Rosen, Brian" wrote: > > > > > > I think you missed one point: "How does a NON-redundant MG > > > upgrade to a > > > new version of the protocol?" > > It comes down, reboots, and comes up again - it's a service affecting > > change. AFAIK, that's the only way today. > > <MB> Yes, if the MG is really Non-redundant there doesn't seem to be an option. > > > > > > > > > Can the MG Failover to itself? Will this cause any problems > > > in the MGC? > > Since that's not a defined option, some MGCs might have a problem. > > <MB> While there is no existing text specifically saying that this is allowed., > there also is none that disallows this behavior. It seems to me that the MGC > should just accept the "new" address for the "secondary" MG and go on. This > would be used when an MG and its mate hide behind a single address for the MGC > <> MG control association. I would think that this could easily be added to the > implementor's guide and I don't think that it should cause problems. > > > > > > > > > > > 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"." > > I think that's a scope add, which I for one am reluctant to do. > > If there was a real problem with something we already had, that's one thing, > > but a real feature add, I'm less thrilled about. I'll admit some of the > > things > > we have talked about stray at least close, if not over such a line. Here, > > I think an MG that can do a non-service affecting upgrade which is not > > redundant is pretty unusual these days - I don't mean to discourage folks > > from doing that, but I also don't feel we need changes in semantics (and > > some additional syntax, albeit some IANA registrations) to make it happen, > > it can wait for V2. > > <MB> I'm suppose I'd agree that this propoal is adding a new feature as it would > require a new, IANA registered reason and the associated behavior. I'd say it's > somewhat unfortunate because basically, I don't see problems with the proposed > approach. There is one thing about the approach that bothers me which we might > consider for V2. That is, the use of Failover in this instance seems > inappropriate. The name just seems to imply that a software upgrade is a failure > scenario. I would suggest that it would be nicer to enhance the definition of > Handoff rather than Failover since handoff implies a more graceful transition. > Given the current definitions of Handoff and Failover in version 1, we do have > to live with Failover for now. > > > > > > > > > > > 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(a)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 > > > > > > > > -- Nancy Devin Software Designer Alcatel 600 March Road, P.O. Box 13600 Kanata, Ontario, Canada K2K 2E6 Telephone: (613) 591-3600 x6897 Fax: (613) 599-3609 Internet: nancy.devin(a)alcatel.com

3 2

Liaison from Q11/16 to Q2, 3/16
by Les Brown 28 Feb '01

28 Feb '01

Paul, Glen, I don't know the procedure for requesting a contribution number for this liaison, so I am sending it to the reflector. Please consider it at your meeting next week. Les Brown, Rapporteur Q11/16 (See attached file: Liaison.zip)

1 0

Contribution AVD-2056 available
by Sayre, Clifford L, III (Clifford) 28 Feb '01

28 Feb '01

Dear All, Contribution AVD-2056 is available in the avc-site/0103_LAU folder. AVD-2056 is a proposal for a new annex to H.246 with the title "New annex to H.246: Interworking H.323 and H.324 Annex C" Also available is the related contribution AVD-2057, "New H.248 Packages to support Interworking between H.323 and H.324 Annex C" Comments are welcome. We look forward to discussing these contributions at the Launceston meeting. Thanks, Cliff Sayre Clifford Sayre Lucent Technologies Phone (732) 332-6060 clsayre(a)lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2083 revised
by BOUGANT Fran�ois FTRD/DAC/ISS 28 Feb '01

28 Feb '01

Dear experts, I just realized that I sent you a version of AVD-2083 containing some errors. Please find enclosed a revised version of AVD-2083 in zip format (name : AVD2083R1.zip). I am sorry again for the delay. Best regards, François BOUGANT & France Télécom R&D FTR&D/DAC/ACE e-mail :francois.bougant@francetelecom.fr 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42

1 0

AVD-2083 revised
by BOUGANT Fran�ois FTRD/DAC/ISS 28 Feb '01

28 Feb '01

Dear experts, I just realized that I sent you a version of AVD-2083 containing some errors. Please find enclosed a revised version of AVD-2083 in zip format (name : AVD2083R1.zip). I am sorry again for the delay. Best regards, François BOUGANT & France Télécom R&D FTR&D/DAC/ACE e-mail :francois.bougant@francetelecom.fr 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42 -----Message d'origine----- De : Gary Thom [mailto:gthom@DELTA-INFO.COM] Envoyé : mercredi 28 février 2001 15:33 À : ITU-SG16(a)MAILBAG.INTEL.COM Objet : AVD-2052 All, Attached is AVD-2052 for the Luanceston meeting. Paul or Mr. Okubo, I was not able to upload this document to the ftp site. could one of you please upload it for me. Thank you. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Christian Groves Sent: Tuesday, February 27, 2001 11:45 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: APC uploaded Hello, APC-2068 Improved Auditing in H.248 Version 2 APC-2069 Proposed Additions to the Implementors' Guide for H.248 APC-2070 Documenting H.248 Packages APC-2090 BICC CS3 contributions on end-to-end QoS service control APC-2091 Comments to SG 16 Draft H.GEF.2 (Number Portability Interworking between H.323 and SCN) have been uploaded to avc-site/Incoming. Regards, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Test tool Megaco/H.248
by SAVOURE Regis FTRD/DAC/LAN 28 Feb '01

28 Feb '01

Hello everybody, I'm beginning to work on the protocol Megaco/H.248 and i'm looking for tests systems to validate such protocols (analysor and simulator). Could you tell me if such products exist already and which industrials could provide me this kind of tool ... Thanks a lot, Régis Savouré France Telecom R&D DAC/ESN/IPI Tél : 33 2 96 05 13 51 Fax : 33 2 96 05 13 02 mailto:Regis.Savoure@rd.francetelecom.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC uploaded
by Christian Groves 28 Feb '01

28 Feb '01

Hello, APC-2068 Improved Auditing in H.248 Version 2 APC-2069 Proposed Additions to the Implementors' Guide for H.248 APC-2070 Documenting H.248 Packages APC-2090 BICC CS3 contributions on end-to-end QoS service control APC-2091 Comments to SG 16 Draft H.GEF.2 (Number Portability Interworking between H.323 and SCN) have been uploaded to avc-site/Incoming. Regards, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

TD-53 uploaded
by CHAPRON Jean-Emmanuel FTRD/DAC/ISS 28 Feb '01

28 Feb '01

TD-53 (H.248 Annex O) has been uploaded to the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/ . This is the same file as the one already discussed in Geneva. It is provided again in case of further dicussion. best regards, Jean-Emmanuel Chapron ``` (o o) ----------oOO--(_)-OOo-------------- Jean-Emmanuel CHAPRON FRANCE TELECOM R&D DAC/ACE 38-40 rue du général Leclerc 92794 Issy-les-Moulineaux Cedex 9 - France Tel: +33 1 45 29 64 50 ------------------------------------- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Q.G: TD-03 uploaded
by Euchner Martin 28 Feb '01

28 Feb '01

TD-03a with the title "SG9 security documents from Geneva" has been uploaded to the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/ <ftp://standard.pictel.com/avc-site/Incoming/> The file provides information on SG 9's security documents and in/outgoing liaisons from the past SG16 meeting Geneva. The material may be useful for review of AVD-2047. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

SCTP
by James Dam 27 Feb '01

27 Feb '01

Dear all, Could you please help. 1. Would H.323 (VoIP) eventually used SCTP (instead of UDP and TP)?. Regards James Dam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1