Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Chris, About your comments 1. B can make A start H.245 by using facility message with reason startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. 2. About 6.2.8 I agree that it states the H.245 shall be established, it does not say when. The when is mentioned in 8.1.7.2. Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, March 21, 2001 3:31 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni,
H.323 mandates the support of H.245 for end points that comply with the standard. It does not mean, when using fast connect that it must be open immediately but can be opened at a later stage by any side. Except that it states exactly the opposite in the section under discussion.
Also, consider the following scenario: Two endpoints, A and B. B does not support tunnelled H.245. A calls B, without giving any H.245 address in its Setup message. B accepts the call on the basis of fastStart. No H.245 channel is set up, as you suggest. Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. It can't set up the H.245 channel. A could set it up, but doesn't see the need.
The reason for mandating H.245 is to supply a control channel and is important for gateways and MCUs as well as for control functions in point to point calls such as Video fast updates. H.323 annex F defines a simple end point that has H.245 support as optional. I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you have to support it but not to actually open it as in simple fast connect calls. But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL be opened.
As for DTMF you can use the DTMF RTP payload to have it in band instead of H.245. If the person you're talking to happens to support this. Of course you don't know whether or not it does if you haven't exchanged TCS.
-----Original Message----- From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] Sent: Tuesday, March 20, 2001 6:59 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Chris,
Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If
Please let's not break this! Regards, Chris that
is the case, then the extract from H.323v2 below is misleading(I believe).
H.323v2: 8.1.7 Fast Connect Procedure
"..... The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection."
BR, Charles
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, March 20, 2001 5:47 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
It does NOT defeat ANY of the stated aims of FastConnect. These aims were to get agreed media channels in both directions open as quickly as possible. Doing FastStart AND H.245 gives you your media quickly, and means you have the power of H.245 thereon.
In-band DTMF transfer may be used. If you happen to be using a codec that supports it. If you assume it when you're using an unsuitable codec you'll have a problem. Which is a reason for using H.245 capability negotiation.
Regards, Chris
Agboh, Charles wrote:
which defeats the whole point of having a Fast Connect
procedure (FS +
H.245). Why isn't in-band- DTMF transfer used instead (in FS)?
-Charles
-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, March 20, 2001 4:40 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the
requirement for
establishing a H.245 control channel??
Chris,
I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened.
To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel.
Frank
cwp@isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification:
Frank,
Why do you consider this text to be "conflicting"? Specifically, with what does it conflict?
Regards, Chris
6.2.8/H.323 states: "The endpoint shall establish exactly
one H.245
Control Channel for each call that the endpoint is
participating in."
8.1.7/H.323 never states that when Fast Connect is being
used such a
control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245
procedures.
It would seem that section 6.2.8 should be rephrased to
make clear that
the H.245 control channel shall only be established when
"normal" H.245
procedures are being followed and not in the fast connect case.
Frank
-- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Roni, Frank, Paul Jones et al, Having reread 8.1.7.2 (as referenced by Roni) I believe that Frank was right all along in saying there is a conflict. 8.1.7.2 saying that a device "may" establish an H.245 session at any point during a call is, I would argue, clearly at odds with 6.2.8 stating that such a session "shall" be established. After all, having not bothered to bring one up until an instant before the end of the call (clearly permitted by 8.1.7.2), why create one at that stage (except because 6.2.8 tells you to...)? There is an alternative reading: the implication of 6.2.8 is that some sort of H.245 session should start immediately (the start and end are the only "special" times in an ordinary call, so if you must start one it's pretty well a requirement to do it immediately). What I don't recall is whether it's permitted to drop an H.245 session during a call. I think it is. So is there an alternative reading, saying "start the H.245 channel at the beginning of the call, but you may drop and restart it as you like during the call"? I don't like this reading, though, it's probably the worst of all worlds. However I don't like the delay of setting up an H.245 session being added to the time taken to transmit the first DTMF tone in a call either... Paul, I think this really needs tidying up one way or another - I think it's a job for the implementors guide... Consensus currently seems to be against me, and to be that we should dump the relevant text in 6.2.8. Regards, Chris Roni Even wrote:
Chris, About your comments
1. B can make A start H.245 by using facility message with reason startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. 2. About 6.2.8 I agree that it states the H.245 shall be established, it does not say when. The when is mentioned in 8.1.7.2. Roni Even
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, March 21, 2001 3:31 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Roni,
H.323 mandates the support of H.245 for end points that comply with the standard. It does not mean, when using fast connect that it must be open immediately but can be opened at a later stage by any side.
Except that it states exactly the opposite in the section under discussion.
Also, consider the following scenario: Two endpoints, A and B. B does not support tunnelled H.245. A calls B, without giving any H.245 address in its Setup message. B accepts the call on the basis of fastStart. No H.245 channel is set up, as you suggest. Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. It can't set up the H.245 channel. A could set it up, but doesn't see the need.
The reason for mandating H.245 is to supply a control channel and is important for
gateways
and MCUs as well as for control functions in point to point calls such as Video fast updates. H.323 annex F defines a simple end point that has
H.245
support as optional. I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you have to support it but not to actually open it as in simple fast connect calls.
But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL be opened.
As for DTMF you can use the DTMF RTP payload to have it in band instead of H.245.
If the person you're talking to happens to support this. Of course you don't know whether or not it does if you haven't exchanged TCS.
Please let's not break this!
Regards, Chris
-----Original Message----- From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] Sent: Tuesday, March 20, 2001 6:59 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Chris,
Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If
that
is the case, then the extract from H.323v2 below is misleading(I believe).
H.323v2: 8.1.7 Fast Connect Procedure
"..... The Fast Connect procedure allows the endpoints to establish a
basic
point-to-point call with as few as one round-trip message exchange,
enabling
immediate media stream delivery upon call connection."
BR, Charles
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, March 20, 2001 5:47 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
It does NOT defeat ANY of the stated aims of FastConnect. These aims were to get agreed media channels in both directions open as quickly as possible. Doing FastStart AND H.245 gives you your media quickly, and means you have the power of H.245 thereon.
In-band DTMF transfer may be used. If you happen to be using a codec that supports it. If you assume it when you're using an unsuitable codec you'll have a problem. Which is a reason for using H.245 capability negotiation.
Regards, Chris
Agboh, Charles wrote:
which defeats the whole point of having a Fast Connect
procedure (FS +
H.245). Why isn't in-band- DTMF transfer used instead (in FS)?
-Charles
-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, March 20, 2001 4:40 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the
requirement for
establishing a H.245 control channel??
Chris,
I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened.
To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel.
Frank
cwp@isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification:
Frank,
Why do you consider this text to be "conflicting"? Specifically, with what does it conflict?
Regards, Chris
6.2.8/H.323 states: "The endpoint shall establish exactly
one H.245
Control Channel for each call that the endpoint is
participating in."
8.1.7/H.323 never states that when Fast Connect is being
used such a
control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245
procedures.
It would seem that section 6.2.8 should be rephrased to
make clear that
the H.245 control channel shall only be established when
"normal" H.245
procedures are being followed and not in the fast connect case.
Frank
-- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
-- 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
Roni, Frank, Paul Jones et al,
Having reread 8.1.7.2 (as referenced by Roni) I believe that Frank was right all along in saying there is a conflict. 8.1.7.2 saying that a device "may" establish an H.245 session at any point during a call is, I would argue, clearly at odds with 6.2.8 stating that such a session "shall" be established. After all, having not bothered to bring one up until an instant before the end of the call (clearly permitted by 8.1.7.2), why create one at that stage (except because 6.2.8 tells you to...)?
There is an alternative reading: the implication of 6.2.8 is that some sort of H.245 session should start immediately (the start and end are the only "special" times in an ordinary call, so if you must start one it's pretty well a requirement to do it immediately). What I don't recall is whether it's permitted to drop an H.245 session during a call. I think it is. So is there an alternative reading, saying "start the H.245 channel at the beginning of the call, but you may drop and restart it as you like during the call"? I don't like this reading, though, it's probably the worst of all worlds.
However I don't like the delay of setting up an H.245 session being added to the time taken to transmit the first DTMF tone in a call either...
Paul,
I think this really needs tidying up one way or another - I think it's a job for the implementors guide... Consensus currently seems to be against me, and to be that we should dump the relevant text in 6.2.8.
Regards, Chris
Roni Even wrote:
Chris, About your comments
1. B can make A start H.245 by using facility message with reason startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. 2. About 6.2.8 I agree that it states the H.245 shall be established, it does not say when. The when is mentioned in 8.1.7.2. Roni Even
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, March 21, 2001 3:31 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Roni,
H.323 mandates the support of H.245 for end points that comply with the standard. It does not mean, when using fast connect that it must be open immediately but can be opened at a later stage by any side.
Except that it states exactly the opposite in the section under discussion.
Also, consider the following scenario: Two endpoints, A and B. B does not support tunnelled H.245. A calls B, without giving any H.245 address in its Setup message. B accepts the call on the basis of fastStart. No H.245 channel is set up, as you suggest. Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. It can't set up the H.245 channel. A could set it up, but doesn't see
Chris, My opinion is that, if you do Fast Connect, there is no need to start H.245. I agree that support shall be there, so that either end may initiate H.245 for whatever reason, but if using Fast Connect, opening the H.245 channel should be optional. Also, as I suggested earlier, given that tunneling is the "norm" now, one could argue that the H.245 channel is already there... we just don't exchanges messages over it :-) (Yes, I know.. that's a weak argument.) Paul ----- Original Message ----- From: "Chris Wayman Purvis" <cwp@ISDN-COMMS.CO.UK> To: <ITU-SG16@mailbag.cps.INTEL.COM> Sent: Thursday, March 22, 2001 6:27 AM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? the
need.
The reason for mandating H.245 is to supply a control channel and is important for
gateways
and MCUs as well as for control functions in point to point calls such as Video fast updates. H.323 annex F defines a simple end point that has
H.245
support as optional. I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you have to support it but not to actually open it as in simple fast connect calls.
But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL be opened.
As for DTMF you can use the DTMF RTP payload to have it in band instead of H.245.
If the person you're talking to happens to support this. Of course you don't know whether or not it does if you haven't exchanged TCS.
Please let's not break this!
Regards, Chris
-----Original Message----- From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] Sent: Tuesday, March 20, 2001 6:59 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Chris,
Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If
that
is the case, then the extract from H.323v2 below is misleading(I believe).
H.323v2: 8.1.7 Fast Connect Procedure
"..... The Fast Connect procedure allows the endpoints to establish a
basic
point-to-point call with as few as one round-trip message exchange,
enabling
immediate media stream delivery upon call connection."
BR, Charles
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, March 20, 2001 5:47 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
Charles,
It does NOT defeat ANY of the stated aims of FastConnect. These aims were to get agreed media channels in both directions open as quickly as possible. Doing FastStart AND H.245 gives you your media quickly, and means you have the power of H.245 thereon.
In-band DTMF transfer may be used. If you happen to be using a codec that supports it. If you assume it when you're using an unsuitable codec you'll have a problem. Which is a reason for using H.245 capability negotiation.
Regards, Chris
Agboh, Charles wrote:
which defeats the whole point of having a Fast Connect
procedure (FS +
H.245). Why isn't in-band- DTMF transfer used instead (in FS)?
-Charles
-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, March 20, 2001 4:40 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the
requirement for
establishing a H.245 control channel??
Chris,
I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened.
To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel.
Frank
cwp@isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification:
Frank,
Why do you consider this text to be "conflicting"? Specifically, with what does it conflict?
Regards, Chris
> 6.2.8/H.323 states: "The endpoint shall establish exactly
one H.245
> Control Channel for each call that the endpoint is
participating in."
> 8.1.7/H.323 never states that when Fast Connect is being
used such a
> control channel should be established. As far as I understand the > mechanism this is only required to switch to "normal" H.245
procedures.
> It would seem that section 6.2.8 should be rephrased to
make clear that
> the H.245 control channel shall only be established when
"normal" H.245
> procedures are being followed and not in the fast connect case. > > Frank
-- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
-- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Chris Wayman Purvis -
Paul E. Jones -
Roni Even