Re: Third party registration/group registration
Folks: It may not be easy to standardize something in H.323 with respect to the "Third Party." There are some situations where the role of the third party is useful. However, the standardization criteria will depend what the functions are and what the role to be played by the third party. Let us consider two cases: 1. Third party registration 2. Third party call control I have already mentioned some points with respect to "Third Party" REGISTRATION. In this case, the third party, for example - my secretary will register me for the meeting, will have no role as soon as the registration is done. This may be a little difficult task in H.323 (although it is very simple in SIP). (My guess is that we may be surprised to see that we may have to decompose the H.323 functional entities to have this kind of flexibility.) Now, can we say the same for the third party call control? The points that I am making are as follows: 1. Let us define the necessary functions (i.e., requirements) and the criteria (e.g., roles, etc.) that need to be performed by the third party. 2. Then translate those functions and criteria in H.323 signaling messages (if we can). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM] Sent: Thursday, December 07, 2000 11:00 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Chris Some applicaitons of third-party registration -secretary mode, where the secretary registers the current location (e.g., tel:) for his boss; - voicemail, where the voicemail system registers itself as a branch location regards, charles -----Original Message----- From: Agboh, Charles Sent: Thursday, December 07, 2000 3:57 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Chris, Some ideas about why I think this could be a useful feature..... It is the concept of third-party registration that I believe is not clearly (if at all) specified in H.323. "In third-party registration, the entity issuing the request is different from the entity being registered." This is not equivalent to hunting down the list of alternateEnpoints for an Endpoint I am trying to reach. The key to this is who is requesting the binding between an alias address and a transport address. The entity making the request is using resources of the GK. The GK may view the entity that is being registered as a client of the entiry that made the request and may send CDRs correlating the three parties entities. The 3rd-party (as paul called it: the entity making the request) may be charged for using the GKs resources. Even though my friend bob has an H.323 complaint EP that is capable of registering itself, I (3rd-party: as paul called it) can register bobs alias at my GK and my GK will send CDRs to me at the end of *our* conference. Bob may inheret some of my priveleges as a result of my action. I don't have all the possible applications of this feature on my radar. Best regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Monday, December 04, 2000 2:26 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles,
I said that the "....H.323 EP must support RAS...". We are down to the case where the H.323 EP user has disabled RAS. I would argue that this means that the endpoint is not supporting RAS, and has become uncompliant...
Is it useful to have this feature (third-party registration) for this specific case? Its not defined in the standard and I think it should be (i.e. From Pauls view, it could be useful for administrative reasons ); although there are ways to provide this feature in H.323v2 and H.323v4. Please expand on why you think it's a useful feature, and what you think is required for it. I don't understand what you feel you need beyond what's already there. If you are acting as a gateway/IWF then you are handling all call signalling, and the registration is not third-party. If you are doing Paul's "as if" case then it isn't "as if" if it requires any modifications to the standard. If you wish to do anything else, you need to tell us WHAT as I for one don't understand what you're trying to achieve (and calling "third-party registration") that doesn't come under the above headings.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Monday, December 04, 2000 11:01 AM To: Agboh, Charles Cc: ITU-SG16@mailbag.cps.intel.com Subject: Re: Third party registration/group registration
Charles,
By H.323 EP, I mean an H.323 EP that must support RAS (by your interpretation of the standard), but the RAS function can be disabled by the user (Pauls views ). The GK is an optional H.323 entity. I repeat that "The GK is an optional H.323 entity" does NOT imply "RAS is optional in an endpoint".
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. A4b Yes, the H.323 EP user may have disabled RAS or the H.323 EP is turned off (i.e. SIP EP). These are two complete separate cases. We were discussing only the (disputed) case that the H.323 EP user has disabled RAS. If the H.323 endpoint is turned off and a SIP endpoint is being used, the gateway is handling ALL H.323 call signalling on behalf of the SIP endpoint. In other words the gateway is terminating H.323 call signalling and, as far as H.323 is concerned, IS
endpoint. Or, to put it yet another way, the same device is handling RAS as is handling all other call signalling.
Regards, Chris
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 3:36 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Charles,
I am not a native English speaker (1/3), sorry for the mistake. I understand things better now. I think we're getting closer now. Don't worry about not being a native English speaker - please persevere. I apologise if I've sometimes sounded harsh in my responses - it's normally because I'm trying to make points quickly! I know communicating in a foreign language is hard - which is precisely why it's important to make sure that nomenclature is clear and unambiguous!
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.
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).
Ah! This is a COMPLETELY different scenario from that I was describing! This is simple. All you are doing here is registering an alias somewhere different from what you may consider its "usual home". The key to thinking about this is that aliases are just that - they may only bind to particular devices for defined periods of time (the same user may use different endpoints on different days, but retain the same phone number). The practicalities between IWF and the "transport address this endpoint uses when it is turned on" may get somewhat hairy and certainly outside the remit of H.323, when it comes to ensuring that you don't have multiple devices trying to use the same alias in the same zone simultaneously (sadly not permitted).
A5: If I have a GK in my network, I may not allow "dubious" EPs to have direct access to my GK. <misprint corrected> True, but not addressing the question. The question is whether it is permitted to separate EP and GK with a proxy. I don't know the answer to this one!
Regards, Chris
-----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@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@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
Regards, Chris the transport that
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
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
I'd 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,
if 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
> >
> > --
> > Dr Chris Purvis -- Development Manager
> > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > Winkfield Row, Berkshire. RG42 6LY ENGLAND
> > Phone: +44 1344 899 007
> > Fax: +44 1344 899 001
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv@mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv@mailbag.intel.com
>
> --
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire. RG42 6LY ENGLAND
> Phone: +44 1344 899 007
> Fax: +44 1344 899 001
--
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND
Phone: +44 1344 899 007
Fax: +44 1344 899 001
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (1)
-
Roy, Radhika R, ALCOO