Re: Third party registration/group registration
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@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@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
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
down 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@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@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
Francois, GCF from a gatekeeper certainly does NOT guarantee that the following registration will be permitted. A gatekeeper may allow an endpoint to attempt to register and then refuse the registration for any reason. However, from the point of view of my position on Q3, GRQ-GRJ should be treated the same as GRQ-GCF-RRQ-RRJ in my view. Regards, Chris BOUGANT François FTRD/DAC/ISS wrote:
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@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@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
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
down 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@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@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
participants (2)
-
BOUGANT Fran�ois FTRD/DAC/ISS -
Chris Wayman Purvis