AW: H.225.0 v4 inconsistencies/errors found
Paul, having been through it a number of time does not solve a problem at all unless we fix it. Facts are: 1) Octet 3a is an optional octet in calling party number IE. It may or may not be present. 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2), specifies the use of the extension bit to indicate presence or absence of optional octets. 3) My interpretation of 7.2.2.6 of H.225.0 is that Q.931 clause 4.5.10 applies for the coding of calling party number, including the use of octet 3 bit 8 as extension bit. 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly set to '1'. 5) Octet 3a, when present, poses a problem for v1 in any case, independent of bit 8 of octet 3! 6) Clearing the call if an optional information element is flawed is not correct - it should be ignored. Clearing is only correct for erroneous mandatory or 'comprehension-required' optional IEs. Calling party number is not 'comprehension-required'. Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Paul Long [mailto:Plong@SMITHMICRO.COM] Gesendet am: Donnerstag, 08. Juni 2000 05:03 An: ITU-SG16@mailbag.cps.intel.com Betreff: Re: H.225.0 v4 inconsistencies/errors found
Karl,
We've been through this before. Allowing the extension bit in octet 3 to be set to 0 causes H.225.0v4 to be inconsistent with earlier versions and potentially causes insurmountable backwards-compatibility problems between v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall not be set to 0 under any circumstances. Since the calling EP cannot know the version of the called EP before it sends Setup, it would be sending an IE that would contain invalid content for a pre-v4 EP. According to Q.931, the receiving EP would then be required to terminate the call with ReleaseComplete. A safe solution would be to add a new Calling Party Number field where this bit is allowed to be set to 0.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Klaghofer Karl ICN SIB NL D1 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, June 07, 2000 10:29 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 v4 inconsistencies/errors found
Rich, and others
Please find below comments I have in the area of Calling Party Number IE and the ASN.1 elements ScreeningIndicator and PresentationIndicator. Comments no. 1-4 should be corrected by the editor in v4, since these are inconsistencies/errors. Comment 5 could be solved later.
1) Calling Party Number IE (octet 3 extension bit 8) The H.225.0v4 definition looks as follows: - Set to '1' This is not compliant with the extension bit handling used in Q.931 and H.225.0. It should be corrected in v4 (v3 impl guide) to read: - Set to '1' if octet 3a is not present; set to "0" if octet 3a is present.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Ernst, Likewise the fact remains that as in earlier versions the bit "shall not" be set, so earlier version devices on receiving a SETUP message with the bit set at best should be sending RELEASE COMPLETE and at worst have undefined behaviour. In other words suddenly allowing this bit to be set knowingly violates the ITU's principle of backward compatibility, and is hence not acceptable if you wish the resulting protocol to be called H.323. I take issue with your "comprehension-required" points too. My (hazy) understanding is that if bit 8 or octet 3 is set to 0, this inserts an extra byte into the message (octet 3a) - so comprehension of this bit is clearly required if the rest of the message is to be parsed! Regards, Chris Horvath Ernst wrote:
Paul,
having been through it a number of time does not solve a problem at all unless we fix it.
Facts are: 1) Octet 3a is an optional octet in calling party number IE. It may or may not be present. 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2), specifies the use of the extension bit to indicate presence or absence of optional octets. 3) My interpretation of 7.2.2.6 of H.225.0 is that Q.931 clause 4.5.10 applies for the coding of calling party number, including the use of octet 3 bit 8 as extension bit. 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly set to '1'. 5) Octet 3a, when present, poses a problem for v1 in any case, independent of bit 8 of octet 3! 6) Clearing the call if an optional information element is flawed is not correct - it should be ignored. Clearing is only correct for erroneous mandatory or 'comprehension-required' optional IEs. Calling party number is not 'comprehension-required'.
Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Paul Long [mailto:Plong@SMITHMICRO.COM] Gesendet am: Donnerstag, 08. Juni 2000 05:03 An: ITU-SG16@mailbag.cps.intel.com Betreff: Re: H.225.0 v4 inconsistencies/errors found
Karl,
We've been through this before. Allowing the extension bit in octet 3 to be set to 0 causes H.225.0v4 to be inconsistent with earlier versions and potentially causes insurmountable backwards-compatibility problems between v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall not be set to 0 under any circumstances. Since the calling EP cannot know the version of the called EP before it sends Setup, it would be sending an IE that would contain invalid content for a pre-v4 EP. According to Q.931, the receiving EP would then be required to terminate the call with ReleaseComplete. A safe solution would be to add a new Calling Party Number field where this bit is allowed to be set to 0.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Klaghofer Karl ICN SIB NL D1 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, June 07, 2000 10:29 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 v4 inconsistencies/errors found
Rich, and others
Please find below comments I have in the area of Calling Party Number IE and the ASN.1 elements ScreeningIndicator and PresentationIndicator. Comments no. 1-4 should be corrected by the editor in v4, since these are inconsistencies/errors. Comment 5 could be solved later.
1) Calling Party Number IE (octet 3 extension bit 8) The H.225.0v4 definition looks as follows: - Set to '1' This is not compliant with the extension bit handling used in Q.931 and H.225.0. It should be corrected in v4 (v3 impl guide) to read: - Set to '1' if octet 3a is not present; set to "0" if octet 3a is present.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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 3a. - Rich Chris Wayman Purvis wrote:
Ernst,
Likewise the fact remains that as in earlier versions the bit "shall not" be set, so earlier version devices on receiving a SETUP message with the bit set at best should be sending RELEASE COMPLETE and at worst have undefined behaviour. In other words suddenly allowing this bit to be set knowingly violates the ITU's principle of backward compatibility, and is hence not acceptable if you wish the resulting protocol to be called H.323.
I take issue with your "comprehension-required" points too. My (hazy) understanding is that if bit 8 or octet 3 is set to 0, this inserts an extra byte into the message (octet 3a) - so comprehension of this bit is clearly required if the rest of the message is to be parsed!
Regards, Chris
Horvath Ernst wrote:
Paul,
having been through it a number of time does not solve a problem at all unless we fix it.
Facts are: 1) Octet 3a is an optional octet in calling party number IE. It may or may not be present. 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2), specifies the use of the extension bit to indicate presence or absence of optional octets. 3) My interpretation of 7.2.2.6 of H.225.0 is that Q.931 clause 4.5.10 applies for the coding of calling party number, including the use of octet 3 bit 8 as extension bit. 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly set to '1'. 5) Octet 3a, when present, poses a problem for v1 in any case, independent of bit 8 of octet 3! 6) Clearing the call if an optional information element is flawed is not correct - it should be ignored. Clearing is only correct for erroneous mandatory or 'comprehension-required' optional IEs. Calling party number is not 'comprehension-required'.
Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Paul Long [mailto:Plong@SMITHMICRO.COM] Gesendet am: Donnerstag, 08. Juni 2000 05:03 An: ITU-SG16@mailbag.cps.intel.com Betreff: Re: H.225.0 v4 inconsistencies/errors found
Karl,
We've been through this before. Allowing the extension bit in octet 3 to be set to 0 causes H.225.0v4 to be inconsistent with earlier versions and potentially causes insurmountable backwards-compatibility problems between v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall not be set to 0 under any circumstances. Since the calling EP cannot know the version of the called EP before it sends Setup, it would be sending an IE that would contain invalid content for a pre-v4 EP. According to Q.931, the receiving EP would then be required to terminate the call with ReleaseComplete. A safe solution would be to add a new Calling Party Number field where this bit is allowed to be set to 0.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Klaghofer Karl ICN SIB NL D1 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, June 07, 2000 10:29 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 v4 inconsistencies/errors found
Rich, and others
Please find below comments I have in the area of Calling Party Number IE and the ASN.1 elements ScreeningIndicator and PresentationIndicator. Comments no. 1-4 should be corrected by the editor in v4, since these are inconsistencies/errors. Comment 5 could be solved later.
1) Calling Party Number IE (octet 3 extension bit 8) The H.225.0v4 definition looks as follows: - Set to '1' This is not compliant with the extension bit handling used in Q.931 and H.225.0. It should be corrected in v4 (v3 impl guide) to read: - Set to '1' if octet 3a is not present; set to "0" if octet 3a is present.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Rich, 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 many 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@CISCO.COM] Sent: Thursday, June 08, 2000 2:21 PM To: ITU-SG16@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 3a. - Rich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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 alright. 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. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Paul Long <Plong@SMITHMICRO.COM> To: <ITU-SG16@MAILBAG.INTEL.COM> Sent: 09 June 2000 02:19 Subject: Re: AW: H.225.0 v4 inconsistencies/errors found
Rich,
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 many 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@CISCO.COM] Sent: Thursday, June 08, 2000 2:21 PM To: ITU-SG16@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 3a.
- Rich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
I want to make it clear that I didn't intend to re-open the octet 3a debate. On the contrary, I was trying to point out that it was put to rest a long time ago. I just want to fix the inconsistency that Karl noticed. - Rich Paul Long wrote:
Rich,
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 many 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@CISCO.COM] Sent: Thursday, June 08, 2000 2:21 PM To: ITU-SG16@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 3a.
- Rich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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 3a.
- Rich
Chris Wayman Purvis wrote:
Ernst,
Likewise the fact remains that as in earlier versions the bit "shall
not" be
set, so earlier version devices on receiving a SETUP message with the bit set at best should be sending RELEASE COMPLETE and at worst have undefined behaviour. In other words suddenly allowing this bit to be set knowingly violates
ITU's principle of backward compatibility, and is hence not acceptable if you wish the resulting protocol to be called H.323.
I take issue with your "comprehension-required" points too. My (hazy) understanding is that if bit 8 or octet 3 is set to 0, this inserts an extra byte into the message (octet 3a) - so comprehension of this bit is clearly required if the rest of the message is to be parsed!
Regards, Chris
Horvath Ernst wrote:
Paul,
having been through it a number of time does not solve a problem at
all
unless we fix it.
Facts are: 1) Octet 3a is an optional octet in calling party number IE. It may or may not be present. 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2), specifies the use of the extension bit to indicate presence or absence of optional octets. 3) My interpretation of 7.2.2.6 of H.225.0 is that Q.931 clause 4.5.10 applies for the coding of calling party number, including the use of octet 3 bit 8 as extension bit. 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly set to '1'. 5) Octet 3a, when present, poses a problem for v1 in any case, independent of bit 8 of octet 3! 6) Clearing the call if an optional information element is flawed is not correct - it should be ignored. Clearing is only correct for erroneous mandatory or 'comprehension-required' optional IEs. Calling party number is not 'comprehension-required'.
Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Paul Long [mailto:Plong@SMITHMICRO.COM] Gesendet am: Donnerstag, 08. Juni 2000 05:03 An: ITU-SG16@mailbag.cps.intel.com Betreff: Re: H.225.0 v4 inconsistencies/errors found
Karl,
We've been through this before. Allowing the extension bit in octet 3 to be set to 0 causes H.225.0v4 to be inconsistent with earlier versions and potentially causes insurmountable backwards-compatibility problems between v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall not be set to 0 under any circumstances. Since the calling EP cannot know the version of the called EP before it sends Setup, it would be sending an IE that would contain invalid content for a pre-v4 EP. According to Q.931, the receiving EP would then be required to terminate the call with ReleaseComplete. A safe solution would be to add a new Calling Party Number field where this bit is allowed to be set to 0.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Klaghofer Karl ICN SIB NL D1 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, June 07, 2000 10:29 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 v4 inconsistencies/errors found
Rich, and others
Please find below comments I have in the area of Calling Party Number IE and the ASN.1 elements ScreeningIndicator and PresentationIndicator. Comments no. 1-4 should be corrected by the editor in v4, since
Rich, I think this is yet more evidence that we should consider breaking ties with Q.931 altogether. These inconsistencies are problematic, to say the least. I have heard from many vendors who say "but Q.931 says this". The fact is, encoding is done according to H.225.0. From the H.323 Implementers Guide, February 2000: ``Information Elements shall be encoded according to Q.931, except where modified in this Recommendation.'' This qualifies as "modified by H.225.0". The extension bit must always be set to 1, but the extension shall also be present. This is not as pretty as it should be, but would probably be a non-issue if we follow Bob's suggestion to break ties with Q.931. Perhaps the editors of V5 would like to take on this challenge? :-) Paul ----- Original Message ----- From: "Rich Bowen" <rkbowen@CISCO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Thursday, June 08, 2000 3:21 PM Subject: Re: AW: H.225.0 v4 inconsistencies/errors found the these
are inconsistencies/errors. Comment 5 could be solved later.
1) Calling Party Number IE (octet 3 extension bit 8) The H.225.0v4 definition looks as follows: - Set to '1' This is not compliant with the extension bit handling used in Q.931 and H.225.0. It should be corrected in v4 (v3 impl guide) to read: - Set to '1' if octet 3a is not present; set to "0" if octet 3a is present.
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv@mailbag.intel.com
> > > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv@mailbag.intel.com
> >
> > --
> > Dr Chris Purvis -- Development Manager
> > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > Winkfield Row, Berkshire. RG42 6LY ENGLAND
> > Phone: +44 1344 899 007
> > Fax: +44 1344 899 001
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv@mailbag.intel.com
>
> --
> --------------------------------------------------------------------
> Richard K. Bowen Cisco Systems, Inc.
> rkbowen@cisco.com Research Triangle Park, NC
> --------------------------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv@mailbag.intel.com
>
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (6)
-
Chris Wayman Purvis -
Horvath Ernst -
Paul E. Jones -
Paul Long -
Pete Cordell -
Rich Bowen