- sg16-avd - lists.packetizer.com

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 to be some difference between the ITU H.248 document and the RFC3015. In the ITU document, it is mentionned that a service change command specifying "root" is a registration command and that it should be "forced". The ITU document also mention that "restart" indicates that the service will be restored on the specified termination after expiration of the ServiceChangeDelay timer. The termination are assumed to not be associated with any contexts. That last sentence makes me wonder if we can really use "restart" on "root" with the "warm boot" reason to perform protocol version upgrade. Another unrelated question, which document should we reference to when the information in the ITU document and the RFC3015 document differ? comments, 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

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 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 > > ___________________________________________________ > > > > > > >

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: 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 > ___________________________________________________ > > >

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 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 > ___________________________________________________ > > >

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 like to renew the discussion during the next meeting starting from this version. Best Regards, Orit Levin Chief Architect RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430

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@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 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.COM > <mailto:gLiu@UNISPHERENETWORKS.COM> ] > > Sent: Friday, March 02, 2001 11:16 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: New commer questions > > > > > > 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 <http://www.unispherenetworks.com> > > 7800 Congress Ave., Suit 100 > Boca Raton, FL 33487 > T:(561)981-7022, F:(561)981-7001 > > mailto:gliu@unispherenetworks.com <mailto:gliu@unispherenetworks.com> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

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 alias addresses, by which other terminals may identify this terminal. This field may be used in addition to or as an alternative to the terminalAliasPattern and supportedPrefixes fields. If the terminalAlias is null, a dialedDigits address may be assigned by the gatekeeper, and included in the RCF. If an email-ID is available for the endpoint, it should be registered. Note that multiple alias addresses may refer to the same transport addresses. All of the endpoint's aliases that it desires to register shall be included in this list unless the additiveRegistration option is specified, in which case the endpoint aliases in an RRQ shall be added to the list of aliases currently registered for the endpoint. It should be changed to: terminalAlias - This optional value is a list of alias addresses, by which other terminals may identify this terminal. This field may be used in addition to or as an alternative to the terminalAliasPattern and supportedPrefixes fields. If the terminalAlias is null, a terminalAlias address may be assigned by the gatekeeper, and included in the RCF. If an email-ID is available for the endpoint, it should be registered. Note that multiple alias addresses may refer to the same transport addresses. All of the endpoint's aliases that it desires to register shall be included in this list unless the additiveRegistration option is specified, in which case the endpoint aliases in an RRQ shall be added to the list of aliases currently registered for the endpoint. Comments? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

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, 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

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. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 =============================================

1 0