May 2004 - sg16-avd - lists.packetizer.com

RE: Comments on AVD-2464 (H.245 OLC Master/Slave conflicts)
by Tsahi Levent-Levi 05 May '04

05 May '04

Hi, The reasons stated below are not the actual reasons. The main reason is the fact that the standard doesn't state anything about conflicts that arise because of uni/bi-direction-ness of channels. Since H.324 can open video channels as bi-directional or uni-directional, such conflicts are quite common. In the Geneva meeting, it was suggested to add a new chapter into the standard about this and a new appendix with the illustrations. Tsahi -----Original Message----- From: Dave Lindbergh [mailto:lindbergh@92f1.com] Sent: Tuesday, May 04, 2004 11:47 PM To: itu-sg16(a)external.cisco.com; Tsahi Levent-Levi Cc: Roni Even; Dave Lindbergh; Paul Jones <paulej(a)packetizer.com> Subject: Comments on AVD-2464 (H.245 OLC Master/Slave conflicts) Hi all, I regret that I will be unable to attend the Beijing meeting. Re AVD-2464, (on H.245 OLC Master/Slave conflicts), the proposed material appears to be redundant with the existing text in C.4.1.3/H.245 and C.5.1.3/H.245. Perhaps I misunderstand. If I remember correctly, this issue was discussed in Geneva, and one of the reasons given for adding this text was that some implementations do not follow the procedures of C.4.1.3 and C.5.1.3 correctly (that is, they don't handle Master/Slave OLC conflicts per those clauses, which can break interworking). If that is the main motivation, I suggest that it would be better to point out the existing text of C.4.1.3 / C.5.1.3 of H.245 to the implementors so they can correct the bug, than to add redundant text, which may make it more difficult to read and understand H.245. This could have the unintended effect of making mistakes in understanding H.245 more likely (by adding complexity to the document), rather than less. Best regards to all, --Dave Lindbergh ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

RE: Comments on AVD-2464 (H.245 OLC Master/Slave conflicts)
by Tsahi Levent-Levi 05 May '04

05 May '04

Hi, The reasons stated below are not the actual reasons. The main reason is the fact that the standard doesn't state anything about conflicts that arise because of uni/bi-direction-ness of channels. Since H.324 can open video channels as bi-directional or uni-directional, such conflicts are quite common. In the Geneva meeting, it was suggested to add a new chapter into the standard about this and a new appendix with the illustrations. Tsahi -----Original Message----- From: Dave Lindbergh [mailto:lindbergh@92f1.com] Sent: Tuesday, May 04, 2004 11:47 PM To: itu-sg16(a)external.cisco.com; Tsahi Levent-Levi Cc: Roni Even; Dave Lindbergh; Paul Jones <paulej(a)packetizer.com> Subject: Comments on AVD-2464 (H.245 OLC Master/Slave conflicts) Hi all, I regret that I will be unable to attend the Beijing meeting. Re AVD-2464, (on H.245 OLC Master/Slave conflicts), the proposed material appears to be redundant with the existing text in C.4.1.3/H.245 and C.5.1.3/H.245. Perhaps I misunderstand. If I remember correctly, this issue was discussed in Geneva, and one of the reasons given for adding this text was that some implementations do not follow the procedures of C.4.1.3 and C.5.1.3 correctly (that is, they don't handle Master/Slave OLC conflicts per those clauses, which can break interworking). If that is the main motivation, I suggest that it would be better to point out the existing text of C.4.1.3 / C.5.1.3 of H.245 to the implementors so they can correct the bug, than to add redundant text, which may make it more difficult to read and understand H.245. This could have the unintended effect of making mistakes in understanding H.245 more likely (by adding complexity to the document), rather than less. Best regards to all, --Dave Lindbergh ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

Beijing meeting is held as scheduled
by OKUBO Sakae 04 May '04

04 May '04

