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

Submission of AVD-2036 for the upcoming SG16 meeting.
by Paul, Manoj 12 Feb '01

12 Feb '01

Hi Paul, Please include the attached AVD-2036 document for consideration to the upcoming SG16 meeting at Launceston. The title of the document is "Usage of H.248 Syntax in H.225 Version 4". Thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

comparison document H.323 Annex I
by Baese Gero 12 Feb '01

12 Feb '01

Dear Mr. Li, experts, as requested by the chairman we started working on the joint document containing the fair comparison of both proposals concerning H.323 Annex I. We provide the first draft based on the outcome of the Geneva meeting. This document should be completed up to the meeting in Australia and will contain the results of the objective tests as well. Everybody is solicited to contribute to the completion. Thank you and best wishes Gero Baese ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- <<APC-XXXX_comparison.doc>>

1 0

TEST - IGNORE
by Jozef Vandenameele 12 Feb '01

12 Feb '01

test test test test test test test test test test test test test test test test test test test test

1 0

communicationModeCommand
by csg 11 Feb '01

11 Feb '01

Dear H.323 Experts I want to develop MC that control conferences by the type of multi-unicast conference. The terminal would multi-unicast audio/video stream to each terminal participating in the conference. But, I am not clear how to describe communicationModeCommand, especially mediaChannel, and mediaControlChannel. Because mediaChannel & mediaControlChannel will be determined by each terminal, MC cannot specify the TransportAddress of them. Experts! please, light my way.

1 0

Best New Trade Show Display by Opera Portables, Inc. adv
by opera＠localhost.net 09 Feb '01

09 Feb '01

1 0

Checkup
by Meyer, Greg W 09 Feb '01

09 Feb '01

The ITU-SG16 mail list has been suspiciously quiet since the loop condition earlier this week. If you experience any problems with the list, please let me know directly. Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Test - please ignore <eom>
by Patrick_Luthi＠PICTEL.COM 08 Feb '01

08 Feb '01

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ITU Approves Editorial Corrections to H.323v4/H.225.0v4
by Paul E. Jones 07 Feb '01

07 Feb '01

Greetings! As many of you may be aware, a number of editorial errors in H.323v4 and H.225.0v4 were pointed out to me very soon after the approval of those documents in November. While the number of errors is not tremendous, the very fact that the errors were reported by so many people so quickly is a testament to the fact that there are many people actively working on developing H.323-based products around the world. I have been working with the ITU to get those corrections made to the documents prior to publication so as to reduce confusion and interoperability issues. I have also been posting those corrections to the ITU SG-16 mailing list and to the Packetizer web site. I received good news this week: the ITU has agreed to accept those corrections for the final published texts. I have already updated the H.323 version 4 text and hope to have H.225.0v4 updated soon. You can download the new text from the Packetizer site (linking to the PictureTel avc-site). The corrections that were applied to H.323v4 and the corrections that will be applied to H.225.0v4 can also be found on the Packetizer site. Best Regards, Paul E. Jones Rapporteur, ITU-T Q.2/16

1 0

Re: H.323 Annex I
by Baese Gero 07 Feb '01

07 Feb '01

Dear Stephan, experts, your are completely right and your point is out of discussion, of course. As you mentioned it is a problem with the wording only. The slice length should certainly be used in an efficient way but nobody should be restricted to use it in a special manner. Hopefully this small discussion/misunderstanding is now clarified. Best Wishes Gero Baese ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- Folks, At 04:47 PM 2/5/2001 -0800, Adam Li wrote: >Dear Mr. Baese, and Q.3 experts, > >First, since I haven't got Mr. Baese's opinion on what we pointed out in the >last email, I would like to repeat one more time and seeking a definite >answer (i.e., agree or disagree with your reasons). [...] What is the point of even discussing conditions where entities (be it slices or partitions) are bigger than the MTU size? No reasonable implementation would do this. >For the following in the testing condition documents "When the Annex K >and/or Annex V is used, the length of the slice should be such to make >packets fit in the length of segment to avoid segmentation of the IP packet >(for fixed segment-loss-rate channels, see below)." I'm not sure whether this sentence is the best possible wording to describe that a packet should be smaller than the MTU size. But this is just a matter of wording anyway. Stephan P.s. Personally, I would be much in favor of letting Annex I die the peaceful death it deserves -- given the amount of support it receives. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

None
by Baese Gero 07 Feb '01

07 Feb '01

Dear Mr. Li, experts, a wording problem caused this discussion/misunderstanding concerning the slice length. You are completely free to use H.263 Annex K and Annex V the way you think it would be the best for your proposal and the optimum. In general, for a fair comparison parameter adjustments should be done the way it is widespread used. > For the following in the testing condition documents "When the Annex K > and/or Annex V is used, the length of the slice should be such to make > packets fit in the length of segment to avoid segmentation of > the IP packet. This would prevent us from using different approaches. Therefore we propose using "might" instead of "should" and as mentioned above you can use it in the optimal manner for your proposal. While testing your approach we will use it the way you proposed. If you agree on that we will incorporate it in the test scenario document APC-1993. We are still waiting for your contribution to the internet test section(Fixed Packet Loss Rate IP Channel). Best Wishes Gero Baese ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0