AW: H.225.0 v4 inconsistencies/errors found
pete at TECH-KNOW-WARE.COM
Fri Jun 9 04:07:22 EDT 2000
Just so you don't feel alone Paul,...
I agree that this action does seem symbolic of the voodoo science that is
being put into H.323.
The theory seems to be that if I wish really hard then it will all be
I'm beginning to wonder why I spent so many years at university learning
solid engineering principles.
And all those years of getting nasty little un-foreseen bugs despite my best
efforts were obviously not because the physical world is a hard task master,
but because I wasn't wishing hard enough that it would all be alright!
H.323 - Another production by Disney!
pete at tech-know-ware.com
+44 1473 635863
----- Original Message -----
From: Paul Long <Plong at SMITHMICRO.COM>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: 09 June 2000 02:19
Subject: Re: AW: H.225.0 v4 inconsistencies/errors found
> I know I'm fighting a losing battle, so I'll be quiet. Just realize that
> (one last parting shot :-) )
> 1. this change risks undesired behavior (call termination) or at least
> undefined behavior (EP crashes? EP accepts?),
> 2. there is really no way to know whether this breaks existing
> implementations (you can't just ask 12 people around a table or 100 people
> on an email reflector because many may not actually know the answer and
> more didn't even hear the question), and
> 3. there are alternatives that are completely safe.
> Paul Long
> Smith Micro Software, Inc.
> "Primum non nocere"
> -----Original Message-----
> From: Rich Bowen [mailto:rkbowen at CISCO.COM]
> Sent: Thursday, June 08, 2000 2:21 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: AW: H.225.0 v4 inconsistencies/errors found
> The backward compatibility issue was debated last year on the mailing
> lists and in Santiago (5/99). No implementor claimed to have a backward
> compatibility problem, and it was agreed in Santiago that octet 3a would
> be allowed, as shown in H.225.0 v3. However, now the text is
> inconsistent with itself, in that it allows octet 3a but says that the
> extension bit shall be set to 1, thus indicating that octet 3a is not
> present. This is an error in v3 that needs to be corrected to indicate
> that the value may be either 0 or 1 to indicate the presence of octet
> - Rich
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd