AW: different CRVs on DCFs

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

 



Hi Michal

I filly agree with you, the status quo may not be changed, otherwise there
will be a lot of users out there very sad.... 
My intension would be to implement a switch that allows to configure wheter
CRV or conferenceID would be printed out with the ARQs/DRQs. And CRV would
be the default setting. 
Like this there would be a full backward compability (none of the existing
users would have to change anything in their configs). And since the CRV
field is just replaced with the conferenceID when the switch is on
conferenceID, also the fomat of the ARQ/DRQ messages would be the same, only
the content in one field would change.

For CRV this already looks like:

ACF|CallerIP:Port|CallerEndpointId|CRV|DestinationInfo|SourceInfo|IsAnswered
;
DCF|IP|EndpointId|CRV|DisengageReason;

And for conferenceID it would look like:

ACF|CallerIP:Port|CallerEndpointId|conferenceID|DestinationInfo|SourceInfo|I
sAnswered;
DCF|IP|EndpointId|conferenceID|DisengageReason;

What do you think about this?

Greetings
Frank

-----Ursprüngliche Nachricht-----
Von: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] Im Auftrag von
Zygmuntowicz Michal
Gesendet: Samstag, 13. November 2004 00:52
An: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Betreff: Re:  different CRVs on DCFs

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/





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