Hi, 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. >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) 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. In the upcoming V.34 ammendment, we've added some clarification around the meaning and use of the version numbers, though it doesn't specifically address the corrigendum issue." (end of Dave's comments) 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. James Rafferty * ----------------------------------- James Rafferty Senior Product Manager, IP Telephony [EMAIL PROTECTED] Brooktrout Technology 410 First Avenue Needham, MA 02494 USA Phone: +1-781-433-9462 Fax: 781-433-9268 www.brooktrout.com Your Hook into the New Network(SM) > -----Original Message----- > From: Equivalence Support [mailto:[EMAIL PROTECTED] > Sent: Monday, March 03, 2003 12:45 AM > To: Paul E. Jones > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: [imtch323implementors] Re: T.38 potentially broken by recent > Corrigendum > > > > On Sun, 2 Mar 2003 21:20:51 -0500 > "Paul E. Jones" <[EMAIL PROTECTED]> wrote: > > > I just recently discovered that the ITU-T published a corrigendum to > > T.38 (1998) that apparently breaks backward compatibility > for all T.38 > > devices currently deployed that follow the original 1998 > specifications. > ... > > What I would like to know is whether this change impacts > your product or > > not. I am aware of many deployed devices on the market today that > > employs the 1998 syntax without this ellipsis. I would > like to find out > > to what extent this change is going to present problems for > companies > > represented on various lists and, if I get sufficient > support, I want to > > take a contribution to the ITU-T SG16 meeting in May to try > to resolve > > this problem in such a way as to not break backward > compatibility and > > interoperability. > > From the point of view of OpenH323 this was most assuredly a nasty and > annoying problem! Which version is used seems to vary from product to > product and even what version of product. > > And more importantly, as far as I could tell, it is impossible to > determine at run time which version is in use. You must > establish this a > priory and decode PDU's accordingly. And if a stack does not identify > itself sufficiently you get into all sorts of trouble. Not > very good for > interoperability! > > I am not sure what they could have done so you could tell at run time. > The only thing I could think of was to add a new Type-Of-Message data > enumeration type (eg t38-version2) which must be sent before any other > data PDU's. The receiving stack can then assume if it is there that it > uses the new syntax and if not the old. > > This is not perfect though as the PDU's are sent by UDP and even with > some redundancy you cannot GUARANTEE it will work! > > > ---------- > 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 > > > --- > You are currently subscribed to imtch323implementors as: > [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
