Re: Third party registration/group registration

29 Nov 2000


      Accurate terminology is obviously useful, but in this case, at least, it
looks like something people can agree on and then move on.  The more
important point seems to be the underlying distinction in requirements:
 -- register on behalf of H.323 endpoints
 -- register on behalf of other endpoints
where I use "other" in the sense that the contact address is associated with
a non-H.323 signalling protocol.  Purity is beside the point here -- it's
the intention of the contact address that matters.  Stating the requirement
in this way makes it obvious that the second requirement includes the need
to state which protocol the endpoints expects to receive.
There is another possibility, of course: use the same mechanism to satisfy
all requirements, and allow for the possibility that the endpoint supports
multiple protocols.  I think the design would be cleaner if we took the
approach: one contact point, one protocol -- even if it meant repeating the
contact information for each protocol a multiprotocol endpoint supports.
...
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
Sent: Wednesday, November 29, 2000 4:45 AM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
Charles,
...
The IWF (SIP-H.323 gateway) may terminate data (voice,
video, data) if it
...
determines that the call cannot go from end-to-end.  An
entity outside of
...
the IWF may perform this function on behalf of the IWF.  In
this case, this
...
entity would be under the influence of the IWF.
Right.  But my point is that for a registration is to be
called "third-party",
the IWF would have NO part in the proceedings other than the
registration
stage.  You appear to be ignoring my point about what entity
is handling
H.225.0/Q.931 and/or H.245 signalling, which I feel is the
crucial part of what
would make a registration "third-party".
...
By *true* H.323 entities, I meant an entity that *speaks*
ONLY H.323.   The
...
IWF represents non-H.323 entities on the H.323 network.
Your "*true*" H.323 entity is an unusual beast indeed, given
that the majority
of H.323 devices around are either gateways (speaking another
protocol) or
PC-based (in which they generally "*speak*" large varieties
of protocols for
different purposes.  In fact you restrict your definition of
"*true*" H.323
entities to standalone IP phones.  The fact that a device
supports protocols
other than H.323 does NOT make it any the less a "*true*"
H.323 device in any
reasonable definition of the word "true".
...
You are right, additive registration is NOT third-party
registration.   Can
...
it be used as a means to achieve scalable third-party registration?
Additive registrations can, I believe, be used to achieve
what you are trying
to achieve.  I don't believe it can be used to achieve what
_I_ understand as
third-party registration.  Our disagreement is around the
definition of the
term "third-party registration", the difference in our
definitions causing
confusion.
I'll stick my neck out here and say that so far I believe
consensus is with my
definition (third-party registration as one H.323 entity
registering on behalf
of other entities which are H.323 except in their inability
or unwillingness to
register themselves with a gatekeeper) rather than yours (a
gateway registering
any device using any protocol with an H.323 gatekeeper).  I
will then promptly
duck as I wait for the flack to fly!
Regards,
Chris
...
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Tuesday, November 28, 2000 10:36 AM
To: Agboh, Charles; 'ITU-SG16@mailbag.cps.intel.com'
Subject: Re: Third party registration/group registration
All,
Please please PLEASE can we have some more opinions on this
important
...
definition, though.  Charles and I simply disagree, and a
wider pool of
...
opinion
is needed in order for consensus to be reached.  Although I
disagree with
...
Charles's view I am willing to espouse it if that's the way
the majority of
...
experts see things.  Without further input we'll simply go
round in circles.
...
Charles, All,
I believe the fundamental question about "third-partyness"
in this context
...
is
what entity or entities will handle the H.225.0/Q.931 and or H.245
signalling.
My understanding of the type of IWF you are talking about
(at least, the way
...
I
would implement such a thing!) is that the IWF terminates
all signalling,
...
with
RTP data going direct end to end.  So it is the entity that
is performing
...
the
registration that will handle all signalling (namely what
you in your
...
SIP-centred way call and IWF and I in my H.323-centred way
call a gateway!).
...
To me this is a fair definition of first-party.  The only
thing the IWF is
...
not
terminating is (voice, video and application) data.  This
does not make the
...
registration third-party in my opinion.  There is no
assumption (as far as I
...
can remember, anyway) that H.323 entities have to handle
their own RTP
...
sessions

they are required only to exchange addresses to terminate

these sessions.
...
Simple question: What is your definition of a "*true* H.323
entity"?  In
...
what
sense is your gateway/IWF not a "*true* H.323 entity"?
Additive registration is NOT third-party registration by my
definition.
...
Regards,
Chris
"Agboh, Charles" wrote:
...
Hi Chris,
I see what you mean.  I think you are working under the
assumption that
...
the
...
"..other H.323 entities" are *true* H.323 entites.   The
IWF may give the
...
...
impression that they are H.323 entities but it doesn't
mean they are.
...
...
In this model, I am assuming that the "third-party" is
receving all
...
...
signalling from the GK whether it (the GK) is in DRC or GRC mode.
Q:  Do I really care if the "..other H.323 entities" are
*true* H.323
...
...
entities or not?     A GK probably couldn't say if  the
"first-party"
...
being
...
registered   (the entitry being registered as apposed to
the entity
...
...
receiving the registration) is a *true* H.323 entity or not.
A:  It may be usefull.  A GK can invoke a special feature
if it can
...
...
differentiate.
H.323v4 defines the additive registration feature, which by your
definition
...
is a third-party registration, right?  So how does the GK
know that the
...
...
"first-party" is a *true* H.323 entitry?
Best Regards,
charles
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Monday, November 27, 2000 6:19 PM
To: Agboh, Charles
Cc: 'ITU-SG16@mailbag.cps.intel.com'
Subject: Re: Third party registration/group registration
Charles,
...
My undstanding of "third-party" registration is the
same as yours.
...
But,
...
in
...
some applications a registration by the IWF may not be
on its own
...
behalf.
...
These two sentences contradict each other.  Please reread
my explanation
...
of
...
my
understanding, as it is impossible for you to agree with
it and believe
...
what
...
you have written in the second sentence above.
Unless I misunderstand your definition of an "IWF", which
I take to be
...
...
synonymous with a "gateway" as defined in the H.323
series of standards.
...
...
...
H.323v4 provides this feature (a way to bypass the UDP
packet size
...
...
...
limitation) for this same reason.
Does it make sense to have this?, If no, then why not?
SupportedProtocols ::= CHOICE
{
        nonStandardData                 NonStandardParameter,
        h310                            H310Caps,
        h320                            H320Caps,
        h321                            H321Caps,
        h322                            H322Caps,
        h323                            H323Caps,
        h324                            H324Caps,
        voice
        .......,
                SIP                             SIPCaps
}
This may make sense (and is what I meant when I referred to
"supportedPrefixes").  If this is a way forward that you
believe would be
...
...
useful for SIP gateways I would encourage you to write a
formal proposal
...
to
...
an
ITU SG16 experts meeting on this basis.
Regards,
Chris
...
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Monday, November 27, 2000 10:41 AM
To: Agboh, Charles
Cc: ITU-SG16@mailbag.cps.intel.com
Subject: Re: Third party registration/group registration
Charles,
Wrong in my opinion, but I would hope other experts
would express their
...
...
...
opinions too!  The problem is I'm not sure whether this
is a question of
...
...
...
understanding or of detailed definition of the phrase
"third party" in
...
...
this
...
context.
My understanding of the phrase "third party
registration" would be one
...
...
H.323
...
entity registering at a gatekeeper on behalf of other
H.323 entities.
...
My
...
...
understanding of the word "registration" of this
context is that it can
...
...
only
...
apply to H.323 entities.  In this context the IWF can
be considered to
...
be
...
at
...
the extreme edge of the H.323 network, so any
"registration" it does is
...
on
...
...
its
own behalf.
Maybe what you actually want is some equivalent to the
supportedPrefixes
...
...
...
that
arrived in version 2, for SIP gateways.
Whatever we agree you want, though, I think it is worth
trying to reach
...
...
some
...
consensus among experts in this group as to what the
phrase "third
...
party"
...
...
means
in this context - as your understanding and mine are clearly in
disagreement.
Regards,
Chris
"Agboh, Charles" wrote:
...
Chris,
There are applications where an IWF can register an
EP from one domain
...
...
...
into
...
another.   This allows automatic visibility of EP
from one domain from
...
...
...
...
another.  In this case the IWF is registering not
only itself but
...
other
...
...
EPs.
...
For this scenario, the third-party entity is the IWF, right?
regards,
charles
--
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
--
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

Tom-PT Taylor

tags (0)

participants (1)