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.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

-- 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