1. EP S powers up (disabled RAS/not H.323 EP/....)
2. Registering Entity R is notified that EP is up (proprietary/standard)
3. Registering Entity R Registers EP S at GK G
*4. Based on the defined third-party registration procedure, GK G is AWARE
that EP S was registered by Registering entity R. GK G can exploit this
feature
5. EP H sends an ARQ to GK G to call EP S
6. GK G (in DRC mode) confirms with an ACF.
7. EP H sends a setup message to EP S. In the case of theIWF, the setup
message is sent to Registering entity R but, step for is still applicable at
GK G.
Two cases.
If EP H sends setup to registering entity R, this is handled perfectly
adequately by the standard. No alteration to the standard is required.
If EP H sends setup to EP S, this IS what I would understand by third-party
registration. If EP S and registering entity R can not arrange to appear to
the gatekeeper to be a single entity ("as if", in the sense described by Paul
Long), more additions need to be made to the standard. However I am dubious of
this. I would suggest that interactions between R and S are in some sense
internal to an endpoint, and not suitable for standardisation (in the way that
a decomposed gateway has been considered suitable for standardisation). Others
may disagree. Given that you do so, I would suggest that your best way forward
is to make a formal proposal to an ITU experts' meeting as to how this could
work, why it is valuable etc.
Regards,
Chris
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
Sent: Friday, December 08, 2000 11:03 AM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
Charles,
I have no further comment on the subject unless and until you clarify the
following question, which I have asked repeatedly:
Endpoint S, registers using third party registering entity R at gatekeeper G
which uses the direct call model. To which entity does H, an H.323 entity
wishing to call the user at S, send its setup message (the options as I
understand them being R and S)?
Incidentally I regard both applications given in your most recent email
simply
as gatekeeper configuration.
Regards,
Chris
"Agboh, Charles" wrote:
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
(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
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.
Regards,
Chris
-----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
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
if
the
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.
transport
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
EP
that does not "speak" H.323 the signaling will go to some entity
will be able to "speak" H.323 and bind the RAS context created by
(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
IWF
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,
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
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
etc.
throughout
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
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,
I'd
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
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
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)
clearly
the
that
the
that
the
optional
thought
them)
the
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
--
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 Wayman Purvis