October 2000 - sg16-avd - lists.packetizer.com

Re: [H225 Annex G] When to create a new service ID
by Michael Fortinsky 22 Oct '00

22 Oct '00

Paul, Maybe I don't understand your point - I am not sure what you mean when you say "a new ServiceRequest". (I think this is the heart of the matter - what determines what is a NEW ServiceRequest?) New service ID's are allocated and returned in the ServiceConfirmation message, not in the ServiceRequest message. Therefore, it is up to the border element that receives the ServiceRequest message to decide whether to allocate a new service ID or not. The question still remains - how are "keepAlive" ServiceRequests to be treated? Another way of looking at the issue is as follows (maybe this is clearer): If a BE sends a ServiceRequest message that does NOT contain a serviceID field, a new service ID is returned in the ServiceConfirmation message and a new service relationship is defined. If a BE sends a ServiceRequest message that DOES contains a serviceID field, the BE that received the ServiceRequest must determine whether to return the same serviceID or a new one (ie, is there going to be a new service relationship or not) - if the service parameters in the ServiceRequest are the same as those in the existing service relationship, this ServiceRequest message is a refresh of the existing service relationship and the ServiceConfirmation is returned with the same service ID as was in the ServiceRequest - if the service parameters are different, then: - if the BE want to accept the new parameters, it sends a ServiceConfirmation that contains a NEW serviceID - this also indicates that the previous service relationship has ended - if the BE does not want to accept the new parameters, it sends a ServiceRejection (that contains the serviceID from the ServiceRequest message) indicating that the new terms are rejected - the old service relationship is still in effect according to the old service parameters (as per section 1.8.2.7/H.225 Annex G) Comments? Mike "Paul E. Jones" <paulej(a)packetizer.com> 10/22/00 04:02 AM To: <Michael_Fortinsky(a)VOCALTEC.COM>, <ITU-SG16(a)mailbag.cps.intel.com>, <h323implementors(a)imtc.org>, <h323implementors(a)pulver.com> cc: Subject: Re: [H225 Annex G] When to create a new service ID Michael, My opinion is that, given that there is a ServiceRequest and a ServiceRelease and that one can initiate a new service relationship before terminating a previous service relationship, a new service ID shall be introduced with a ServiceRequest message and a BE should not send a new ServiceRequest with the same ID without first releasing the previous relationship. I believe that's in alignment with your interpretation. Paul ----- Original Message ----- From: Michael_Fortinsky(a)VOCALTEC.COM To: ITU-SG16(a)mailbag.cps.intel.com ; h323implementors(a)imtc.org ; h323implementors(a)pulver.com Sent: Wednesday, October 18, 2000 5:40 AM Subject: [H225 Annex G] When to create a new service ID I would like to hear people's interpretation of when a new service ID should be created in H.225.0 Annex G. (A service ID is used to identify a service relationship between two border elements). There are three cases to consider: Case #1: - a BE (border element) receives a ServiceRequest message from a BE with which it does not yet have a service relationship Case #2: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship, but the terms of the service relationship are to be changed (eg, different security parameters) Case #3: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship (ie, this ServiceRequest is refreshing the service relationship), and the terms of the service relationship are identical to the previous terms (eg, same security parameters) My impression is that the following should happen in each case: Case #1 - create a new serviceID in the ServiceConfirmation Case #2 - create a new serviceID because we are changing the parameters of the service relationship (it's becoming a new service relationship) Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, so we should continue to use the same serviceID However, the wording of H.225.0 Annex G does not seem to say this. It seems that in ALL cases, a new serviceID should be created. To me, this seems to be incorrect, and I'm not sure that the original intent took into account case #3. I think that in case #3, we should not be creating a new service ID. The following sections from H.225.0 Annex G are relevant: [from section 1.8.2] service ID - This identifer identifies a particular service relationship session between two border elements. Whenever a border element receives a ServiceRequest message, it allocates a globally unique service ID and returns it to the sender of the ServiceRequest message in the ServiceConfirm message. [from section 1.8.2.5] A border element may send a ServiceRequest message to a border element with which it has an existing relationship, with the intent that the terms of the original relationship be terminated and replaced with the new terms. Service relationships may have limited time to live. A border element may refresh the relationship by sending a new Service Request. [from section 1.8.2.6] Every new service relationship is identified by a service identifier. Whenever a border element receives a new ServiceRequest message, it allocates a unique service ID and returns it to the sender of the service request message in the "service confirm" message. If the border element already has a service relationship with the border element that sent the ServiceRequest message, sending ServiceConfirmation indicates that the terms of the original relationship are terminated and replaced with the new terms. Any comments? If people agree that the wording needs to be changed to unambiguously handle case #3, now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

