AW: different CRVs on DCFs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





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


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux