AW: Third party registration/group registration

Euchner Martin Martin.Euchner at ICN.SIEMENS.DE
Tue Nov 28 06:26:14 EST 2000


I'm not certain whether the term "3rd party registration" is really clearly defined and described; although technically, there might be some means to realize this.

My understanding here is, that a third party which is probably not actually involved in the call, registers one or more H.323 endpoints in one step.

An interesting question for security is: Who gets authenticated? How does the 3rd party registration interact with the usual user-based authentication?

Thus, there is certainly some need for clarification and better description.

Kind Regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 722 55790
| Martin Euchner                 Fax  : +49 89 722 46841
| Siemens AG
| ICN M NT 5                     mailto:Martin.Euchner at icn.siemens.de <mailto:Martin.Euchner at icn.siemens.de>
|                                mailto:martin.euchner at ties.itu.int <mailto:martin.euchner at ties.itu.int>
| Hofmannstr. 51                 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm
| D-81359 Muenchen               Internet: http://www.siemens.de <http://www.siemens.de>
| __________________
| Germany
-----------------------------------------------------------------------


        -----Ursprüngliche Nachricht-----
        Von:    Chris Wayman Purvis [SMTP:cwp at ISDN-COMMS.CO.UK]
        Gesendet am:    Dienstag, 28. November 2000 10:36
        An:     ITU-SG16 at mailbag.cps.intel.com
        Betreff:        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

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