2 1

Re: Rapporteur meeting on 9-10 November in Geneva
by Sakae OKUBO 22 Oct '00

22 Oct '00

Dear Mr. Jones, In response to your requests, the following APC numbers have been allocated to your five contributions: APC-1969 Editor (P Jones) Editorial and Technical Corrections to H.323v4 APC-1970 Cisco Systems Signalling of ingress and egress Carrier/Circuit Identifier information in H.225.0 Messages and Annex G Messages APC-1971 Cisco Systems Third Party Re-routing of a Fast Connect Initiated Call APC-1972 Cisco Systems Ported Number Indications in H.225.0 messages APC-1973 Cisco Systems Reserving Resources for Calls Best regards, Sakae OKUBO *********************************************************** 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) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Error in H.323v3 ASN.1
by Paul E. Jones 22 Oct '00

22 Oct '00

XuPeili and other H.323 Developers, This does appear to be in error. Unfortunately, this was published this way in the H.225.0v3 Recommendation. However, you are correct that a previous H.323v2 Implementers Guide was published which contained the aliasesInconsistent field. So, we have an issue to contend with. I must ask the developer community-- I do not want to make this change without wide support for making such a change. Since the Version 2 field was added via the Implementers Guide, it is entirely possible that H.323v2 vendors did not even include it in their ASN.1 So, I need to hear from all of the developers on this issue. This may have been addressed, but I don't have notes on this matter. A similar issue with the LocationRejectReason was found and I corrected that back in June when discussing with everybody that "I would never change the ASN.1 and more". Well, unfortunately, it appears that we have one last error-- honestly, I'm quite shocked this one slipped through. So... should the "aliasesInconsistent" field be moved above the "routeCallToSCN" element in the AdmissionRejectReason sequence as shown in an earlier H.323v2 Implementers Guide? Please post and debate this publicly. We need to resolve this matter quickly so as to minimize impact on everybody. Best Regards, Paul ----- Original Message ----- From: "XuPeili" <xupeili(a)huawei.com> To: "Paul E. Jones" <paulej(a)packetizer.com> Cc: <h323implementors(a)imtc.org> Sent: Tuesday, October 03, 2000 9:42 PM Subject: ;X84: Multiple Call Proceedings in a H.323 call > hi Paul, > > In the H225.0v3.asn downloaded form www.packetizer.com > the ARJ is specified like this > > AdmissionRejectReason ::= CHOICE > { > calledPartyNotRegistered NULL, -- cannot translate address > invalidPermission NULL, -- permission has expired > requestDenied NULL, -- no bandwidth available > undefinedReason NULL, > callerNotRegistered NULL, > routeCallToGatekeeper NULL, > invalidEndpointIdentifier NULL, > resourceUnavailable NULL, > ..., > securityDenial NULL, > qosControlNotSupported NULL, > incompleteAddress NULL, > routeCallToSCN SEQUENCE OF PartyNumber, > aliasesInconsistent NULL -- multiple aliases in request identify distinct > people > } > > Since the routeCallToSCN is a new choice in H.225.0v3, I think it should be > placed > after the aliasesInconsistent choice which is already exist in v2. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

7 17

[H225 Annex G] When to create a new service ID
by Michael Fortinsky 22 Oct '00

