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

Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel??
by Frank Derks 20 Mar '01

20 Mar '01

6.2.8/H.323 states: "The endpoint shall establish exactly one H.245 Control Channel for each call that the endpoint is participating in." 8.1.7/H.323 never states that when Fast Connect is being used such a control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245 procedures. It would seem that section 6.2.8 should be rephrased to make clear that the H.245 control channel shall only be established when "normal" H.245 procedures are being followed and not in the fast connect case. Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Rapporteurs/Editors Manual - 1 Feb 2001 version
by OKUBO Sakae 20 Mar '01

20 Mar '01

Dear Fellow Rapporteurs, Editors and all, I have received from ITU-TSB the subject manual and placed it at the ftp site: http://standard.pictel.com/ftp/avc-site/manual21-02-01.zip Please carefully read it. I can say from the past experiences that the manual will help us when we face difficulty. Best regards, OKUBO Sakae *************************************************** Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: sokubo(a)mn.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 **************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: A problem involving sending fast-start element in a facility message.
by Paul, Manoj 19 Mar '01

19 Mar '01

Praneeth, Refer to section 8.2.2 of H.323 Version 4. The last paragraph states that the reason should be set to "forwardedElements" as you indicated in your mail. -Manoj -----Original Message----- From: pmreddy(a)HSS.HNS.COM [mailto:pmreddy@HSS.HNS.COM] Sent: Wednesday, March 14, 2001 9:42 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: A problem involving sending fast-start element in a facility message. Hi, I'm stuck with a particular problem, in the implementation of fast-start in the h323v2 implementation. The following are the details. If anybody is certain about the solution please do respond. Consider the scenario in which both calling end-point(A) and called end-point(B) support and prefer fast-start. Calls are gk-routed. A sends Setup message containing a fast-start element, to the Gatekeeper, which fowards it to B. Gatekeeper sends Call-Proceeding to A. B responds to the Setup sent by A, with a Call-Proceeding containing a fast-start element. Now, the Gatekeeper maps the fast-start element to a faststart element in the facility message. NOW, WHAT REASON SHOULD THE FACILITY MESSAGE HAVE?? I feel it should be "forwarded elements". But I am not very sure. If anybody knows about this, please respond immediately. Thanks Praneeth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Roni Even 19 Mar '01

19 Mar '01

Glen, Were do I have to plea, Roni Even Acccord Networks -----Original Message----- From: Glen Freundlich [mailto:ggf@AVAYA.COM] Sent: Thursday, March 15, 2001 8:54 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] I've made my plea to retain the G.723.1 payload format and codepoint, and would suggest that other vendors do the same. We may have some data collected from the IMTC H.323 interop test events that would reflect the number of vendors that have successfully interoperated using G.723.1 (and probably H.263, possibly the GSM coders), and might be able to provide those numbers. But, it's better for vendors to identify themselves. Glen Tom-PT Taylor wrote: It's simply a matter of implementors reporting. The key point is that the Working Group Chair has to know exactly which features of the RFC were tested and which not. In the case of the G723 payload type, there are no options to worry about: it's simply a matter of different implementations agreeing on RTP payload type 4 and subsequently transmitting RTP-encapsulated packets in accordance with G.723.1, using one frame (30 ms) per packet or such other value as specified by the A:ptime attribute. -----Original Message----- From: Rex Coldren [ mailto:coldrenr@AGCS.COM <mailto:coldrenr@AGCS.COM> ] Sent: Wednesday, March 14, 2001 2:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] Francois, I believe you are correct. However, I am not familiar with how the IETF determines "interoperable implementations". Is is simply a matter of vendors reporting with whom they interoperate or is there some IETF-sponsored interop event that needs to be attended? Rex Francois Audet wrote: Guys,This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723?Won't it be a major interoperability problem if this payload type is removed from the A/V specification?????> -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > 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. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

2 1

Report of the Launceston meeting AVD-2100
by OKUBO Sakae 19 Mar '01

19 Mar '01

Dear SG16 experts, The subject document has been uploaded to the /Incoming directory of the ftp site. It is an integration of Question reports and other administrative materials with editorial refinements. http://standard.pictel.com/ftp/avc-site/Incoming/AVD-2100.zip Please review it and return your advice if anything is wrong by the end of this week. Then it will be placed at /0103_Lau directory with status of "confirmed be the participants." Best regards, OKUBO Sakae *************************************************** Global Information and Telecommunication Institute Waseda University Waseda University Bldg. 29-7 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 **************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

I know it's been a while, but... 16921
by Kristie_S＠TEAMZEZZ.COM 19 Mar '01

19 Mar '01

1 0

Call for Participation: Internet Telephony Workshop 2001 April 2/3
by Henning Schulzrinne 18 Mar '01

18 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, on topics ranging from quality of service, voice measurements, deployment experiences, accounting, security, service and feature interaction. The keynote address will be given by Prof. Dave Farber from the University of Pennsylvania. Important Dates --------------- 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 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

IEEE/ACM Workshop on Mobile Software Agents- MATA 2001- Deadline-April 1.
by Ahmed Karmouch 18 Mar '01

18 Mar '01

