Why don't you just create a simple accounting module that records call start/stop events (or even you an existing radius/sql modules to update call state information somewhere in a database). You would then get rid of status port problems and process only information that you are interested in. You could then decrease status trace level to 0 or 1 to read on route requests and CDRs, without RAS message flood (which can be significant when many endpoints are registered).
----- Original Message ----- From: "Frank Fischer" <frank.fischer@xxxxxxxxxxxxxxxx>
Sent: Friday, November 12, 2004 5:37 AM
i found the message below in the mailing list archive. It's about different
CRVs from originating and terminating Endpoints. Refering to 2.0.7 you wrote
that "it should correctly remember CRV for both originating and terminating
endpoint".
Does this mean that you think in 2.0.7 the CRV is also the same for the DCFs
from both endpoints?
I'm asking because on 2.0.9 i expirience the same situation as Raul
described in his Posting - two different CRVs from the both endpoints. For
my plans to implement a line hunting using an external application (via
VirtualQueue) this is a killer, since i will not be able to securely match a
DCF to a call (build on the both ACFs and the one DCF with the identical
CRV).
From my point of view it would even be better to use the call number since it is unique (at least during the runtime of the gatekeeper) and it would allow to also make a reference to the CDR message on the Status Port.
What do you think?
Greetings Frank
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
