H.323 MIB definition
Hans Viens
hviens at MEDIATRIX.COM
Wed Nov 29 11:34:28 EST 2000
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 at isdn-comms.co.uk]
> Sent: Tuesday, November 28, 2000 10:36 AM
> To: Agboh, Charles; 'ITU-SG16 at 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 at isdn-comms.co.uk]
> > Sent: Monday, November 27, 2000 6:19 PM
> > To: Agboh, Charles
> > Cc: 'ITU-SG16 at 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 at isdn-comms.co.uk]
> > > Sent: Monday, November 27, 2000 10:41 AM
> > > To: Agboh, Charles
> > > Cc: ITU-SG16 at 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 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
More information about the sg16-avd
mailing list