Avin,
Having done some more research it appears that Cisco IOS Gatekeepers expect
(require?) lightweight RRQs on re-registration, to quote Cisco:
Lightweight Registration
Prior to H.323 Version 2, Cisco gateways reregistered with the gatekeeper
every 30 seconds. Each registration renewal used the same process as the
initial registration, even though the gateway was already
registered with the gatekeeper. This behavior generated considerable
overhead at the gatekeeper.
H.323 Version 2 defines a lightweight registration procedure that still
requires the full registration process for initial registration, but uses an
abbreviated renewal procedure to update the gatekeeper and minimize
overhead.
Lightweight registration requires each endpoint to specify a TimeToLive
(TTL) value in its Registration Request (RRQ) message. When a gatekeeper
receives an RRQ message with a TTL value, it returns an updated TTL timer
value in a Registration Confirmation (RCF) message to the endpoint. Shortly
before the TTL timer expires, the endpoint sends an RRQ message with
KeepAlive field set to TRUE, which refreshes the existing registration.
An H.323 Version 2 endpoint is not required to indicate a time-to-live in
its registration request. If the endpoint does not indicate a time-to-live,
the gatekeeper assigns one and sends it to the gateway in the RCF message.
No configuration changes are permitted during a lightweight registration, so
all fields are ignored other than the endpoint identifier, gatekeeper
identifier, tokens, and time-to-live. In the case of H.323 Version 1,
endpoints cannot process the TTL field in the RCF; the gatekeeper probes the
endpoint with IRQs for a predetermined grace period to learn if the endpoint
is still alive.
Now, I don't know much about the format of an RRQ but I can guess that we
did a full RRQ initially and suceeded, then when we came to re-register we
did another full RRQ which got rejected because they were expecting a
light-weight (refresh) registration that doesn't have all of the parameters
for a full registration but does have to provide the end-point identifier
that was returned in the original RCF - as described above.
I suspect for this to work ooh323 needs to be able to support the two styles
of operation:
1. always sending full RRQ - for older/legacy GKs
2. initial registiation is full RRQ and re-registration are light-weight RRQ
with only endpoint identifier
for this I suggest we would need a global configuration option in
ooh323.conf
gatekeeper_lightweight_reregistion = true|false
or, alternatively as it appears to be specified as a H.323 protocol version
2.x or later option perhaps it can occur automagically by detecting the
version of the Gatekeeper we're attached to?
We possibly also need to be able to specify the RRQ TTL in the
configuration, with something like:
gatekeeper_ttl = 300
Regards
Mike
----- Original Message -----
From: "Avin Patel" <[EMAIL PROTECTED]>
To: "Mike Tubby" <[EMAIL PROTECTED]>
Cc: <ooh323c-devel@lists.sourceforge.net>
Sent: Wednesday, February 14, 2007 3:17 PM
Subject: Re: [ooh323c-devel] ooh323 drops registration with Cisco
IOSGateKeeper
> Hi Mike,
> Currently I am trying to solve the George problem. As I am not
> contributing full time on ooh323c, so once George problem is solved, we
> will take a look at your problem.
>
> As logically, once registration attempts fails, than endpoint shouldn't be
> trying to register again with same gatekeeper. So I don't see any problem.
> I think need to check, why registration attempts fails.
>
> Regards,
> Avin Patel
> Objective Systems Inc
>
> Mike Tubby wrote:
>> Gents,
>> A week or so ago I posted this query regarding ooh323 with Asterisk
>> dropping registration with a Cisco IOS based Gatekeeper after 5 minutes.
>> I have done some more work on tracking/tracing the issue and present my
>> finding as follows:
>> - initial registration from Asterisk/ooh323 suceeds
>> - first re-registration attempt fails with RRJ returned by the gatekeeper
>> - asterisk never attempts to retry after the RRJ
>> - anything else sent by Asterisk results in ICMP port un-reachable from
>> the gatekeeper
>>
>> My setup has three devices:
>>
>> pabx.int.thorcom.com 192.168.1.5 Asterisk
>> 1.2.14/Asterisk-Addons-1.2.5 (ooh323 rev 0.8.2)
>> cisco-gk.int.thorcom.com 192.168.1.6 Gatekeeper: Cisco 2621XM
>> c2600-jsx-mz.123-22.bin
>> tetra.int.thorcom.com 192.168.1.7 Damm Cellular SB421 TETRA
>> radio system www.damm.dk <http://www.damm.dk>
>> Below are two complete examples of what is happening - the first with
>> tcpdump on the Asterisk box and various debug/logging snippets from the
>> Cisco, the second a complete re-run of what happened but with trace
>> captured by Ethereal so that the H.225/RAS is decoded...
>> Any help with fixing this woudl really be appreciated as its become a
>> show stopper for me...
>> Regards
>> Mike
>>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ooh323c-devel mailing list
ooh323c-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ooh323c-devel