Dear Q.F,G,2-5/16 experts, There have been expressed some concerns about SARS in Beijing. After having reviewed WHO's information and available news by obtaining TSB's help, I think that SARS is kept controlled. We will hold the Beijing meeting of Q.F,G,2-5/16 as scheduled. Q.B/16 will have its meeting there concurrently. I have had a difficulty to get the updated list of participants from the meeting host. Could you take a look at the table after my signature (as of 26 April) and return a short note to <sokubo(a)waseda.jp> if you are coming to Beijing or not? If you are not listed there but coming, please advise me. Please note that the attached list contains only those from organizations outside China. Local attendees are also welcome to advise me. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** List of participants from organizations outside China 26 April (with modifications with received advice) ============================= Surname Given Name ============================= Boyle II Kevin Joseph Gilman Robert Reagan Euchner Martin Fourie Henry Louis Even Roni Flaiani Roberto Schwarz Albrecht Sambasivan Balasubramanian Lehmann Leo Ruditsky Alexander Wilmot Christopher David Tegeler Juergen Pierce Michael Horvath Ernst Blin Jean-Pierre Groves Christian Levent-Levi Tsahi Holmberg Hans-Christer Auerbach David Teising Charles Conrad Jr. Luthi Patrick Hansen Carl Christian Jeong Seong-Ho Xiangyue Cui =============================

1 0

Fall Meeting in Geneva
by Tyler Johnson 04 May '04

04 May '04

At the last full SG16 meeting it was said that the next meeting was scheduled over the US Thanksgiving holiday in Geneva, but I have yet to see this on the schedule. Can anyone shed any light on the meeting date?

1 0

Comments on AVD-2464 (H.245 OLC Master/Slave conflicts)
by Dave Lindbergh 04 May '04

04 May '04

Hi all, I regret that I will be unable to attend the Beijing meeting. Re AVD-2464, (on H.245 OLC Master/Slave conflicts), the proposed material appears to be redundant with the existing text in C.4.1.3/H.245 and C.5.1.3/H.245. Perhaps I misunderstand. If I remember correctly, this issue was discussed in Geneva, and one of the reasons given for adding this text was that some implementations do not follow the procedures of C.4.1.3 and C.5.1.3 correctly (that is, they don't handle Master/Slave OLC conflicts per those clauses, which can break interworking). If that is the main motivation, I suggest that it would be better to point out the existing text of C.4.1.3 / C.5.1.3 of H.245 to the implementors so they can correct the bug, than to add redundant text, which may make it more difficult to read and understand H.245. This could have the unintended effect of making mistakes in understanding H.245 more likely (by adding complexity to the document), rather than less. Best regards to all, --Dave Lindbergh ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

Comments on AVD-2464 (H.245 OLC Master/Slave conflicts)
by Dave Lindbergh 04 May '04

04 May '04

Hi all, I regret that I will be unable to attend the Beijing meeting. Re AVD-2464, (on H.245 OLC Master/Slave conflicts), the proposed material appears to be redundant with the existing text in C.4.1.3/H.245 and C.5.1.3/H.245. Perhaps I misunderstand. If I remember correctly, this issue was discussed in Geneva, and one of the reasons given for adding this text was that some implementations do not follow the procedures of C.4.1.3 and C.5.1.3 correctly (that is, they don't handle Master/Slave OLC conflicts per those clauses, which can break interworking). If that is the main motivation, I suggest that it would be better to point out the existing text of C.4.1.3 / C.5.1.3 of H.245 to the implementors so they can correct the bug, than to add redundant text, which may make it more difficult to read and understand H.245. This could have the unintended effect of making mistakes in understanding H.245 more likely (by adding complexity to the document), rather than less. Best regards to all, --Dave Lindbergh ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

AVD-2434 and AVD-2435
by Sasha Ruditsky 04 May '04

04 May '04

Hi, I have uploaded AVD-2434 and AVD-2435 in the \incoming directory. Thanks Sasha Ruditsky

1 0

FW: RFC 3762 on Telephone Number Mapping (ENUM) Service Registrat
by simao.campos＠ITU.INT 03 May '04

03 May '04

Dear colleagues, FYI, in case you did not see it... Cheers, Simao

1 0

Q3/16: AVD 2437 for meeting in Beijing
by Tegeler Juergen 03 May '04

03 May '04

Dear all, attached you can find AVD 2437 "AAS INAP Adaptation Packages" which is an update of the delayed contribution D 426 that I presented in Geneva in 01/2004. Comments that were made during the meeting have been considered in the updated document. Changes with respect to D 426 are marked. <<AAS INAP Adaptation Packages AVD 030504.doc>> Best regards, J. Tegeler

1 0