- sg16-avd - lists.packetizer.com

Re: Last Call for the SIP-H.323 Interworking Requirements draft
by Roy, Radhika R, ALCOO 13 Mar '01

13 Mar '01

Hi, Chip and All: Any mailing list will be fine. However, I would prefer to send the comments in the SG16 mailing list because although the respective WG Chairs in the IETF are planning to send the notice in their mailing lists to receive comments soon (I am yet to know exactly when they will notify it). Best regards, Radhika R. Roy -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, March 13, 2001 11:47 AM To: Roy, Radhika R, ALCOO Cc: ITU-SG16(a)mailbag.… [View More]

1 0

Re: Last Call for the SIP-H.323 Interworking Requirements draft
by Chip Sharp 13 Mar '01

13 Mar '01

Roy, Thanks for the notice. To which mail list should comments be sent (SG16, sip, iptel, megaco or spirit)? Thanks, Chip At 10:57 AM 3/13/2001 -0500, Roy, Radhika R, ALCOO wrote: >Hi, Everyone: > >We are pleased to let you know that the last call for the following draft >has been requested in the SIP, IPTEL, MEGACO and SPIRIT WG: > >http://search.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-r >eqs-02.txt > >Authors: Hemant Agrawal, Radhika R. Roy, … [View More]

1 0

Last Call for the SIP-H.323 Interworking Requirements draft
by Roy, Radhika R, ALCOO 13 Mar '01

13 Mar '01

Hi, Everyone: We are pleased to let you know that the last call for the following draft has been requested in the SIP, IPTEL, MEGACO and SPIRIT WG: http://search.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-r eqs-02.txt Authors: Hemant Agrawal, Radhika R. Roy, Vipin Palawat, Alan Johnston, Charles Agboh, David Wang, Kundan Singh, and Henning Schulzrinne Abstract: This document describes the requirements for the logical entity known as the SIP-H.323 Interworking Function (… [View More]

1 0

liaison from SG9
by Glen Freundlich 12 Mar '01

12 Mar '01

Dear Colleagues, Attached is a liaison from SG9 related to trunking gateway protocols. I would have preferred to discus this during last week's meeting, but had problems getting email on the last day of the meeting. If you have any comments, please post them to this mail list. I will draft a liaison reply to send by the end of this week. Best Regards, Glen

1 0

Re: Protocol version re-negotiation
by Nancy Devin 12 Mar '01

12 Mar '01

Good morning Christian, The reason why we had put this solution aside is that the RFC specifies that version negotiation occurs at registration and possibly at failover and handoff. Since re-negotiation is done once the MG is registered with the MGC, will the serviceChange with the method "warm boot" and "restart" be considered a registration request even though the MG is already registered? Nancy Christian Groves wrote: > G'Day, > > There's been a few points raised in this … [View More]thread. It seems to me that > people are getting a "protocol version upgrade of Megaco" and an > "upgrade of the MG" mixed up. I don't see the need for bringing down the > whole MG just to update the Megaco interface. We have protocol version > negotiation procedures H.248 sect 11.3. We can issue a ServiceChange > with the new version number, method "warm boot" and "restart" and not > loose state on the MG. See Annex L - > > 3.4 Reason # : 902 Name: Warm Boot > Definition: This indicates that the entity indicated with the > TerminationID is in ServiceState "in-Service", and that it has gone > through a start or recovery action. All transactions in process may be > lost, but otherwise all state is preserved on the termination. > Reference: - > Text in the Service Change extension: - > Comment: This reason code only applies for TerminationID root. > > So I don't see what the issue is. > > Any new functionality to add new methods is really something for H248v2. > > Cheers, Christian > > Michael Brown wrote: > > > > 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 -- 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 [View Less]

1 0

RE: Protocol version re-negotiation
by Tom-PT Taylor 12 Mar '01

12 Mar '01

> -----Original Message----- > From: Nancy Devin [mailto:nancy.devin@alcatel.com] > Sent: Wednesday, March 07, 2001 9:10 AM > To: Christian.Groves(a)ericsson.com > Cc: megaco(a)fore.com; ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: Protocol version re-negotiation > > > Good morning Christian, > > I agree with you that the reason "warm boot" > describes perfectly the state of the MG when it > upgrades to a new version of the H.248 protocol. > > … [View More]

1 0

Fwd: [VCEG] Strengthening our relationship with MPEG
by OKUBO Sakae 11 Mar '01

11 Mar '01

