Hi Roy;
What ever you do, don't mention S*P for now. We are trying to keep the third party registration feature in the H.323 realm. The examples about the secretary and her boss won't work with Chr*s because (i think), if the secretary and boss are both H.323 complaint then they should be able to register themselves (I disagree with this). In the case of the IWF (s*p-h323) this is not true.
The real question for now is, what value will 3rd-party registration bring to an H.323 network. Once we have determined this, then we can proceed to agree on a good definition. Then, we can move onto how to define the procedure in H.323 (IE). Based on the definition, the third-party may or may not actively remain in the call (he may receive call progress information,...). H.323 proxy is an example of an H.323 entity that may not be fully complaint but still remains actively in the call.
I have given some examples about the value of third-party registration but I am told that the value of those examples can be achieved with static GK configuration. I think it may be useful in some roaming scenarios (H.323 annex H). There is also the example of the fully complaint decomposed endpoint (for administative reasons).
Best Regards,
charles
-----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Friday, December 15, 2000 6:12 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Hi, Chris and Charles:
I guess that the third party registration will be helpful in a situation where the first does not want to do this job and may want to delegate this to the third party (e.g., secretary). Another situation can be that an IWF is registering many entities on behalf of many endpoints and the IWF does not want to be a party anymore once the registration is done.
Let us define the requirements of the third party registration as follows:
1. The third party wants to register the first party. 2. The third party shall not be any party once the registration is done. That is, any information related to the first party needs to be obtained from other sources once the registration is done by the third party.
Based on the above two criteria, let us see what needs to be done in H.323 to perform the third party registration.
Hope this helps.
Best regards, Radhika
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 15, 2000 4:38 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Charles,
Ref your "some value": I would bring this down to configuration of the gatekeeper. You could have/configure/write!? a gatekeeper which has "default registrations" - calls for known people go by default to an answering machine unless that individual is actually registered. What I don't understand is how "third-party registration" helps - you're missing out too many steps in your explanation!
Regards, Chris
"Agboh, Charles" wrote:
That is a good questions. I would say this;
3rd party registration is when; The target endpoint (called party ) may
not
be the Registering Entity (IWF/BE) based on the binding between alias and transport address; AND the entity receving the RRQ is aware that this is a 3rd-party RRQ ( a registers b).
This needs to be clearly defined but before that we must be sure there is value in defining 3rd party registration (like third party call control: GK-initiated call control (re-routing...))
some value:
- In this case I do not have to hunt for a "line" at the GK (so at the
GK, I would know that a call was for a registered EP b (registered by registering entity a) and send the call to the transport address which b's alias is binded to (called party is b's alias address); which may be a's transport address depending on the time). With the alternateEndpoint structure, I would reach b only after hunting.
Best regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Tuesday, December 12, 2000 9:52 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
I guess that it is a good observation by Bob. It can be thought a "kind"
of
third party activities. However, a BE becomes a "party" in this process because people have now have a place to go to have the information. And
that
place is the BEs themselves.
So the basic question remains: What is the basic definition of the "third" party registration in H.323?
Thanks Bob for his important observation.
Best regards, Radhika
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, December 12, 2000 3:41 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
I might interject that H.225.0 Annex G can be thought of as a form of
Third
Party registration. This protocol allows a Border Element (or Gatekeeper) to registers its endpoints with other Border Elements (or Gatekeepers).
I do not know is this adds to the discussion, or not.
Bob
Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan@ICN.Siemens.com
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
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com