James, As this was a Corrigendum publish in May 2001, this change actually impacts T.38 (1998) and there is no specified versioning for this.
In other words, it really does break all T.38 implementations. Paul ----- Original Message ----- From: "James Rafferty" <[EMAIL PROTECTED]> To: "'Equivalence Support'" <[EMAIL PROTECTED]>; "Paul E. Jones" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 10:59 AM Subject: RE: [imtch323implementors] Re: T.38 potentially broken by recent Corrigendum > 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