Dear SG16 system experts, For your information, please find attached Mr. Sullivan's message posted at the Q.6/16 video coding experts group reflector. Best regards, OKUBO Sakae *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) … [View More]Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** >From: Gary Sullivan <garysull(a)microsoft.com> >To: "'itu-adv-video(a)standard.pictel.com'"<itu-adv-video(a)standard.pictel.com> >Cc: "Thomas Wiegand (HHI) (E-mail)" <wiegand(a)hhi.de> >Subject: [VCEG] Strengthening our relationship with MPEG >Date: Fri, 9 Mar 2001 18:34:08 -0800 >Sender: itu-adv-video-owner(a)standard.pictel.com > >ITU-T Video Coding Experts Group (VCEG) [Q.6/SG16] >Email from Gary Sullivan <garysull(a)microsoft.com>: > > >Experts, > >MPEG has just made significant gestures toward forming a >stronger relationship with ITU-T VCEG. Thomas and I and >others have recently sought an improved collaborative >relationship with MPEG and have found that our interest >was reciprocated with equal strength. > >Some of you may have heard that I was just appointed >as the chairman of the MPEG video group and that I served in >that capacity this week at the MPEG meeting in Singapore. > >This does not mean that I plan to diminish my role in the >ITU in any way. In fact, I have intended strong service >to the ITU community in my efforts toward coordination >with MPEG. I hope that I can use my "two hats" to ensure >having a strong and cooperative relationship between MPEG >and VCEG, and minimize any potential duplication of effort. > >In addition to our already-expressed intent to participate >in MPEG's upcoming testing effort seeking improved >video compression technology, I have taken the liberty this >week of pre-registering ITU-T VCEG as a potential participant >in MPEG's additional testing effort seeking designs suitable >for Digital Cinema video coding. Since we can still pull >out of this test plan and since MPEG sought early pre- >registration by this week from interested organizations, I >used my discretion as rapporteur (in consultation with Thomas) >to pre-register the ITU-T VCEG for those upcoming Digital Cinema >tests. > >VCEG's ultimate participation in MPEG's Digital Cinema tests would >mean that we need to significantly enhance our current H.26L software >(at least for issues already embraced in spirit such as flexible >picture size, support of 4:4:4 color spaces, and support of 12-bit >sample quantization accuracy). However, I believe that VCEG should >work to test our H.26L design in this demanding new domain and >should work with MPEG to help determine what efforts are needed >by the video coding standardization community to address this >important new application. > >The next few months should be an exciting period in the video coding >community. I hope VCEG can show very strong performance in >MPEG's upcoming tests. I also hope that ITU-T VCEG and ISO/IEC >MPEG can work very closely together in the future as a strong >collaborative team toward standard development efforts to serve >the needs of the global multimedia industry. > >Best Wishes, > >Gary Sullivan > > >--------------------------------------------------------------------------- >----- >*** ITU-T Video Coding Experts Group (VCEG) [Q.6/SG16] Email List Message *** >To send messages, address them to "itu-adv-video(a)standard.pictel.com". >To subscribe or unsubscribe, send email to "majordomo(a)standard.pictel.com". >Note: Only people whose exact email address is subscribed to the list can >post. >Subscriptions: "subscribe itu-adv-video YOUR-EMAIL-ADDRESS" in message body. >Unsubscriptions: "unsubscribe itu-adv-video YOUR-EMAIL-ADDRESS" in message >body. >--------------------------------------------------------------------------- >----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

Re: [Fwd: AVT WG last call on RTP spec and profile]
by Simao Campos-Neto 09 Mar '01

09 Mar '01

Dear colleagues, regarding my recent message on the subject, the AVT profile can be found at http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-10.txt Regards, Simao.

1 0

[Fwd: AVT WG last call on RTP spec and profile]
by Simao Campos-Neto 09 Mar '01

09 Mar '01

Dear colleagues, please see in the attached that audio payload formats for G.723.1, called there "G723", has been removed from the latest RTP A/V profile because of the lack on information that interoperable implementations of them exist. Other audio payload formats have also been removed, e.g. H263 (this is not the same as H263-2000), GSM-HR, GSM-EFR, If you know of such implementations, there is still some VERY short time (less than 2 weeks) before the IETF issues the repeat WG last call. … [View More]

1 0

Re: Quick question on a Request for package registration
by Rosen, Brian 08 Mar '01

08 Mar '01