22 Oct '00

I would like to hear people's interpretation of when a new service ID should be created in H.225.0 Annex G. (A service ID is used to identify a service relationship between two border elements). There are three cases to consider: Case #1: - a BE (border element) receives a ServiceRequest message from a BE with which it does not yet have a service relationship Case #2: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship, but the terms of the service relationship are to be changed (eg, different security parameters) Case #3: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship (ie, this ServiceRequest is refreshing the service relationship), and the terms of the service relationship are identical to the previous terms (eg, same security parameters) My impression is that the following should happen in each case: Case #1 - create a new serviceID in the ServiceConfirmation Case #2 - create a new serviceID because we are changing the parameters of the service relationship (it's becoming a new service relationship) Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, so we should continue to use the same serviceID However, the wording of H.225.0 Annex G does not seem to say this. It seems that in ALL cases, a new serviceID should be created. To me, this seems to be incorrect, and I'm not sure that the original intent took into account case #3. I think that in case #3, we should not be creating a new service ID. The following sections from H.225.0 Annex G are relevant: [from section 1.8.2] service ID - This identifer identifies a particular service relationship session between two border elements. Whenever a border element receives a ServiceRequest message, it allocates a globally unique service ID and returns it to the sender of the ServiceRequest message in the ServiceConfirm message. [from section 1.8.2.5] A border element may send a ServiceRequest message to a border element with which it has an existing relationship, with the intent that the terms of the original relationship be terminated and replaced with the new terms. Service relationships may have limited time to live. A border element may refresh the relationship by sending a new Service Request. [from section 1.8.2.6] Every new service relationship is identified by a service identifier. Whenever a border element receives a new ServiceRequest message, it allocates a unique service ID and returns it to the sender of the service request message in the "service confirm" message. If the border element already has a service relationship with the border element that sent the ServiceRequest message, sending ServiceConfirmation indicates that the terms of the original relationship are terminated and replaced with the new terms. Any comments? If people agree that the wording needs to be changed to unambiguously handle case #3, now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

2 1

Re: Request for APC numbers
by Sakae OKUBO 21 Oct '00

21 Oct '00

