Third party registration/group registration

[Agboh, Charles]

Chris,



Q1:     How can I support third party registration in H.323 v2?

A:1     alternateEndpoint structure but I have the UDP packet size
limitation so if I want to do third party registration on behalf of
thousands of EPs what can I do?

Q2:     Is there a clean way to circumvent this limit?


The application is an H.323-X gateway.  X may be SIP.

regards,

charles


-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp at isdn-comms.co.uk]
Sent: Friday, November 24, 2000 5:48 PM
To: Agboh, Charles
Cc: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: Third party registration/group registration


Charles,

The way you describe this I don't understand how it is "third-party".

It is possible to register lots of aliases simultaneously to the same
endpoint.  This is not third-party as I understand the term.  The size of a
single RRQ is limited by your transport network, but if you're using UDP
that
gives you about 64 kilobytes - is that really not enough for your purposes?

Maybe you should describe your application, so we can think about how to
achieve the desired result.

Regards,
Chris


"Agboh, Charles" wrote:
>
> Chris, all;
>
> Thanks for the response.  The scenario I am thinking off is this.
>
> -(a) for a single endpointIdentifier
> -(b) for a single callSignalingAddress/rasAddress
> -(c) potentially thousands of terminalAlias's.
>
> In version 2, (a)  and  (b) are not supported together because of the
> following text in  H.225.0 V2:
>
> (d)      Section 7.2.2
>             -----------------
>
>             "If the Gatekeeper receives an RRQ having the same Transport
> Address as a previous RRQ and a different alias address, it should replace
> the translation table entries."
>
> My question is, how can I have (a), (b), (c) or third party registration
> with (c).
>
> I was thinking that the alternateEndpoint Structure may be usful for (c)
but
> there is the limitation of the size of the UDP packet.  An alternative
could
> be to use the lightweight RRQ  but from section 7.9.1 of H.225.0:
>
> "An endpoint can send a lightweight RRQ consisting of only keepAlive,
> endpointIdentifier, gatekeeperIdentifier, tokens, and timeToLive."
>
> The last resort for (a), (b) and (c).
> ---------------------------------------
>
> -H.323v4 addtitive registration
> -Group registration (i.e. e164 prefix registration).  This is supported in
> v2->v4.
> -Is there another method I can use with an H.323 complaint GK without
> creating backward compatibility problems.
>
> Best regards,
>
> charles
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
> Sent: Friday, November 24, 2000 2:41 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Third party registration
>
> Charles, All,
>
> > Is third party registration supported in H.323 V2, V3, V4?
> What's your application?
>
> According to "original intent", the answer is "yes".  However this will
> surprise a lot of people and I doubt you'll find many gatekeepers to
support
> it.  It all comes down to a couple of strange-looking "sequence of"s in
RRQ.
> I
> was reliably informed some time ago that the original intent was that IF
RRQ
> gives more than one callSignalAddresses, it should give the same number of
> rasAddresses and either none or the same number of terminalAliases.
> Similarly
> if giving more than one rasAddress there should be the same number of
> callSignalAddresses  Then the first element in each list maps to the first
> element of the others, the second to the second etc.  My assumption is
that
> RCF
> or RRJ ought to be sent only to the first rasAddress in the list.
> However, as I said before, this is an undocumented "original intent", and
> the
> ASN.1 that came out of it is far from the best way to achieve it.  I don't
> know
> if anybody actually handles multiple entries in these fields (apart from
> terminalAlias) or, if they do, HOW they handle them.
>
> Does anyone out there with a gatekeeper have any input on whether or how
> they
> handle this?
>
> Charles,
>
> I'm cross-posting this to the H.323 implementors list - you may get more
> idea
> of what's actually implemented from there.
>
> Regards,
> Chris
> --
> 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

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