On Mon, 3 Mar 2003 10:59:08 -0500 James Rafferty <[EMAIL PROTECTED]> wrote:
> I asked my colleague David Duehren, the ITU-T T.38 editor, about this issue > and he responded as follows: > > "...the T.38 version number is an attribute that is exchanged during call > set up (an OLC I believe in H.323) before any T.38 signal is sent. The > OLCs, if memory serves me, are sent via TCP. The version attribute is also > in the SDP. Interesting. Pity AnnexD/H.323v4 never mentions this field and H.245v7 only says "as per T.38". And neither the version of T.38 I was using, nor the implementer guide from Feb 2000 mentions it. Ah, the perils of evolving protocols and specification! > >From a practical point of view, the "correction" appeared in T.38 version 2 > (there's now a table in T.38 explaining the version numbers) This available anywhere? Is it the current ITU document? > and I doubt > implementors are going to go back to their old versions and fix them > (although I think they should). It's technically feasible to build a > decoder that works for packets encoded with or without the correction. Indeed. Though getting it in later versions of your software still helps! > I would add that for anyone who was actually following the ITU work on T.38, > this problem was known right from the point that the ITU made the mistake in > the first publication, and > we confirmed this in a Fall 1999 SG8 rapporteur's meeting, that led to the > corrigendum to which Dave refers. > > Since T.38 is an evolving standard that needs updates to address attribute > changes, the T.38 versioning was introduced a while back and is being > carried forward. As an implementor, it is very useful to know the context > in which a standard is evolving, whether it is H.323, T.38, SIP, etc.. > Otherwise, it is easy to be surprised, as fixes and improvments get made to > a standard. The H.323 implementor's list has done a pretty good job of > providing some context on H.323, but the list's coverage of T.38's evolution > as it relates to H.323 has been more > limited. Hence, this "surprise", which has been known to participants > within SG8 and now SG16 Q14 all along; unfortunately the ITU publications > department was not quick to fix the error and get this information > disseminated outside of the Study Group participants. This is not terribly helpful. Saying this is not a surprise to the specification writers just means communications between them and the community is not very good. Remember, not every company or developer can actively keep abreast of all of the standards developments on all fronts. Go to rapporteur's meetings etc. Lord knows I want to! But real world practicalities are that most people can't. P.S. This is a just a bit of a whinge by me and I do not expect that anything can change about it. It's just "one of those things, ya know?" ---------- Robert Jongbloed Equivalence Pty. Ltd. Architect Open Phone Abstraction Library (OPAL) & OpenH323 Open Source Telecommunication Protocol Libraries - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Quicknet's revolutionary MicroTelco Services offers LOW WORLDWIDE RATES ANY TIME OF THE DAY with No monthly fees! No monthly minimums! No connection fees! US rates as low as 2.9 cents a minute! To see more rates, visit www.microtelco.com ****LIVE VIDEO CONFERENCE NOW AVAILABLE***** CUworld 6.0 is an affordable easy-to-use service providing live visual communication between friends, family and colleagues worldwide. For more information visit www.cuworld.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
