Re: Third party registration/group registration
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@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@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@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 tosatisfy 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@mailbag.intel.comFor 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
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@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@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@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 isassociated
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 tosatisfy 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@mailbag.intel.comFor 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
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@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
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@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
Chris,
Gettin' closer.
Re Q2: I simply can't justify making the user wait several seconds for a discovery that will always fail in a system without a gatekeeper before he or she can place or answer each and every call. Can you? Therefore, the user should be able to turn off RAS.
Re Q3: I agree with you, except that with some endpoints the user may then turn off RAS and place or answer calls without RAS. Note that the typical user will most likely not do this, since at least placing a call without a gatekeeper would require more knowledge than the average user posseses, e.g., the IP address of the called party.
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there is something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that is acting "as if" it were a corporate entity, it is compliant IMO. Who cares where messages originate as long as the effect is the same? In a different way, the "as if" rule is what allows routing gatekeepers to do what they do--they can fiddle with messages streams all they want as long as they maintain consistency "as if" the message streams were originating from a compliant endpoint.
Note that when I say, "user," I mean either the actual user of the endpoint or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Paul Long ipDialog, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 3:46 AM To: ITU-SG16@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Chris,
Oh, yeah, one other thing. Decomposition like this (unlike H.248) is totally proprietary and any one subcomponent of the decomposed entity may not be complaint. In particular, an EP which relies on another entity, e.g., IWF, for RAS is not compliant by itself, but the composite EP functionality of the EP+IWF(RAS) is compliant.
Paul Long ipDialog, Inc.
-----Original Message----- From: Paul Long [mailto:plong@packetizer.com] Sent: Friday, December 01, 2000 7:31 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Chris,
Gettin' closer.
Re Q2: I simply can't justify making the user wait several seconds for a discovery that will always fail in a system without a gatekeeper before he or she can place or answer each and every call. Can you? Therefore, the user should be able to turn off RAS.
Re Q3: I agree with you, except that with some endpoints the user may then turn off RAS and place or answer calls without RAS. Note that the typical user will most likely not do this, since at least placing a call without a gatekeeper would require more knowledge than the average user posseses, e.g., the IP address of the called party.
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there is something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that is acting "as if" it were a corporate entity, it is compliant IMO. Who cares where messages originate as long as the effect is the same? In a different way, the "as if" rule is what allows routing gatekeepers to do what they do--they can fiddle with messages streams all they want as long as they maintain consistency "as if" the message streams were originating from a compliant endpoint.
Note that when I say, "user," I mean either the actual user of the endpoint or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Paul Long ipDialog, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
Gettin' closer.
I think (and hope!) so!
Re Q2: I simply can't justify making the user wait several seconds for a discovery that will always fail in a system without a gatekeeper before he or she can place or answer each and every call. Can you? Therefore, the user should be able to turn off RAS.
So you'll agree on answer c then? What about regular reattempts to find a gatekeeper (excluding my suggestion of when a call is attempted).
Re Q3: I agree with you, except that with some endpoints the user may then turn off RAS and place or answer calls without RAS. Note that the typical user will most likely not do this, since at least placing a call without a gatekeeper would require more knowledge than the average user posseses, e.g., the IP address of the called party.
This is where I disagree, on the grounds that if we allow calls in systems with gatekeepers from endpoints that are not registered, we may as well throw away the gatekeeper altogether (or at least call it a proxy and start speaking SIP).
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there is something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that is acting "as if" it were a corporate entity, it is compliant IMO. Who cares where messages originate as long as the effect is the same? In a different way, the "as if" rule is what allows routing gatekeepers to do what they do--they can fiddle with messages streams all they want as long as they maintain consistency "as if" the message streams were originating from a compliant endpoint.
Surely if the "as if" rule applies there can be no requirement for any changes to the standard - otherwise it isn't "as if"! I grant the possibility of the decomposed endpoint, although I don't personally understand why anyone would want to, as the communication between the decomposed parts would be at least as complicated as RAS itself.
Note that when I say, "user," I mean either the actual user of the endpoint or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Agreed.
Regards, Chris
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 3:46 AM To: ITU-SG16@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
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
Chris,
Re Re Q2: Yes, I agree with A2c, but I see no point in wasting _any_ bandwidth for RAS on a system that does not contain a gatekeeper.
Re Re Q3: I think we understand each other and that we'll just have to agree to disagree on this. It's up to the implementation and ultimately the market to decide whether the user may disable RAS.
Re Re Q4: Correct, if something behaves "as if" it were compliant then I suppose it is, well... compliant. :-) No change is necessary to the Recommendations.
Paul Long ipDialog, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 8:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Paul,
Gettin' closer.
I think (and hope!) so!
Re Q2: I simply can't justify making the user wait several seconds for a discovery that will always fail in a system without a gatekeeper before he or she can place or answer each and every call. Can you? Therefore, the
user
should be able to turn off RAS.
So you'll agree on answer c then? What about regular reattempts to find a gatekeeper (excluding my suggestion of when a call is attempted).
Re Q3: I agree with you, except that with some endpoints the user may then turn off RAS and place or answer calls without RAS. Note that the typical user will most likely not do this, since at least placing a call without a gatekeeper would require more knowledge than the average user posseses, e.g., the IP address of the called party.
This is where I disagree, on the grounds that if we allow calls in systems with gatekeepers from endpoints that are not registered, we may as well throw away the gatekeeper altogether (or at least call it a proxy and start speaking SIP).
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there is something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that is acting "as if" it were a corporate entity, it is compliant IMO. Who cares where messages originate as long as the effect is the same? In a different way, the "as if" rule is what allows routing gatekeepers to do what they do--they can fiddle with messages streams all they want as long as they maintain consistency "as if" the message streams were originating from a compliant endpoint.
Surely if the "as if" rule applies there can be no requirement for any changes to the standard - otherwise it isn't "as if"! I grant the possibility of the decomposed endpoint, although I don't personally understand why anyone would want to, as the communication between the decomposed parts would be at least as complicated as RAS itself.
Note that when I say, "user," I mean either the actual user of the
endpoint
or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Agreed.
Regards, Chris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
All,
I think on the matter of whether the standards permit H.323 entities to continue to operate unregistered in an environment where there is a gatekeeper, in two cases: 1. They have discovered the gatekeeper, but have been rejected by either GRJ or RRJ. 2. No attempt has been made to discover a gatekeeper.
I have a view. Paul Long has a view. I have a different view. These differ. I believe, however, that whichever view prevails, one must, and this must be through the standards themselves. Common usage can not decide this, as it's a question of whether something is permitted by the standard. I could draw up a very quick proposal (<= 1/2 page) for the next ITU meeting, but I will not be able to come and present it. To help the experts at the meeting to come to the right decision, however, opposing proposals probably ought to be presented properly by their authors, giving the two viewpoints. Any volunteers (Rick? Paul J? As editors of the relevant standards?)?
Regards, Chris
Paul Long wrote:
Chris,
Re Re Q2: Yes, I agree with A2c, but I see no point in wasting _any_ bandwidth for RAS on a system that does not contain a gatekeeper.
Re Re Q3: I think we understand each other and that we'll just have to agree to disagree on this. It's up to the implementation and ultimately the market to decide whether the user may disable RAS.
Re Re Q4: Correct, if something behaves "as if" it were compliant then I suppose it is, well... compliant. :-) No change is necessary to the Recommendations.
Paul Long ipDialog, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 8:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Paul,
Gettin' closer.
I think (and hope!) so!
Re Q2: I simply can't justify making the user wait several seconds for a discovery that will always fail in a system without a gatekeeper before he or she can place or answer each and every call. Can you? Therefore, the
user
should be able to turn off RAS.
So you'll agree on answer c then? What about regular reattempts to find a gatekeeper (excluding my suggestion of when a call is attempted).
Re Q3: I agree with you, except that with some endpoints the user may then turn off RAS and place or answer calls without RAS. Note that the typical user will most likely not do this, since at least placing a call without a gatekeeper would require more knowledge than the average user posseses, e.g., the IP address of the called party.
This is where I disagree, on the grounds that if we allow calls in systems with gatekeepers from endpoints that are not registered, we may as well throw away the gatekeeper altogether (or at least call it a proxy and start speaking SIP).
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there is something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that is acting "as if" it were a corporate entity, it is compliant IMO. Who cares where messages originate as long as the effect is the same? In a different way, the "as if" rule is what allows routing gatekeepers to do what they do--they can fiddle with messages streams all they want as long as they maintain consistency "as if" the message streams were originating from a compliant endpoint.
Surely if the "as if" rule applies there can be no requirement for any changes to the standard - otherwise it isn't "as if"! I grant the possibility of the decomposed endpoint, although I don't personally understand why anyone would want to, as the communication between the decomposed parts would be at least as complicated as RAS itself.
Note that when I say, "user," I mean either the actual user of the
endpoint
or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Agreed.
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
Chris,
I'll be happy to present anything. Can't say that I will defend anything, but I'll present it :-)
I missed much of the discussion, so if you wouldn't mind, will you write an e-mail me summarizing the two opposing opinions?
Thanks, Paul
----- Original Message ----- From: "Chris Wayman Purvis" cwp@isdn-comms.co.uk To: plong@ipdialog.com; ITU-SG16@mailbag.cps.intel.com; "Paul Jones" paul.jones@ties.itu.ch; rkbowen@cisco.com Sent: Friday, December 01, 2000 11:57 AM Subject: Re: Third party registration/group registration
All,
I think on the matter of whether the standards permit H.323 entities to continue to operate unregistered in an environment where there is a
gatekeeper,
in two cases:
- They have discovered the gatekeeper, but have been rejected by either
GRJ or
RRJ. 2. No attempt has been made to discover a gatekeeper.
I have a view. Paul Long has a view. I have a different view. These
differ.
I believe, however, that whichever view prevails, one must, and this must
be
through the standards themselves. Common usage can not decide this, as
it's a
question of whether something is permitted by the standard. I could draw
up a
very quick proposal (<= 1/2 page) for the next ITU meeting, but I will not
be
able to come and present it. To help the experts at the meeting to come
to
the right decision, however, opposing proposals probably ought to be
presented
properly by their authors, giving the two viewpoints. Any volunteers
(Rick?
Paul J? As editors of the relevant standards?)?
Regards, Chris
Paul Long wrote:
Chris,
Re Re Q2: Yes, I agree with A2c, but I see no point in wasting _any_ bandwidth for RAS on a system that does not contain a gatekeeper.
Re Re Q3: I think we understand each other and that we'll just have to
agree
to disagree on this. It's up to the implementation and ultimately the
market
to decide whether the user may disable RAS.
Re Re Q4: Correct, if something behaves "as if" it were compliant then I suppose it is, well... compliant. :-) No change is necessary to the Recommendations.
Paul Long ipDialog, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 8:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Paul,
Gettin' closer.
I think (and hope!) so!
Re Q2: I simply can't justify making the user wait several seconds for
a
discovery that will always fail in a system without a gatekeeper
before he
or she can place or answer each and every call. Can you? Therefore,
the
user
should be able to turn off RAS.
So you'll agree on answer c then? What about regular reattempts to find a gatekeeper (excluding my
suggestion
of when a call is attempted).
Re Q3: I agree with you, except that with some endpoints the user may
then
turn off RAS and place or answer calls without RAS. Note that the
typical
user will most likely not do this, since at least placing a call
without a
gatekeeper would require more knowledge than the average user
posseses,
e.g., the IP address of the called party.
This is where I disagree, on the grounds that if we allow calls in
systems
with gatekeepers from endpoints that are not registered, we may as well throw away the gatekeeper altogether (or at least call it a proxy and start
speaking
SIP).
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there
is
something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that
is
acting "as if" it were a corporate entity, it is compliant IMO. Who
cares
where messages originate as long as the effect is the same? In a
different
way, the "as if" rule is what allows routing gatekeepers to do what
they
do--they can fiddle with messages streams all they want as long as
they
maintain consistency "as if" the message streams were originating from
a
compliant endpoint.
Surely if the "as if" rule applies there can be no requirement for any changes to the standard - otherwise it isn't "as if"! I grant the possibility of the decomposed endpoint, although I don't personally understand why anyone would want to, as the communication between the decomposed parts would be at least as complicated as RAS itself.
Note that when I say, "user," I mean either the actual user of the
endpoint
or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Agreed.
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
Paul,
I'll be happy to present anything. Can't say that I will defend anything, but I'll present it :-)
Past experience shows that on complex issues this simply is not sufficient - there will be too many people who don't understand, hence fear, hence (if it ever comes to a vote) oppose any proposal in either camp. So, realistically, nothing will result. Not that I don't understand that you have plenty else to do at these meetings!
I missed much of the discussion, so if you wouldn't mind, will you write an e-mail me summarizing the two opposing opinions?
There are a three questions I can identify in this discussion. Note that the answers I give with initials CWP by them are mine, PL are Paul Long's views as I understand them, CA are Charles Agboh's views as I understand them. If I have misunderstood the views of either of these people I apologise and would be obliged if they would clarify their positions. I am not intending to misrepresent anybody, but I may have inadvertently done so!
Q1. Is a device permitted to call itself H.323 if it does not support RAS (or can be configured not to use RAS)? A1a (CWP). No, on the grounds that certain RAS messages are mandatory for devices to support (H.225.0 section 7.7) A1b (CA, PL). Yes, on the grounds that gatekeepers are an optional part of an H.323 system.
Assume RAS is being supported in a particular "system" (without prejudging the answer to Q1), and we come to the other question: Q2. If an endpoint has attempted gatekeeper discover and/or registration, and been rejected (GRJ or RRJ) by all gatekeepers it has found (this being at least one gatekeeper), is the endpoint permitted to make and receive H.323 calls? A2a (CWP). No, on the grounds that there is a gatekeeper in control of this system, and it has denied access. Also on grounds of common sense (ARJ makes no sense if an endpoint may deregister and then make the call it's been refused). A2b (PL). Yes, presumably on grounds of restrictiveness.
Q3. Should third-party registration be standardised? A3a (CA). Yes. A3b (CWP). Possibly, but before this can be answered a LOT of clarification is required on what is meant by the term "third-party".
Regards, Chris
----- Original Message ----- From: "Chris Wayman Purvis" cwp@isdn-comms.co.uk To: plong@ipdialog.com; ITU-SG16@mailbag.cps.intel.com; "Paul Jones" paul.jones@ties.itu.ch; rkbowen@cisco.com Sent: Friday, December 01, 2000 11:57 AM Subject: Re: Third party registration/group registration
All,
I think on the matter of whether the standards permit H.323 entities to continue to operate unregistered in an environment where there is a
gatekeeper,
in two cases:
- They have discovered the gatekeeper, but have been rejected by either
GRJ or
RRJ. 2. No attempt has been made to discover a gatekeeper.
I have a view. Paul Long has a view. I have a different view. These
differ.
I believe, however, that whichever view prevails, one must, and this must
be
through the standards themselves. Common usage can not decide this, as
it's a
question of whether something is permitted by the standard. I could draw
up a
very quick proposal (<= 1/2 page) for the next ITU meeting, but I will not
be
able to come and present it. To help the experts at the meeting to come
to
the right decision, however, opposing proposals probably ought to be
presented
properly by their authors, giving the two viewpoints. Any volunteers
(Rick?
Paul J? As editors of the relevant standards?)?
Regards, Chris
Paul Long wrote:
Chris,
Re Re Q2: Yes, I agree with A2c, but I see no point in wasting _any_ bandwidth for RAS on a system that does not contain a gatekeeper.
Re Re Q3: I think we understand each other and that we'll just have to
agree
to disagree on this. It's up to the implementation and ultimately the
market
to decide whether the user may disable RAS.
Re Re Q4: Correct, if something behaves "as if" it were compliant then I suppose it is, well... compliant. :-) No change is necessary to the Recommendations.
Paul Long ipDialog, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 8:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Paul,
Gettin' closer.
I think (and hope!) so!
Re Q2: I simply can't justify making the user wait several seconds for
a
discovery that will always fail in a system without a gatekeeper
before he
or she can place or answer each and every call. Can you? Therefore,
the
user
should be able to turn off RAS.
So you'll agree on answer c then? What about regular reattempts to find a gatekeeper (excluding my
suggestion
of when a call is attempted).
Re Q3: I agree with you, except that with some endpoints the user may
then
turn off RAS and place or answer calls without RAS. Note that the
typical
user will most likely not do this, since at least placing a call
without a
gatekeeper would require more knowledge than the average user
posseses,
e.g., the IP address of the called party.
This is where I disagree, on the grounds that if we allow calls in
systems
with gatekeepers from endpoints that are not registered, we may as well throw away the gatekeeper altogether (or at least call it a proxy and start
speaking
SIP).
Re Q4: Maybe he has decomposed his endpoint. In the C Standard, there
is
something called the "as if" rule. Applying it here, if the system experiences consistent behavior from a possibly decomposed entity that
is
acting "as if" it were a corporate entity, it is compliant IMO. Who
cares
where messages originate as long as the effect is the same? In a
different
way, the "as if" rule is what allows routing gatekeepers to do what
they
do--they can fiddle with messages streams all they want as long as
they
maintain consistency "as if" the message streams were originating from
a
compliant endpoint.
Surely if the "as if" rule applies there can be no requirement for any changes to the standard - otherwise it isn't "as if"! I grant the possibility of the decomposed endpoint, although I don't personally understand why anyone would want to, as the communication between the decomposed parts would be at least as complicated as RAS itself.
Note that when I say, "user," I mean either the actual user of the
endpoint
or possibly an administrator of the system. I think it's perfectly reasonable to make the use of RAS an administrated setting.
Agreed.
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
Chris,
Here are my opinions:
Q1. Is a device permitted to call itself H.323 if it does not support RAS
(or
can be configured not to use RAS)? A1a (CWP). No, on the grounds that certain RAS messages are mandatory for devices to support (H.225.0 section 7.7) A1b (CA, PL). Yes, on the grounds that gatekeepers are an optional part of
an
H.323 system.
I agree with CWP on this issue. 7.2.2/H.323 states: As part of their configuration process, all endpoints shall register with the Gatekeeper identified through the discovery process.
This means that they must be pre-configured with a GK or must perform automatic discover-- i.e., they must support RAS. It is acceptable for an endpoint to continue operation of no Gatekeeper is found or if the Gatekeeper(s) reject the registration requests. The last paragraph of 7.2.2 is there to indicate that an endpoint may continue in such a manner-- it is just considered "unregistered".
Assume RAS is being supported in a particular "system" (without prejudging
the
answer to Q1), and we come to the other question: Q2. If an endpoint has attempted gatekeeper discover and/or registration,
and
been rejected (GRJ or RRJ) by all gatekeepers it has found (this being at
least
one gatekeeper), is the endpoint permitted to make and receive H.323
calls?
A2a (CWP). No, on the grounds that there is a gatekeeper in control of
this
system, and it has denied access. Also on grounds of common sense (ARJ
makes
no sense if an endpoint may deregister and then make the call it's been refused). A2b (PL). Yes, presumably on grounds of restrictiveness.
I asked this question of the original H.323 designers. The correct answer is PL's interpretation. As noted above, the last paragraph of 7.2.2 was there for this reason, but I'll admit it could be clarified a bit.
Q3. Should third-party registration be standardised? A3a (CA). Yes. A3b (CWP). Possibly, but before this can be answered a LOT of
clarification is
required on what is meant by the term "third-party".
I have my idea about what a 3rd party is, but it may differ from others' opinions.
A gateway could certainly register an address that could be used to reach said 3rd party, but it's not really registering on behalf of the 3rd party-- it's acting as a gateway to that entity.
I suppose one could build a device that does register on behalf of H.323 endpoints. Perhaps the endpoints communicate with this entity in a proprietary manner and allow it to perform the RAS functions for the endpoint. I don't see a lot of value in such a scheme, because the proprietary protocol would simply be doing what RAS does.
Now, I have seen some endpoints which do not support RAS and Gatekeepers that allow static entries to be made in order to accommodate them. I suppose that's a "3rd party" registration-- but then, it's also done because the endpoints are not compliant.
What would be the benefit of 3rd party registration? (Keep in mind that a GW that can reach the 3rd parties can register the appropriate aliases, but it's not really "3rd party registration" in my opinion.)
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Chris,
I personally don't think this is something that needs to be in the Recommendation. Interoperability won't be helped either way.
Paul Long ipDialog, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Friday, December 01, 2000 10:58 AM To: plong@ipdialog.com; ITU-SG16@mailbag.cps.intel.com; Paul Jones; rkbowen@cisco.com Subject: Re: Third party registration/group registration
All,
I think on the matter of whether the standards permit H.323 entities to continue to operate unregistered in an environment where there is a gatekeeper, in two cases: 1. They have discovered the gatekeeper, but have been rejected by either GRJ or RRJ. 2. No attempt has been made to discover a gatekeeper.
I have a view. Paul Long has a view. I have a different view. These differ. I believe, however, that whichever view prevails, one must, and this must be through the standards themselves. Common usage can not decide this, as it's a question of whether something is permitted by the standard. I could draw up a very quick proposal (<= 1/2 page) for the next ITU meeting, but I will not be able to come and present it. To help the experts at the meeting to come to the right decision, however, opposing proposals probably ought to be presented properly by their authors, giving the two viewpoints. Any volunteers (Rick? Paul J? As editors of the relevant standards?)?
Regards, Chris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (5)
-
Agboh, Charles -
Chris Wayman Purvis -
Chris Wayman Purvis
-
Paul E. Jones -
Paul Long