Dear Mr. Euchner, Dear Mr. Anderson, In response to your requests, the following APC numbers have been allocated to your contributions: At 09:09 +0200 00/10/20, Euchner Martin wrote: >The following block of contributions relate to corrections of the H.235 >Version 2 white text for decision: APC-1961 >Source Title >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding Section B.4.3 APC-1962 >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding the use of the password and shared secret APC-1963 >Editor Clarification on the use of sendersID and generalID in >white Draft H.235 Version 2 APC-1964 >Editor REVISED ITU-T RECOMMENDATION H.235 VERSION 2 - SECURITY AND >ENCRYPTION FOR H-SERIES (H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS >- CORRECTED VERSION FOR DECISION >The following block of contributions relate to the new H.235 Version 3: APC-1965 >Source Title >Editor Draft H.235 Version 3 - Security and encryption for >H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 >Editor Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 >Editor Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 >Mobile Environments" At 14:53 -0400 00/10/20, Terry L Anderson wrote: >Please assign me an APC number for APC-1968 >Title: Draft H323 Annex R. >Source: Editor Best regards, Sakae OKUBO *********************************************************** 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) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: QOS signaling in RAS
by Roy, Radhika R, ALCOO 20 Oct '00

20 Oct '00

Hi, Ilyya and Mike: Please see H.323 Appendix II - Transport Level Resource Reservation Procedure. The "transportQOS" field simply provides a mechanism who "controls" the transport level resource reservation: Endpoint or GK. Accordingly, the resource reservation is made by that particular entity. Then each entity can use couple of things related to the resource reservation: 1. BRQ/BCF/BRJ and 2. RSVP (plus ATM QOS for the ATM network as well). Now, items 1 and 2 are independent. Item 1 is in RAS (pre-call setup phase) and item 2 is in H.245 (call setup phase). Here is my own interpretation: Item 1 has the abstraction of bandwidth (generic) that can be used on end-to-end basis. That is, this abstraction is independent of the lower transport network. In other words, the total bandwidth that is required for the H.323 application (audio, video, and data) is expressed in the bandwidth field. However, item 2 is network specific. If there is a single network (either IP or ATM), it may work. If there are two networks (IP + ATM) between the two H.323 endpoints, we have problems to use either RSVP or ATM QOS on end-to-end basis. In addition, H.323 also provides the abstraction of "circuits: DS0s, etc. (indirectly bandwidth)" in the context of the PSTN-Packet network in Q.931 call setup phase. H.323 Annex N is addressing this problem to provide end-to-end QOS not only for the bandwidth parameter, but for all other parameters including delay, jitter, bit-error-rate/packet losses for both: 1. Pre-call setup phase (RAS) and 2. Call setup phase (Q.931/H.245). AT&T is bringing a contribution related to QOS in the upcoming SG16 November'00 meeting. Best regards, Radhika R. Roy AT&T +1 732 420 1580 -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, October 20, 2000 6:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: QOS singaling in RAS Ilya, We are presently reviewing QoS support in H.323 and a new Annex N to H.323 is in preparation. The current H.323 assumes homogeneity of network transport and QoS mechanisms so the only issues to be considered in H.323 are what type if QoS mechanism is supported in the end point. The new work recognises that transport may involve a variety of transport mechanisms e.g. ATM, IP FR, as well as QoS mechanism, e.g. RSVP, DiffServ, MPLS, some of which may be hidden from the end user. Maybe other experts could comment on your specific query. Regards, Mike Buckley Editor Annex N +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Ilya Freytsis" <ifreytsis(a)CETACEANNETWORKS.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, October 19, 2000 7:46 PM Subject: QOS singaling in RAS > Dear experts, > One of the choices of the RegistrationRejectReason (h225 v3) is > "transportQOSNotSupported NULL, -- endpoint QOS not supported". How it should be interpreted since it seems there is nothing > related to transport QOS in registration request PDU itself? > > Ilya Freytsis > Cetacean Networks > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

QOS singaling in RAS
by Ilya Freytsis 20 Oct '00

20 Oct '00

Dear experts, One of the choices of the RegistrationRejectReason (h225 v3) is "transportQOSNotSupported NULL, -- endpoint QOS not supported". How it should be interpreted since it seems there is nothing related to transport QOS in registration request PDU itself? Ilya Freytsis Cetacean Networks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: test conditions provided
by Baese Gero 20 Oct '00

20 Oct '00

Dear experts, Mr. Li, we want to proceed with a technical and objective discussion. Everybody is solicited to suggest further improvements for the provided test conditions to become as realistic as possible. Any constructive criticism is welcome as well. Concerning your point Mr. Li, if you read the test conditions carefully you will see it is one item out of a list where you have the choice to take what you think is suitable. You will find the H.263 Wireless Profile also. Furthermore we want to discuss the main points of the test conditions (bearer service, ...). What is your opinion about the UMTS scenario ? We are still convinced, the provided test conditions are fair and reasonable. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: Adam Li [mailto:adamli@icsl.ucla.edu] > Gesendet am: Montag, 16. Oktober 2000 07:00 > An: Mailing list for parties associated with ITU-T Study Group 16 > Cc: Baese Gero; Yung Lyul Lee; Jeong-Hoon Park; John D. Villasenor > Betreff: RE: test conditions provided > > Dear experts and Mr. Gero, > > It seems that the conditions described in the document can hardly be > called "reasonable and fair conditions". > > For example, for Media codecs, it specifies H.263 with Annex O. As we > all know, Annex O (with spatial, temporal and SNR scalability) is NOT > in the Wireless Profiles of H.263. Indeed, it is not in ANY of the > profiles defined in H.263. > > The whole Annex O is such a very complex algorithm, that it is NOT > even in the most complex profiles where complexity is not that much a > concern. It is really unimaginable that any mobile applications will > use Annex O. > > If the Siemens proposal needed such a un-realistic scenario to provide > any possible gain, the wireless connection oriented Annex I seems is > not the right place for it. > > Since Mr. Gero have just proposed the condition now, he may have > enough resource to test it before the document submission date. Maybe > you can test it also without Annex O, Mr. Gero? > > Sincerely, > > Adam Li > > ---------- > Adam H. Li, Ph.D. > Image Communication Lab (310) 825-5178 (Lab) > University of California, Los Angeles (310) 825-7928 (Fax) > > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Baese Gero > > Sent: Friday, October 13, 2000 7:38 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: test conditions provided > > > > > > Dear experts, > > > > the long lasting diskussion about the superiority of one > > of the proposals concerning error resilient transmission > > of progressive multimedia streams(H.323 Annex I) needs > > to be decided on an objective basis soon. > > > > Therefor we are providing reasonable and fair test conditions. > > > > The test conditions are focused on a common UMTS scenario with > > video input and PSNR as an objective quality measurement. > > Furthermore > > every step in between is well defined and a graphic visualization of > > the outcome is the ideal and easy basis, with not much room for > > interpretation, for the decision process. > > > > > > Comments, questions and supplements are welcome. > > > > Best wishes > > Gero Baese > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: APC Number Request
by Sakae OKUBO 20 Oct '00

20 Oct '00

Dear Mr. Ratta, >Please assign an APC number to the following document directed >to the Q14/16 rapporteur's meeting in November: > >Source: Lucent Technologies >Title: Proposal to create an SDL representation of H.248 APC-1960 has been allocated to your contribution. Best regards, Sakae OKUBO *********************************************************** 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) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

IEEE PACRIM 2001 CALL FOR PAPERS
by agullive＠ENGR.UVIC.CA 19 Oct '00

19 Oct '00

**************** CALL FOR PAPERS *************** 2001 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM'01) August 26-28, 2001, Victoria, B.C., Canada Sponsored by IEEE Canada (Region 7) & IEEE Victoria Section Co-sponsored by the University of Victoria Established in 1987, Pacific Rim Conference is the premier IEEE biennial event in the Pacific Northwest. It is our pleasure to invite you to participate in this event. The scope of PACRIM'01 encompasses but is not limited to: Mobile and Personal Communications Computer Architecture Coding, Modulation and Spread Spectrum Parallel and Distributed Computing ATM Networks Internet Applications Multimedia Communications Neural Networks and Genetic Algorithms Optoelectronic Systems and Devices Hardware/Software Codesign Broadband Satellite Communications Database and Knowledge-Based Systems DSP Applications in Telecommunication Adaptive Filters and Algorithms Image and Video Processing Wavelets and Filter Banks Digital Filters VLSI Speech and Audio Processing Nonlinear Signals and Systems DEADLINES 1000 word summary: March 1, 2001 Acceptance/Rejection: April 1, 2001 Camera Ready Copy: May 1, 2001 Please submit your summary General enquires on PACRIM'01 (by March 1, 2001) to the can be addressed to either of the Technical Program Chair: General Co-Chairs: Dr. Panajotis Agathoklis Dr. Aaron Gulliver or Dr. Kin Li Dept. of Electrical & Computer Eng. Dept. of Electrical & Computer Eng. University of Victoria University of Victoria P.O. Box 3055, STN CSC P.O. Box 3055, STN CSC Victoria, BC, Canada V8W 3P6 Victoria, BC, Canada V8W 3P6 Fax: +1-250-721-6052 Fax: +1-250-721-6052 Email: pan(a)ece.uvic.ca Email: agullive(a)ece.uvic.ca or kinli(a)ece.uvic.ca Accepted papers will be published by the IEEE in the Conference Proceedings. They will be available for worldwide post conference sales from the IEEE. Further information on the conference may be found on the Website: http://www.citr.ece.uvic.ca/pacrim01/ ------------------------------------------------------------------------ We apologize if you have received this notice more than once. ------------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0