[My apologies if you receive this more than once] ====================================================== MATA'2001 Third International Workshop on Mobile Agents for Telecommunication Applications August 14-16, 2001, Montréal, CANADA Co-sponsored by IEEE and ACM http://www.congresbcu.com/mata01/ CALL FOR PAPERS ================ Technical papers (4500 words maximum) describing previously unpublished, completed research or work in progress, not currently under review by another journal or conference, are solicited on the following topics: Mobile Agent Architecture and Models Agent Identification, Tracking and Persistence Agent-based Mobility Management in Mobile Networks Web Agent Systems Agent Integration with CORBA and TINA Active Networks and Mobile Agents Feature Interaction and Agents Mobile Agents Communication Language Security in Mobile Agent Systems Interactive Multimedia Presentation Agents Agent-based Electronic Commerce Agent-based Access to Legacy Services Managing QoS with agents Information Discovery and Gathering using agents Data Mining Agents Network Management Agents Policy-based Management using Mobile Agents Education and Applications of Mobile Agents Prototypes and Experience with Mobile Agents Seamless Messaging and Mobile Agents Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in IEEE Network Magazine. All paper submissions should have a cover page containing the title, names, email address and complete postal addresses (including telephone and fax numbers) for all authors. Please indicate the main author for the purpose of correspondence. The cover page should also provide an abstract (150 words maximum), and a list of keywords. Please include a statement stating that "when accepted, one of the authors will attend the Workshop to present the paper". Submissions should be sent by email to the program chair: Roch Glitho Ericcson Research Canada 8400, boul. Décarie Ville Mont-Royal, Québec, Canada, H4P 2N2 email: roch.glitho(a)lmc.ericsson.se Tel.: (514) 345-7000 ext. 2266 IMPORTANT DATES FOR PAPER SUBMISSION Full paper submission due April 1, 2001 Notification of acceptance May 15, 2001 Final paper due June 15, 2001 ======================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 UUIE PDU
by Nehru, Archana 16 Mar '01

16 Mar '01

hi all, I have a question about the encoding of the UUIE PDU that is sent by an endpoint to its GateKeeper through an IRR message. Suppose we have the following scenario: EP1 (v3)-----------------------------GK(v3/v2)---------------------------------- ----EP2(v2) Here Ep1 is a version 3 client, Gk could either be v3 or V2. Ep2 is version 2. Now if EP1 sends out a UUIE PDU to the GK for all incoming messages from EP2, is it supposed to encode them as version 3 messages or version 2 messages? . The issue here is that the messages from EP2 will not contain V3 fields, so EP1 can forward the message coming from EP2 to the GK in one of the following ways: 1) EP1 forwards the EXACT copy of message coming from EP2. This obviously means that EP1 will forward a "version 2" message as a UUIE to the GK. Note that this means the GK gets an incoming version 2 message inspite of knowing that EP1 is a version 3 endpoint. 2) EP1 does not send an EXACT COPY of messages coming from EP2 as part of UUIEs. This means that EP1 decodes the v2 message from EP2, re-encodes it as a version 3 message and then sends this out to the GK. So the "information content" of the message sent to the Gk is the same as in the incoming PDU from EP2, but the message sent is version3. E.g: let us say EP2 sent a SETUP message to EP1, so its ASN part does not contain version 3 fields like "maintain connection" or "multipleCalls". So EP1 can do the following as indicated above: For choice 1(mentioned above): --------------------------------- It will forward the same SETP UUIE to Gk For Choice 2 (mentioned above): ------------------------------------- It will encode the incoming version 2 message as a version 3 message , i.e it will encode "maintain connection" and "multiple calls" BUT set their values to FALSE. This means that the information delivered to the Gk is the same( maintain connection or multiple calls not supported). The point to clarify here is whether : 1) it is acceptable that a GK sees a version 3 endpoint (EP1) sending out a version 2 message? 2) it is acceptable to GK that the EP1 has actually converted a version 2 message in to a version 3 message (choice no 2)? Pros and Cons of choice 1 and Choice 2: ----------------------------------------------------------- With choice 1, EP1 has to have logic for generating all backward compatible messages (e.g: if EP1 is a V4 endpoint, it should be capable of "encoding a v1, v2 and v3 message also. As the versions increase, this may become cumbersome to implement. With choice 2, EP1 can have the logic of encoding messages only for version 3. But the disadvantage here is that EP1 has to fill in values corresponding to all the fields added for version 3 in order to convert a version2 into a version 3 message. Also it is possible to fill corresponding values for fields that are "BOOLEANs" , but it may not be possible to fill "dummy values" for all "non-BOOLEAN" fields. E.g:what if the new fields added in version 3 is an integer? what dummy values will the GW fill in the version 3 message ? So the question here is , which one of the above choices is correct? My guess is choice 1) works better. Is that right? Any answers are greatly appreciated. -Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Tom-PT Taylor 15 Mar '01

15 Mar '01

It's simply a matter of implementors reporting. The key point is that the Working Group Chair has to know exactly which features of the RFC were tested and which not. In the case of the G723 payload type, there are no options to worry about: it's simply a matter of different implementations agreeing on RTP payload type 4 and subsequently transmitting RTP-encapsulated packets in accordance with G.723.1, using one frame (30 ms) per packet or such other value as specified by the A:ptime attribute. -----Original Message----- From: Rex Coldren [mailto:coldrenr@AGCS.COM] Sent: Wednesday, March 14, 2001 2:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] Francois, I believe you are correct. However, I am not familiar with how the IETF determines "interoperable implementations". Is is simply a matter of vendors reporting with whom they interoperate or is there some IETF-sponsored interop event that needs to be attended? Rex Francois Audet wrote: Guys,This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723?Won't it be a major interoperability problem if this payload type is removed from the A/V specification?????> -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > 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. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

2 1