Yes, you must specify both when defining a package. Brian -----Original Message----- From: Kevin Gorey [mailto:kgorey@nortelnetworks.com] Sent: Thursday, March 08, 2001 6:52 AM To: 'ian.park(a)vf.vodafone.co.uk'; Tom-PT Taylor; 'iana(a)iana.org' Cc: 'megaco(a)fore.com'; 'itu-sg16(a)mailbag.cps.intel.com' Subject: RE: Quick question on a Request for package registration Dear all, As I've been involved in 3GPP working group discussions regarding these 3GPP H.248 extentions, I'd like to … [View More]provide some additional information/comments. Although the 3GPP working groups view is that the 3GPP specification that contains the package definations in question is 95% complete. In my opinion these packages are not currently technically stable, during the last meeting the technical details for the encoding of the TFO package were not agreed. Additionally, there is the open issue within 3GPP as to whether these 3GPP H.248 specifications should be specified for both text and binary encodings, or whether only one encoding type should be chosen. However from reading clause 13.1 of H.248 (reproduced below) it seems that its a mandatory requirement to specify both a text and binary encoding of additional packages. 13.1 Packages The following considerations SHALL be met to register a package with IANA: 1) A unique string name, unique serial number and version number is registered for each package. The string name is used with text encoding. The serial number shall be used with binary encoding. Serial Numbers 60000-64565 are reserved for private use. Serial number 0 is reserved. ..." Regards, Kevin. ----------------- Kevin Gorey Nortel Networks, UMTS Strategic Product Planning Tel: +44 (0)1628 434606 Fax: +44 (0)1628 434034 kgorey(a)nortelnetworks.com -----Original Message----- From: ian.park(a)vf.vodafone.co.uk [SMTP:ian.park@vf.vodafone.co.uk] Sent: Wednesday, March 07, 2001 10:40 AM To: Taylor, Tom-PT [NORSE:B881:EXCH]; iana(a)iana.org Cc: megaco(a)fore.com; itu-sg16(a)mailbag.cps.intel.com; ian.park(a)vf.vodafone.co.uk Subject: RE: Quick question on a Request for package registration Dear all FWIW, I agree entirely with Michelle's assessment. 3GPP specifications are *definitely* public documents (and we require that any document which is cited as a reference in a 3GPP specification is, in turn, a publicly available document). On Tom Taylor's point about the stability of the specifications, we agreed at last week's working group meeting that the specifications are now ready for approval (which means that they will be brought under a formal change control system). They will be presented for approval at the meeting of Technical Specification Group Core network next week (14 - 16 March) in Palm Springs, CA. I hope this helps. Best regards Ian Park ___________________________________________________ Ian Park Chief Engineer, Core Network Signalling Standards Vodafone Limited *T: +44 1635 673 527 *F: +44 1635 233 562 ?E: ian.park(a)vf.vodafone.co.uk ___________________________________________________ -----Original Message----- From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com <mailto:taylor@nortelnetworks.com> ] Sent: 26 February 2001 10:50 To: IANA Cc: megaco(a)fore.com; itu-sg16(a)mailbag.intel.com; ian.park(a)vf.vodafone.co.uk Subject: RE: Quick question on a Request for package registration 3GPP is a public forum, and I believe their packages would be viewed as public. I'll note that it is desirable that the packages be considered technically stable (though perhaps subject to some editing and minor adjustment) before they are registered. I've copied various parties for coordination purposes. > -----Original Message----- > From: IANA [ mailto:iana@iana.org <mailto:iana@iana.org> < mailto:iana@iana.org <mailto:iana@iana.org> > ] > Sent: Friday, February 23, 2001 5:28 PM > To: Taylor, Tom-PT [NORSE:B881:EXCH] > Subject: FW: Quick question on a Request for package registration > > > Tom, > > Quick question. Which range should these packages be registered in? > Do I need to ask the applicants if these are public or private? > > From the RFC: > Public packages MUST be given serial numbers in the range 0x0001 to > 0x7fff. Private packages MUST be given serial numbers in the range > 0x8000 to 0xffff. > > Thanks for any help. If there is someone better to ask, please let me > know. Don't want to bug you :) > > Michelle > IANA > > ************************************************************** > *********** > > Hi there > > I am the editor for a 3rd Generation Partnership Project > (3GPP) protocol > specification which defines extensions to the H.248/MeGaCo > protocol; I have > pasted in a copy of the "Scope" clause of this specification below. > > "The present document describes the protocol to be used on > the Media Gateway > Controller (MGC) - Media Gateway (MGW) interface. The Media Gateway > Controllers covered in this specification are the MSC server > and the GMSC > server. The basis for this protocol is the H.248/MEGACO protocol as > specified in ITU-T and IETF. The BICC architecture as > described in ITU-T > Q.1902 [7]-[11] and 3G TS 23.205 [3] defines the usage of > this protocol. > This specification describes the changes to H.248/MEGACO > which are needed to > handle 3GPP specific traffic cases. This is done by using the > H.248/MEGCO > standard extension mechanism. > The present document is valid for a 3rd generation PLMN > (UMTS) complying > with Release 2000 and later. " > We need to define three new packages for this specification, > and as the > custodians of the package identifiers you are the people I > need to contact > to ask for the package numbers! > > I have pasted in the first part of the definition of each > package below. > > 13.1.1 IuUP package. > PackageID: 3giuup (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package identifies that the Iu User Plane is used for > the termination. > It also contains some parameters for the Iu User Plane > functions in the MGW. > The Iu User Plane is active in both directions independently > of the Stream > Mode. > 13.1.2 Circuit Switched Data package > PackageID: 3gcsd (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package contains the information needed to be able to > support GSM and > UMTS Circuit Switched Data from the media gateway. > 13.1.3 TFO package > PackageID: 3gtfoc (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package defines events and properties for Tandem Free > Operation (TFO) > control. TFO uses inband signalling and procedures for > Transcoders to enable > compressed speech to be maintained between a tandem pair of > transcoders. > This package allows an MGW which has inserted a transcoder to > support TFO. > Can you please let me know how I should go on from here to > have the package > numbers allocated? If you need any further information, > please contact me. > > Best regards > > Ian Park > > ___________________________________________________ > Ian Park > Chief Engineer, Core Network Signalling Standards > Vodafone Limited > *T: +44 1635 673 527 > *F: +44 1635 233 562 > *E: ian.park(a)vf.vodafone.co.uk > ___________________________________________________ > > > [View Less]

1 0

Re: Protocol version re-negotiation
by Nancy Devin 08 Mar '01

08 Mar '01

Good morning Christian, I agree with you that the reason "warm boot" describes perfectly the state of the MG when it upgrades to a new version of the H.248 protocol. I have question on the use of "restart" and "root". According the RFC3015, this combination indicates a registration command. Since the registration command should be the first command received from an MG after it comes in service, what happens when this command is received while the MG is already in service? Also, there seems … [View More]

2 2

RE: Quick question on a Request for package registration
by Kevin Gorey 08 Mar '01

08 Mar '01

