December 2000 - sg16-avd - lists.packetizer.com

Re: Third party registration/group registration
by BOUGANT Fran�ois FTRD/DAC/ISS 01 Dec '00

01 Dec '00

Chris, I don't understand your position on Q3. An endpoint shall attempt to register with all discovered GKs (at least one) only if this endpoint has received at least one GCF message from any GK. My understanding is that a GK returning a GCF message to an endpoint (after having previously received a GRQ message from this endpoint) is active and implicitly ready to register the endpoint; if not the GK shall return a GRJ message. The RRJ message is used by the GK to indicate that the registration has failed and indicates the reason. I think that the endpoint shall re-send a RRQ message with corrections (when possible). If the rejection occurs several times, the endpoint may shut down to re-initialize and re-start the GK discovery procedure. Regards, François BOUGANT & France Télécom R&D FTR&D/DAC/ACE e-mail : francois.bougant(a)francetelecom.fr 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42 -----Message d'origine----- De : Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Envoyé : vendredi 1 décembre 2000 10:46 À : ITU-SG16(a)MAILBAG.INTEL.COM Objet : Re: Third party registration/group registration Paul, I think we're starting to converge. Let's separate this out now, into separate questions: Q1. Are endpoint devices (in which term I include gateways etc throughout this mail) required to implement RAS? A1. Yes (agreed between you and me, disagreed by Charles). Q2. How does an endpoint device know whether or not a gatekeeper is present in the system, and hence whether or not to use RAS? A2a (Your position as I understand it.) Configuration, discovery on startup, give up if you don't find anything then. A2b (My suggestion) Configuration, discovery on startup, retry at some reasonable frequency (hourly?), take the three seconds to attempt gatekeeper discovery when someone makes a call to or from the endpoint in question. A2c (What we'll probably end up agreeing!) Implementation decision. Q3. What should an endpoint do if it attempts to register with all discovered gatekeepers, where there is at least one gatekeeper in the system, and fails (RRJ)? A3a (My position) Shut itself down. A3b (Anybody elses) ??? Q4. Is Charles's actual application, where one entity is registering and hence presumably (although he's consistently failed to clarify) handling RAS on behalf of another compliant H.323 endpoint a possibility? A4a (My position, with which I THINK you agree) No, on the grounds that if the gateway/IWF can find a gatekeeper and use it, so can the endpoint. A4b (Charles) Yes. This actually gives rise to a further question, which is (I believe) open, and probably shouldn't be: Q5. Can an endpoint be separated from its gatekeeper by a proxy? Regards, Chris Paul Long wrote: > > Chris, > > (You and I inadvertently replied to each other privately. I thought I'd > clean my email up a bit :-) and post it to the reflector.) > > As you point out, gatekeepers are optional, but an endpoint may not be > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > agree with you that an endpoint must implement and be able to use RAS. The > tricky part, though, is under what circumstances _shall_ an endpoint use > RAS, i.e., at least attempt to register with a gatekeeper. It may come down > to a rather philosophical question. If an endpoint is required to use RAS in > any way and ultimately discover and register with a gatekeeper only if there > is a gatekeeper in the "system," how does it know whether there is a > gatekeeper within the system without using RAS? Look like a Catch-22, but my > take on it is that whether a gatekeeper is in the system must be known out > of band. That's the only way I know of to resolve these otherwise > contradictory issues. > > Smith Micro builds endpoints that can be used in systems with and without > gatekeepers. Because this vendor does not know whether the system within > which the user will be deploying the endpoint contains a gatekeeper, the > user presumably knows and has the discretion as whether to use RAS via a > Preferences dialog in the user interface. I think that's reasonable and > compliant. Some vendors may build endpoints that are designed to always be > used within systems that contain gatekeepers, and that's fine, too, and > compliant. However, IMO, besides probably being a bad marketing decision > :-), an endpoint that does not support RAS at all is not compliant. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 7:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)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(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by Agboh, Charles 01 Dec '00

01 Dec '00

