I understand your point of view, but the problem with status port output is that many applications depend on it and it cannot be easily changed, without breaking existing systems. ----- Original Message ----- From: "Frank Fischer" <frank.fischer@xxxxxxxxxxxxxxxx> Sent: Saturday, November 13, 2004 12:12 AM Hi Michal Thanks a lot for your Feedback. > Why don't you just create a simple accounting module that records call start/stop events Do you mean a GnuGk module? That would basically be a good idea i think, but doesn't fit very well for my specific use case. Even if there would be a such a module, i would still have to communicate from my external Routing Application with that GnuGk module. Since I'm also tracking other RAS messages (i also monitor endpoints) it would make sense to solve that call monitoring using the same mechanism based on the VirtualQueue/Status Port. I also think/hope that replacing the CRV field with the conferenceID in ARQs and DRQs would be a quicker way to do it (but i'm not familiar with the GnuGK code, so I can just hope :-)). Kind Regards Frank -----Ursprüngliche Nachricht----- Von: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Zygmuntowicz Michal Gesendet: Freitag, 12. November 2004 16:28 An: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Betreff: Re: different CRVs on DCFs 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: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49 Homepage: http://www.gnugk.org/