Dear all, As I've been involved in 3GPP working group discussions regarding these 3GPP H.248 extentions, I'd like to provide some additional information/comments. Although the 3GPP working groups view is that the 3GPP specification that contains the package definations in question is 95% complete. In my opinion these packages are not currently technically stable, during the last meeting the technical details for the encoding of the TFO package were not agreed. Additionally, there is the open … [View More]issue within 3GPP as to whether these 3GPP H.248 specifications should be specified for both text and binary encodings, or whether only one encoding type should be chosen. However from reading clause 13.1 of H.248 (reproduced below) it seems that its a mandatory requirement to specify both a text and binary encoding of additional packages. 13.1 Packages The following considerations SHALL be met to register a package with IANA: 1) A unique string name, unique serial number and version number is registered for each package. The string name is used with text encoding. The serial number shall be used with binary encoding. Serial Numbers 60000-64565 are reserved for private use. Serial number 0 is reserved. ..." Regards, Kevin. ----------------- Kevin Gorey Nortel Networks, UMTS Strategic Product Planning Tel: +44 (0)1628 434606 Fax: +44 (0)1628 434034 kgorey(a)nortelnetworks.com > -----Original Message----- > From: ian.park(a)vf.vodafone.co.uk [SMTP:ian.park@vf.vodafone.co.uk] > Sent: Wednesday, March 07, 2001 10:40 AM > To: Taylor, Tom-PT [NORSE:B881:EXCH]; iana(a)iana.org > Cc: megaco(a)fore.com; itu-sg16(a)mailbag.cps.intel.com; > ian.park(a)vf.vodafone.co.uk > Subject: RE: Quick question on a Request for package registration > > Dear all > > FWIW, I agree entirely with Michelle's assessment. 3GPP specifications are > *definitely* public documents (and we require that any document which is > cited as a reference in a 3GPP specification is, in turn, a publicly > available document). > > On Tom Taylor's point about the stability of the specifications, we agreed > at last week's working group meeting that the specifications are now ready > for approval (which means that they will be brought under a formal change > control system). They will be presented for approval at the meeting of > Technical Specification Group Core network next week (14 - 16 March) in > Palm > Springs, CA. > > I hope this helps. > > Best regards > > Ian Park > ___________________________________________________ > Ian Park > Chief Engineer, Core Network Signalling Standards > Vodafone Limited > *T: +44 1635 673 527 > *F: +44 1635 233 562 > ?E: ian.park(a)vf.vodafone.co.uk > ___________________________________________________ > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: 26 February 2001 10:50 > To: IANA > Cc: megaco(a)fore.com; itu-sg16(a)mailbag.intel.com; > ian.park(a)vf.vodafone.co.uk > Subject: RE: Quick question on a Request for package registration > > > > 3GPP is a public forum, and I believe their packages would be viewed as > public. I'll note that it is desirable that the packages be considered > technically stable (though perhaps subject to some editing and minor > adjustment) before they are registered. > > I've copied various parties for coordination purposes. > > > -----Original Message----- > > From: IANA [ mailto:iana@iana.org <mailto:iana@iana.org> ] > > Sent: Friday, February 23, 2001 5:28 PM > > To: Taylor, Tom-PT [NORSE:B881:EXCH] > > Subject: FW: Quick question on a Request for package registration > > > > > > Tom, > > > > Quick question. Which range should these packages be registered in? > > Do I need to ask the applicants if these are public or private? > > > > From the RFC: > > Public packages MUST be given serial numbers in the range 0x0001 to > > 0x7fff. Private packages MUST be given serial numbers in the range > > 0x8000 to 0xffff. > > > > Thanks for any help. If there is someone better to ask, please let me > > know. Don't want to bug you :) > > > > Michelle > > IANA > > > > ************************************************************** > > *********** > > > > Hi there > > > > I am the editor for a 3rd Generation Partnership Project > > (3GPP) protocol > > specification which defines extensions to the H.248/MeGaCo > > protocol; I have > > pasted in a copy of the "Scope" clause of this specification below. > > > > "The present document describes the protocol to be used on > > the Media Gateway > > Controller (MGC) - Media Gateway (MGW) interface. The Media Gateway > > Controllers covered in this specification are the MSC server > > and the GMSC > > server. The basis for this protocol is the H.248/MEGACO protocol as > > specified in ITU-T and IETF. The BICC architecture as > > described in ITU-T > > Q.1902 [7]-[11] and 3G TS 23.205 [3] defines the usage of > > this protocol. > > This specification describes the changes to H.248/MEGACO > > which are needed to > > handle 3GPP specific traffic cases. This is done by using the > > H.248/MEGCO > > standard extension mechanism. > > The present document is valid for a 3rd generation PLMN > > (UMTS) complying > > with Release 2000 and later. " > > We need to define three new packages for this specification, > > and as the > > custodians of the package identifiers you are the people I > > need to contact > > to ask for the package numbers! > > > > I have pasted in the first part of the definition of each > > package below. > > > > 13.1.1 IuUP package. > > PackageID: 3giuup (0x####) > > [Editor's note: PackageID to be allocated by IANA] > > Version: 1 > > Extends: None > > This package identifies that the Iu User Plane is used for > > the termination. > > It also contains some parameters for the Iu User Plane > > functions in the MGW. > > The Iu User Plane is active in both directions independently > > of the Stream > > Mode. > > 13.1.2 Circuit Switched Data package > > PackageID: 3gcsd (0x####) > > [Editor's note: PackageID to be allocated by IANA] > > Version: 1 > > Extends: None > > This package contains the information needed to be able to > > support GSM and > > UMTS Circuit Switched Data from the media gateway. > > 13.1.3 TFO package > > PackageID: 3gtfoc (0x####) > > [Editor's note: PackageID to be allocated by IANA] > > Version: 1 > > Extends: None > > This package defines events and properties for Tandem Free > > Operation (TFO) > > control. TFO uses inband signalling and procedures for > > Transcoders to enable > > compressed speech to be maintained between a tandem pair of > > transcoders. > > This package allows an MGW which has inserted a transcoder to > > support TFO. > > Can you please let me know how I should go on from here to > > have the package > > numbers allocated? If you need any further information, > > please contact me. > > > > Best regards > > > > Ian Park > > > > ___________________________________________________ > > Ian Park > > Chief Engineer, Core Network Signalling Standards > > Vodafone Limited > > *T: +44 1635 673 527 > > *F: +44 1635 233 562 > > *E: ian.park(a)vf.vodafone.co.uk > > ___________________________________________________ > > > > > > > [View Less]

