Paul, A mechanism was introduced after this Corrigendum was approved to add versioning support for T.38. Version information can be added to SDP as well as H.245. Unfortunately, no such allowance in the versioning was provided for this ASN.1 syntax change.
Paul ----- Original Message ----- From: "Paul Long" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, March 04, 2003 9:46 AM Subject: [Sip-implementors] RE: [imtch323implementors] Re: T.38 potentially broken by recent Corrigendum > Here's my two cents... The corrigendum broke the standard because T.38 was > not defective to begin with. There was an editorial mistake in the ASN.1 > syntax tree, but T.38 was perfectly implementable as is. Standards are rife > with instances where mistakes like this must unfortunately be accomodated in > order to preserve backwards compatibility. > > That said, however, I don't know how to fix the problem. Can the corrigendum > be withdrawn? Hmmm, it sounds like this has also been incorpated into > T.38v2. Bummer. Maybe it's a matter of how many entities have shipped with > and without the corrigendum, e.g., 100 with and 10,000 without? How about > this: As with versioning in H.323, perhaps the onus should be on the newer > entity--when it detects that the other entity is T.38v1 (corrigendum be > damned), it shall produce an encoding without the extension bit. > > Paul > > -----Original Message----- > From: Paul E. Jones [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 2:32 AM > To: James Rafferty; 'Equivalence Support' > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [imtch323implementors] Re: T.38 potentially broken by recent > Corrigendum > > > 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 > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