in A5, I meant GK in the last line. -charles -----Original Message----- From: Agboh, Charles Sent: Friday, December 01, 2000 12:27 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Chris, I am not a native English speaker (1/3), sorry for the mistake. I understand things better now. Consider the following scenario; A4: An enpoint A (first-party) is switch off or does not "speak" H.323 (it supports RAS). I (third-party. i.e. IWF ) may want to be able to register this endpoint which we will call EP A. I register this endpoint with its "well-known" alias address which is binded to a transport addresses (not the one this EP usually uses when it is turned on. i.e. transport address of an H.323 complaint device like an answering machine called AM). The GK will now be able to route the call for EP A to the AM. For the EP that does not "speak" H.323 the signaling will go to some entity that will be able to "speak" H.323 and bind the RAS context created by the IWF (this may be the IWF itself). A5: If I have a GK in my network, I may not allow "dubious" EPs to have direct access to my EP. Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Friday, December 01, 2000 10:31 AM To: Agboh, Charles Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Third party registration/group registration Charles, I'll take these two mails together, as the point is the same. H.225.0 section 7.7 states which RAS messages are mandatory, optional etc. for different H.323 devices. By mandating the support of these messages, it mandates the support of RAS, since there is no proviso there for "when the EP/entity is supporting RAS". An aside, from a famous UK 80s sitcom on the subject of "clarification": "You don't issue clarifications to MAKE things clear: you issue them to put you IN the clear." Regards, Chris -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 10:46 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Paul, I think we're starting to converge. Let's separate this out now, into separate questions: Q1. Are endpoint devices (in which term I include gateways etc throughout this mail) required to implement RAS? A1. Yes (agreed between you and me, disagreed by Charles). Q2. How does an endpoint device know whether or not a gatekeeper is present in the system, and hence whether or not to use RAS? A2a (Your position as I understand it.) Configuration, discovery on startup, give up if you don't find anything then. A2b (My suggestion) Configuration, discovery on startup, retry at some reasonable frequency (hourly?), take the three seconds to attempt gatekeeper discovery when someone makes a call to or from the endpoint in question. A2c (What we'll probably end up agreeing!) Implementation decision. Q3. What should an endpoint do if it attempts to register with all discovered gatekeepers, where there is at least one gatekeeper in the system, and fails (RRJ)? A3a (My position) Shut itself down. A3b (Anybody elses) ??? Q4. Is Charles's actual application, where one entity is registering and hence presumably (although he's consistently failed to clarify) handling RAS on behalf of another compliant H.323 endpoint a possibility? A4a (My position, with which I THINK you agree) No, on the grounds that if the gateway/IWF can find a gatekeeper and use it, so can the endpoint. A4b (Charles) Yes. This actually gives rise to a further question, which is (I believe) open, and probably shouldn't be: Q5. Can an endpoint be separated from its gatekeeper by a proxy? Regards, Chris Paul Long wrote: > > Chris, > > (You and I inadvertently replied to each other privately. I thought I'd > clean my email up a bit :-) and post it to the reflector.) > > As you point out, gatekeepers are optional, but an endpoint may not be > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > agree with you that an endpoint must implement and be able to use RAS. The > tricky part, though, is under what circumstances _shall_ an endpoint use > RAS, i.e., at least attempt to register with a gatekeeper. It may come down > to a rather philosophical question. If an endpoint is required to use RAS in > any way and ultimately discover and register with a gatekeeper only if there > is a gatekeeper in the "system," how does it know whether there is a > gatekeeper within the system without using RAS? Look like a Catch-22, but my > take on it is that whether a gatekeeper is in the system must be known out > of band. That's the only way I know of to resolve these otherwise > contradictory issues. > > Smith Micro builds endpoints that can be used in systems with and without > gatekeepers. Because this vendor does not know whether the system within > which the user will be deploying the endpoint contains a gatekeeper, the > user presumably knows and has the discretion as whether to use RAS via a > Preferences dialog in the user interface. I think that's reasonable and > compliant. Some vendors may build endpoints that are designed to always be > used within systems that contain gatekeepers, and that's fine, too, and > compliant. However, IMO, besides probably being a bad marketing decision > :-), an endpoint that does not support RAS at all is not compliant. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 7:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)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(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 01 Dec '00

01 Dec '00