1 0

RE: Quick question on a Request for package registration
by Michael Brown 08 Mar '01

08 Mar '01

Not having been involved in the 3GPP work I was not aware of the 3 new packages referred to in the initial email. Could someone provide info on where to obtain copies of these packages? Thanks, Michael Brown -----Original Message----- From: ian.park(a)vf.vodafone.co.uk [mailto:ian.park@vf.vodafone.co.uk] Sent: Wednesday, March 07, 2001 5:40 AM To: Taylor, Tom-PT [NORSE:B881:EXCH]; iana(a)iana.org Cc: megaco(a)fore.com; itu-sg16(a)mailbag.cps.intel.com; ian.park(a)vf.vodafone.co.uk Subject: … [View More]RE: Quick question on a Request for package registration Dear all FWIW, I agree entirely with Michelle's assessment. 3GPP specifications are *definitely* public documents (and we require that any document which is cited as a reference in a 3GPP specification is, in turn, a publicly available document). On Tom Taylor's point about the stability of the specifications, we agreed at last week's working group meeting that the specifications are now ready for approval (which means that they will be brought under a formal change control system). They will be presented for approval at the meeting of Technical Specification Group Core network next week (14 - 16 March) in Palm Springs, CA. I hope this helps. Best regards Ian Park ___________________________________________________ Ian Park Chief Engineer, Core Network Signalling Standards Vodafone Limited *T: +44 1635 673 527 *F: +44 1635 233 562 ?E: ian.park(a)vf.vodafone.co.uk ___________________________________________________ -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: 26 February 2001 10:50 To: IANA Cc: megaco(a)fore.com; itu-sg16(a)mailbag.intel.com; ian.park(a)vf.vodafone.co.uk Subject: RE: Quick question on a Request for package registration 3GPP is a public forum, and I believe their packages would be viewed as public. I'll note that it is desirable that the packages be considered technically stable (though perhaps subject to some editing and minor adjustment) before they are registered. I've copied various parties for coordination purposes. > -----Original Message----- > From: IANA [ mailto:iana@iana.org <mailto:iana@iana.org> ] > Sent: Friday, February 23, 2001 5:28 PM > To: Taylor, Tom-PT [NORSE:B881:EXCH] > Subject: FW: Quick question on a Request for package registration > > > Tom, > > Quick question. Which range should these packages be registered in? > Do I need to ask the applicants if these are public or private? > > From the RFC: > Public packages MUST be given serial numbers in the range 0x0001 to > 0x7fff. Private packages MUST be given serial numbers in the range > 0x8000 to 0xffff. > > Thanks for any help. If there is someone better to ask, please let me > know. Don't want to bug you :) > > Michelle > IANA > > ************************************************************** > *********** > > Hi there > > I am the editor for a 3rd Generation Partnership Project > (3GPP) protocol > specification which defines extensions to the H.248/MeGaCo > protocol; I have > pasted in a copy of the "Scope" clause of this specification below. > > "The present document describes the protocol to be used on > the Media Gateway > Controller (MGC) - Media Gateway (MGW) interface. The Media Gateway > Controllers covered in this specification are the MSC server > and the GMSC > server. The basis for this protocol is the H.248/MEGACO protocol as > specified in ITU-T and IETF. The BICC architecture as > described in ITU-T > Q.1902 [7]-[11] and 3G TS 23.205 [3] defines the usage of > this protocol. > This specification describes the changes to H.248/MEGACO > which are needed to > handle 3GPP specific traffic cases. This is done by using the > H.248/MEGCO > standard extension mechanism. > The present document is valid for a 3rd generation PLMN > (UMTS) complying > with Release 2000 and later. " > We need to define three new packages for this specification, > and as the > custodians of the package identifiers you are the people I > need to contact > to ask for the package numbers! > > I have pasted in the first part of the definition of each > package below. > > 13.1.1 IuUP package. > PackageID: 3giuup (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package identifies that the Iu User Plane is used for > the termination. > It also contains some parameters for the Iu User Plane > functions in the MGW. > The Iu User Plane is active in both directions independently > of the Stream > Mode. > 13.1.2 Circuit Switched Data package > PackageID: 3gcsd (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package contains the information needed to be able to > support GSM and > UMTS Circuit Switched Data from the media gateway. > 13.1.3 TFO package > PackageID: 3gtfoc (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package defines events and properties for Tandem Free > Operation (TFO) > control. TFO uses inband signalling and procedures for > Transcoders to enable > compressed speech to be maintained between a tandem pair of > transcoders. > This package allows an MGW which has inserted a transcoder to > support TFO. > Can you please let me know how I should go on from here to > have the package > numbers allocated? If you need any further information, > please contact me. > > Best regards > > Ian Park > > ___________________________________________________ > Ian Park > Chief Engineer, Core Network Signalling Standards > Vodafone Limited > *T: +44 1635 673 527 > *F: +44 1635 233 562 > *E: ian.park(a)vf.vodafone.co.uk > ___________________________________________________ > > > [View Less]

1 0

RE: Quick question on a Request for package registration
by ian.park＠vf.vodafone.co.uk 07 Mar '01

07 Mar '01

Dear all FWIW, I agree entirely with Michelle's assessment. 3GPP specifications are *definitely* public documents (and we require that any document which is cited as a reference in a 3GPP specification is, in turn, a publicly available document). On Tom Taylor's point about the stability of the specifications, we agreed at last week's working group meeting that the specifications are now ready for approval (which means that they will be brought under a formal change control system). They … [View More]will be presented for approval at the meeting of Technical Specification Group Core network next week (14 - 16 March) in Palm Springs, CA. I hope this helps. Best regards Ian Park ___________________________________________________ Ian Park Chief Engineer, Core Network Signalling Standards Vodafone Limited *T: +44 1635 673 527 *F: +44 1635 233 562 ?E: ian.park(a)vf.vodafone.co.uk ___________________________________________________ -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: 26 February 2001 10:50 To: IANA Cc: megaco(a)fore.com; itu-sg16(a)mailbag.intel.com; ian.park(a)vf.vodafone.co.uk Subject: RE: Quick question on a Request for package registration 3GPP is a public forum, and I believe their packages would be viewed as public. I'll note that it is desirable that the packages be considered technically stable (though perhaps subject to some editing and minor adjustment) before they are registered. I've copied various parties for coordination purposes. > -----Original Message----- > From: IANA [ mailto:iana@iana.org <mailto:iana@iana.org> ] > Sent: Friday, February 23, 2001 5:28 PM > To: Taylor, Tom-PT [NORSE:B881:EXCH] > Subject: FW: Quick question on a Request for package registration > > > Tom, > > Quick question. Which range should these packages be registered in? > Do I need to ask the applicants if these are public or private? > > From the RFC: > Public packages MUST be given serial numbers in the range 0x0001 to > 0x7fff. Private packages MUST be given serial numbers in the range > 0x8000 to 0xffff. > > Thanks for any help. If there is someone better to ask, please let me > know. Don't want to bug you :) > > Michelle > IANA > > ************************************************************** > *********** > > Hi there > > I am the editor for a 3rd Generation Partnership Project > (3GPP) protocol > specification which defines extensions to the H.248/MeGaCo > protocol; I have > pasted in a copy of the "Scope" clause of this specification below. > > "The present document describes the protocol to be used on > the Media Gateway > Controller (MGC) - Media Gateway (MGW) interface. The Media Gateway > Controllers covered in this specification are the MSC server > and the GMSC > server. The basis for this protocol is the H.248/MEGACO protocol as > specified in ITU-T and IETF. The BICC architecture as > described in ITU-T > Q.1902 [7]-[11] and 3G TS 23.205 [3] defines the usage of > this protocol. > This specification describes the changes to H.248/MEGACO > which are needed to > handle 3GPP specific traffic cases. This is done by using the > H.248/MEGCO > standard extension mechanism. > The present document is valid for a 3rd generation PLMN > (UMTS) complying > with Release 2000 and later. " > We need to define three new packages for this specification, > and as the > custodians of the package identifiers you are the people I > need to contact > to ask for the package numbers! > > I have pasted in the first part of the definition of each > package below. > > 13.1.1 IuUP package. > PackageID: 3giuup (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package identifies that the Iu User Plane is used for > the termination. > It also contains some parameters for the Iu User Plane > functions in the MGW. > The Iu User Plane is active in both directions independently > of the Stream > Mode. > 13.1.2 Circuit Switched Data package > PackageID: 3gcsd (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package contains the information needed to be able to > support GSM and > UMTS Circuit Switched Data from the media gateway. > 13.1.3 TFO package > PackageID: 3gtfoc (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package defines events and properties for Tandem Free > Operation (TFO) > control. TFO uses inband signalling and procedures for > Transcoders to enable > compressed speech to be maintained between a tandem pair of > transcoders. > This package allows an MGW which has inserted a transcoder to > support TFO. > Can you please let me know how I should go on from here to > have the package > numbers allocated? If you need any further information, > please contact me. > > Best regards > > Ian Park > > ___________________________________________________ > Ian Park > Chief Engineer, Core Network Signalling Standards > Vodafone Limited > *T: +44 1635 673 527 > *F: +44 1635 233 562 > *E: ian.park(a)vf.vodafone.co.uk > ___________________________________________________ > > > [View Less]

1 0

H.323 Question
by rdhanju 07 Mar '01

07 Mar '01

I have been trying to find the actual ASN coding of the fastStart element in the version 2 of the H.225 setup message without any luck. Any help is appreciated.. Thanks. Roby Dhanju Senior Engineer ipNetFusion Voice 972.761.9271 x 214 Fax 972.761.9067 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2063 Document
by Orit Levin 06 Mar '01

06 Mar '01

Hello all! Unfortunately at the last moment I had to cancel my participation in the meeting due to personal reasons. I hope seeing you all next time, though. I am attaching the AVD-2063 "Draft of Annex O" updated version that includes all the material being discussed so far. Please, upload this late contribution to the working sites. If you find time to review it during the meeting, I will be happy to see your comments and thoughts directly or/and in the meeting report. In any case, I would … [View More]

1 0

Re: New comer questions
by Tom-PT Taylor 06 Mar '01

06 Mar '01

You can find it in section D.2 of the Megaco/H.248 specification. > -----Original Message----- > From: Liu, Gary [mailto:gLiu@unispherenetworks.com] > Sent: Monday, March 05, 2001 8:21 AM > To: Taylor, Tom-PT [NORSE:B881:EXCH]; ITU-SG16(a)MAILBAG.INTEL.COM > Subject: RE: New comer questions > > > Is RFC1006 recommended for MEGACO implementation or vendor specific > implementation? > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@… [View More]

1 0

Gatekeeper-assigned address in RCF
by Francois Audet 06 Mar '01

06 Mar '01

Hi guys, I found a minor mistake in H.225.0v4. It says in 7.9.1 that if no terminalAlias is included in the RRQ, a dialedDigits address may be assigned by the gatekeeper in the RCF terminalAlias. There is no reason to restrict it to a dialedDigits string. The text in 7.9.2 for RCF mentions a terminalAlias field, not a dialedDigits. If we wanted to restrict it to a "phone number", it should be a partyNumber. The original text is as follows: terminalAlias - This optional value is a list of … [View More]

2 1

Call for Participation: IPtel 2001 workshop
by Henning Schulzrinne 05 Mar '01

05 Mar '01

Call for Participation 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The IP Telephony Workshop aims at bringing together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, … [View More]deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony will be presented. We received forty papers addressing QoS research (12), service creation and call control (8), firewall/NAT traversal issues (3), conferencing (3), IP interworking with PSTN and wireless (3), QoS testing and measurement (2), instant messaging and presence (2), security (1), administration mechanisms (1), performance analysis (1), etc. Twenty submissions will be accepted, presented and published in the proceedings. Important Dates --------------- Program published March 15th, 2001 Registration deadline March 23rd, 2001 Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research D. Medhi University of Missouri-Kansas City D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. Stüttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Contact Address --------------- Please send all your inquiries regarding iptel2001 to iptel2001(a)egroups.com. Registration ------------ The registration is now open. Participants are asked to register in advance at http://www.fokus.gmd.de/iptel2001/iptel2001/reg/ The registration deadline is March 23rd, 2001. See our registration website for more details. Accommodation ------------- New York city offers many hotels in different price ranges. Our accommodation web page contains pointers to some nearby hotels, however, attendees are responsible for booking their own accommodation. http://www.fokus.gmd.de/events/iptel2001/accommodation/ Exhibition ---------- To demonstrate how research and development become reality there will be an exhibition co-located with the workshop. A limited number of teams from industry as well as from academia and research will be given space to present their software and hardware, both products and prototypes. If you are interested in presenting your products or prototypes at iptel2001, please send an e-mail to iptel2001(a)egroups.com. Please include a short description of what you plan to display and special requirements if you have any. We will provide tables, power strips, Ethernet/802.11b wireless Internet connectivity (no firewall/NAT) and space for your booth if needed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

List of docs
by Pete Cordell 05 Mar '01

05 Mar '01

Couldn't find an up to date list of docs for the meeting, so made up one myself. Seemed churlish to keep it to myself, so I've attached it here. The links should work, but they currently point to the pictel site. If you want to access files from your hard drive, remove the line: <base href... from the HTML file (just use notepad to edit it). (The unzipped links will only work if you have already unzipped the docs!!!) No promises on accuracy!!! Pete. =============================… [View More]

1 0

Re: New comer questions
by Liu, Gary 05 Mar '01

05 Mar '01

Is RFC1006 recommended for MEGACO implementation or vendor specific implementation? -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Sunday, March 04, 2001 3:28 PM To: Liu, Gary; ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: New commer questions We use the RFC 1006 length specifier to indicate total message length in TCP. The "ALF" is actually anything but message delimitation -- not sure how it got that name. The functions performed by the application … [View More]

1 0

Re: New commer questions
by Tom-PT Taylor 04 Mar '01

04 Mar '01

We use the RFC 1006 length specifier to indicate total message length in TCP. The "ALF" is actually anything but message delimitation -- not sure how it got that name. The functions performed by the application are -- reliable delivery (aided by Megaco's transaction orientation) -- sequencing (not much needed in Megaco except in sorting out event reports) -- throttling in the face of network congestion. > -----Original Message----- > From: Liu, Gary [mailto:gLiu@UNISPHERENETWORKS.… [View More]

1 0

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 … [View More]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 [View Less]

3 2

FW: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
by Paul, Manoj 02 Mar '01

02 Mar '01

Hi All, Following text contains further clarification on encoding rules for NULL ASN.1 data types. This might be useful for implementors in general. thanks Manoj Paul. -----Original Message----- From: Bancroft Scott [mailto:baos@oss.com] Sent: Thursday, March 01, 2001 6:46 PM To: Paul, Manoj Cc: Olivier DUBUISSON; John Larmouth; Jean-Paul LEMAIRE Subject: RE: Interoperability Problems due to Open Type encoding of Null t ypes (fwd) On Thu, 1 Mar 2001, Paul, Manoj wrote: > Hi Bancroft, … [View More]> > Thanks for your clarification. I now understand outermost value > as a value nested in an Open Type (TYPE-IDENTIFIER.&Type). I actually > began to get into this loop > when i was encoding an "extension addition" as open type (for ex, an > extension addition in a SEQUENCE). For ex > > example ::= SEQUENCE > { > a BOOLEAN, > ..., > b CHOICE > { > b1 NULL, > b2 NULL > } > } > Now when I encode the value of "b", I would apply the rules of Open > Type encoding. I choose one of the Nulls, say b2. Which of the following > you think is a correct encoding: > > 1) Does b2 qualify as an outermost value and since it does not produce any > encode bits, I need to encode a 0x00 octet for it with the bit-fields of > "b", and > then octet align to generate complete encoding. And add this total length > before this octet aligned bit field. > > 2) b and not b2 is the outermost value, and since b generates a > non-empty bit string, we just add pad bits, add length. So no > additional 0x00 octet for b2. 2 is correct. > The above example is closest to what I am trying to understand. The > problem is that clause "10.1.3" does not state definition of > "outermost value". After your clarification, I do understand it as the > value nested in an Open Type. But besides this definition, is there > any other meaning of Outermost value also (like the last embedded > codepoint in an information element which is after the extension > marker). What do you mean by "codepoint" in this context? > My $0.02 is to make the definition of outermost value > explicit in X.691. Your assistance is greatly appreciated. We will either do this, or revise the text to not use the term "outermost value". Bancroft > warm regards > Manoj Paul. > > -----Original Message----- > From: Bancroft Scott [mailto:baos@oss.com] > Sent: Wednesday, February 28, 2001 4:37 PM > To: Paul, Manoj > Cc: Olivier DUBUISSON; John Larmouth; Jean-Paul LEMAIRE > Subject: RE: Interoperability Problems due to Open Type encoding of Null > t ypes (fwd) > > > On Wed, 28 Feb 2001, Paul, Manoj wrote: > > > Hi Bancroft, > > > > A few weeks back there was a discussion on the SG16 mailing > > list about the meaning of Outermost value. You had given the > > clairification on this term with the following example. > > > > > > > > "outermost" value refers to a value of a type that is either directly > > > > nested in an open type or is a complete application message unto > itself. > > > > For example, if you had: > > > > > > > > Foo ::= SEQUENCE { > > > > b BOOLEAN, > > > > v TYPE-IDENTIFIER.&Type, > > > > ..., > > > > i NULL > > > > } > > > > > > > > bar Foo ::= {b TRUE, v NULL : NULL, i NULL} > > > > > > > > The value of Foo, bar, is an outermost value. The value of v (NULL : > > NULL) > > > > is encoded as an outermost value, so in this case since NULL encodes > to > > 0 > > > > bits it is replaced with eight 0-bits, and this is prefixed with a > > length > > > > of 1. Similarly, the value of i is encoded as an outermost value, so > > the > > > > resulting encoding in this case will have a length of 1 followed by > > eight > > > > 0-bits. > > > > I have a doubt about this and would highly appreciate if you could > > help me with that. In the example above, I assume that bar is being > > encoded as an Open type value. > > No, not at all as an Open type value. It is being encoded as an outermost > value, which means that after encoding it is padded to be an integral > number of 8 bits long. > > > You mentioned that each type which is directly nested in the Open type > > should be considered as an Outermost value. > > Correct. > > > By that logic, b,v and i should be encoded as per the outermost value > > rules. Is that true? > > > No. b is not directly nested in an open type value. The *contents* > of v is encoded as an outermost value because it is to be nested in > the Open type, v. i is encoded as an outermost value because the rules > for encoding extension additions mandates it. > > > Does that mean that "b" which resuls in a non-empty bit string need to > > be octet aliged? > > No. Indeed, "b" would never be octet aligned because of the extensibility > marker that will always occur immediately in front of it (and because it > is not encoded as an outermost type). > > > In the encoding above, you also mentioned that v should result in > > 0x01, 0x00 octets. But why should we encode the length for v, since it > > is not encoded as an open type itself. > > The *contents* of v is encoded as an outermost type, meaning that it is > padded to an octet boundary. v itself is encoded as an Open type, meaning > that a length is always prefixed to its value (i.e., always prefixed to > its *contents* by virtue of encoding v). > > > Shouldn't it just be 0x00? > > No, not at all. > > Consider the case where you have the following and maybe you will see > the rationale why it was designed this way. Suppose we have: > > ObjSet TYPE-IDENTIFIER ::= {...} > > Bar ::= SEQUENCE { > b TYPE-IDENTIFIER.&id ({ObjSet}), > v TYPE-IDENTIFIER.&Type ({ObjSet}{@b}} > } > > > Zoo ::= SEQUENCE { > j Bar, > k INTEGER > } > > If an implementation did not know all the information objects in ObjSet > (a common occurrence in many types of applications) then it would be > impossible for such a receiving implementation to know how many bytes > to skip over to get to k if v were not encoded with a length prefix. > > > I will really appreciate your help on this since no where this > > clarification is available. > > In my previous email I spelled out the pertinent clauses where the > proper encoding is defined. Which did you find unclear. Your feedback > would be much appreciated so that we can improve the documentation. > > ------------------------------------------------------------------------- > Bancroft Scott Toll Free :1-888-OSS-ASN1 > OSS Nokalva International:1-732-302-0750 > baos(a)oss.com Tech Support :1-732-302-9669 > x-1 > 1-732-302-9669 x-200 Fax :1-732-302-0023 > http://www.oss.com > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

New commer questions
by Liu, Gary 02 Mar '01

02 Mar '01

Hi, I am a new commer to the MEGACO mailing list and have some dump questions. The text enconding is new to me. If TCP is used as transport, how is a transaction message framed out from the data stream. Is "MEGACO/1" the frame mark? The standard requies MGC/MC to support UDP/ALF. UDP is already message based. Why is ALF (application level framing) needed? I though the other way around. Framing is needed for TCP. Thanks. Gary Liu Unisphere Networks, Inc. <http://www.unispherenetworks.com… [View More]

1 0