Third party registration/group registration
Agboh, Charles
Charles.Agboh at GTS.COM
Fri Nov 24 10:24:49 EST 2000
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
More information about the sg16-avd
mailing list