Third party registration/group registration

Roy, Radhika R, ALCOO rrroy at ATT.COM
Mon Dec 18 12:28:06 EST 2000


Hi, Charles:

Yes, if the objectives are satisfied somehow, we do not need to do any
especial standard works just for the "Third Party." We will see as you go
down the road.

I have just explained the things how we should analyze the problem.

Best regards,
Radhika

-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh at gts.com]
Sent: Monday, December 18, 2000 11:28 AM
To: Roy, Radhika R, ALCOO; ITU-SG16 at MAILBAG.INTEL.COM
Subject: RE: Third party registration/group registration


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 at ATT.COM]
Sent: Friday, December 15, 2000 6:12 PM
To: ITU-SG16 at 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 at ISDN-COMMS.CO.UK]
Sent: Friday, December 15, 2000 4:38 AM
To: ITU-SG16 at 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 at ATT.COM]
> Sent: Tuesday, December 12, 2000 9:52 PM
> To: ITU-SG16 at 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 at ICN.SIEMENS.COM]
> Sent: Tuesday, December 12, 2000 3:41 PM
> To: ITU-SG16 at 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 at ICN.Siemens.com
> -----------------------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at 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 at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list