Hi Roy, Chris; RAS is RECOMMENDED. It is NOT MANDATORY (hence optional) whether the sigalals are incoming or outgoing. Please, just indicate where in H.323 RAS is mandated. Regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Thursday, November 30, 2000 6:33 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Hi, Chris: Yes, I do. Regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, November 30, 2000 12:01 PM To: ITU-SG16(a)mailbag.cps.intel.com Cc: Roy, Radhika R, ALCOO Subject: Re: Third party registration/group registration All, A clarification: I am sure Radhika will agree that when he refers to call setup this includes the case of incoming call setup as well as that of outgoing call setup! Regards, Chris "Roy, Radhika R, ALCOO" wrote: > > Hi, All: > > Let me add a little. > > An H.323 entity needs to have the capability to support RAS messages. > However, whether the RAS messages will be used or not before the call setup > is up to that entity. > > Best regards, > Radhika > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 8:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > "Agboh, Charles" wrote: > > > > Chris, > > > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 12:49 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > > The answer to your first question depends on the capabilities of D. > > > RAS is OPTIONAL so I could have a D device that does not implement RAS. > > > In my last email, the "third-party" would be a C device and > "first-party" > > > would be a D device (second-party is the A device) . > > RUBBISH! > > RAS is NOT optional. See Table 18/H.225.0. > > Besides, how would your crippled H.323 endpoint tell its RAS handler to > send > > the various RAS messages (like for instance ARQ to ask permission to make > a > > call...)? > > > > Regards, > > Chris > > > > > > > > Regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > > Sent: Thursday, November 30, 2000 10:43 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > In your definition of "third-party" registration, consider a scenario > > > involving > > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > > gateway/IWF/registering-entity (C) and an entity of some sort on whose > > > behalf C > > > is registering (which we'll call D). Assuming that B is not routing > > > call-signalling, to which entity would A send its "Setup" message in > order > > > to > > > contact D? > > > > > > If the answer to this question is "C", this is well-covered in the > > standard > > > - > > > it is simply that the term "third-party registration" is not used for > it. > > > It > > > is simply viewed as C registering (potentially) lots of aliases. This > > > parallels Tom's second case. > > > If the answer is "D" (parallelling Tom's first case), then D is a very > odd > > > device (it can't be a full H.323 implementation or it would register for > > > itself). Why have a device implementing all of H.323 except gatekeeper > > > registration? After all, D would have to handle all the rest of RAS for > > > itself > > > - what would it be gaining by not registering on its own behalf? > > > > > > In the same scenario, to what entities are you referring, respectively, > as > > > the > > > "third-party" in your latest contribution? > > > > > > PLEASE clarify your definitions of "first-party" and "third-party" in > > cases > > > where you use these terms. I am certain that the ends you are trying to > > > achieve are perfectly possible - and not even that hard. Either will > > > result, I > > > believe, in a brief discussion with early consensus emerging. I believe > > the > > > problems, and the large amount of mail this is generating on this list, > > come > > > about entirely from the use of these terms without anyone understanding > > > exactly > > > what is meant by them. > > > > > > I agree with Tom that once we can agree on terminology we can move on > > quite > > > easily, and thank him for his usual high-quality clear-sighted input. > > > > > > Regards, > > > Chris > > > > > > ------------------------------------ > > > > > > The registration feature allows endpoints to bind their identities to > > > transport > > > address(es) at the GK. This is well described in H.323. When an > > endpoint > > > delegates another endpoint to perform this fearture on its behalf the > > > definition in H.323 is not there. The signaling that follows the > > > registration > > > whether, its > > > first or third-party may interrogate this binding. The third-party > > > registration feature can enhance the user experience much more than a > > normal > > > first-party > > > registration. I don't believe that the third-party has to be in the > > > signaling > > > flow that may follow the third-registration. I agree with Tom-PTs > view. > > > > > > Best regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > > Sent: Wednesday, November 29, 2000 7:39 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Accurate terminology is obviously useful, but in this case, at > least, > > it > > > looks like something people can agree on and then move on. The more > > > important point seems to be the underlying distinction in > > requirements: > > > > > > -- register on behalf of H.323 endpoints > > > -- register on behalf of other endpoints > > > where I use "other" in the sense that the contact address is > > associated > > > with a non-H.323 signalling protocol. Purity is beside the point here > -- > > > it's the intention of the contact address that matters. Stating the > > > requirement in this way makes it obvious that the second requirement > > > includes > > > the need to state which protocol the endpoints expects to receive. > > > > > > There is another possibility, of course: use the same mechanism to > > > satisfy > > > all requirements, and allow for the possibility that the endpoint > > > supports multiple protocols. I think the design would be cleaner if > > we > > > took the approach: one contact point, one protocol -- even if it meant > > > repeating the contact information for each protocol a multiprotocol > > > endpoint supports. > > > > > > -- > > > 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(a)mailbag.intel.com > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)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(a)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(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)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(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1