Re: [OpenSIPS-Users] ASR & ACR per country/destination

2018-04-12 Thread DanB
Hi Abdoul,

You should start with the components part of the integration: sessions,
cdrs and stats.

I would suggest that we move discussion on CGRateS group so we don't
create much noise here with CGRateS related questions.

Thanks,
DanB



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] ACC module with JSON events

2018-02-25 Thread DanB
Sammy,

Another option on short term until the new feature will be implemented
in OpenSIPS would be to use CGRateS as CDR format converter: receive
CDRs from "cgrates" module in OpenSIPS and use online export of CGRateS
to further export the CDR in the JSON over http (customizable fields).
You don't need to configure much on CGRateS side in this case since no
billing needs to be involved.

DanB





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +

2017-03-08 Thread DanB

Hi Jeff,


You can build packages for CentOS also, you can find more details here:

https://github.com/cgrates/cgrates/tree/master/packages

On the other hand, in order to avoid abusing OpenSIPS mailing list with 
CGRateS related questions, feel free to join our google group or IRC 
channel and come up with any additional questions.


Cheers,
DanB


On 08.03.2017 10:26, users-requ...@lists.opensips.org wrote:

Message: 1
Date: Tue, 7 Mar 2017 17:26:40 -0500
From: Jeff Wilkie<jwil...@usipcom.com>
To: OpenSIPS users mailling list<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +
Message-ID:

Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +

2017-03-05 Thread DanB

Hi Jeff,

Although it is a slippery ground, in order to have the question 
answered, I can claim having experience with both systems (we used to 
install CDRTool for customers and still have today installs running 
since like 8 years without issues).


CDRTool (CDR rating system):

* Written in php, works closely with db (eg: relies on it's query 
speed with some caching for parts of the rates)


* Mature implementation, not much development changing the code 
over the years (other than bug fixes).


* Simple rating definition and implementation.

* Web interface for rates management as well as CDRs.

* Designed around rating CDRs and maintaining account balance.


CGRateS (OCS - online charging system):

* Written in Go, caches almost all information in process, database 
agnostic (abstracts databases into interfaces), database speed does not 
influence the speed of calculations, built on micro-services with full 
asynchronous processing.


* Still in Release Candidate when it comes to architecture, evolved 
a lot over the years, master should be always stable in terms of 
functionality since it runs in production environments (architecture 
part is not yet declared stable - you can expect it to still evolve).


* Complex rating (rates voice calls, data streams, sms, etc) and 
accounting (unlimited number of balances/bundles and failover between 
them during a call).


* API (JSON) driven management (full set) with no official web 
interface available yet.


* Additional functionality: fraud detection with automatic 
mitigation (3 layers: accounts, CDR stats, resources usage), CDR logging 
with support for interim records, QoS LCR and LCR over bundels, 
real-time (complete in memory) call statistics with pattern monitoring 
and triggers/web hooks towards external systems, derive charging 
(session emulation - reseller/distributor scenarios, customer/supplier 
parallel calculations), performance optimized (one CGRateS instance 
should be able to handle 5k requests per second in terms of rating 
calculations), built-in high availability for Diameter setups.



So these being said, it is all about the need vs price (time investment) 
you are ready to pay for it by using one system or another (considering 
both systems are opensource and you can extend yourself in one way or 
another). If you don't have complex rating requirements nor the need of 
increased CPS, I trust CDRTool will do the job just fine since it did it 
for us over the years (you get the advantage as said of simple 
management and architecture stability, quick learning curve). CGRateS on 
the other hand should be there if you decide you need more 
functionality/speed and you are also ready to offer it more time and 
efforts.



I hope this helps someone!

DanB


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-18 Thread DanB

Hey Bogdan,

This one sounds good enough for my use case. I will need a bit of time 
to test it but if it works with dialog vars then I am a happy user ;).


Thanks for your efforts!

DanB

On 18.05.2015 17:05, Bogdan-Andrei Iancu wrote:
Dan, the biggest problem I see is how to get the extra information for 
that event. You can set a list of vars to be added to the event, but 
the question is - what context will be used to evaluated those vars ? 
The events do not have a context of themselves - no msg, so no vars, 
no script variable, no avps are present.


What we should continue doing is to allow the code triggering the 
event (like the dialog module in this case) to make available a 
context with different info - like the dialog related variables in 
this case.
And as Razvan said, this already works - you can intercept the 
STATE_CHANGED event in script, use the dialog vars to collect more 
info ($dlg_val) and raise a new, more complex event.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.05.2015 13:45, DanB wrote:

Hey Bogdan,

Thanks for your answer.

I understand the part with custom things added to events. I was more 
like looking for the long shot solution, to define what to put in 
(maybe same way we do for raise_event).


Regarding solution 2) - tried that but it appears that the avps are 
not longer active in E_DLG_STATE_CHANGED route. Could that be the case?


Dan

On 18.05.2015 11:57, Bogdan-Andrei Iancu wrote:

Hi Dan,

I will do the backport to 1.2.0 - thank you for testing.

Now, on your comments: IMHO it is not wise to add more info to the 
event - the actual event should notify only on the change of state 
and that's it; You need extra A and B fields, somebody else C and D, 
etc... So there is no way to get a consents in term of what and how 
much additional info should be added.

The Options I see:
1) extend support for events, so you can specify extra vars to be 
pushed into the event - this is a long shot.
2) derive the event - capture the event and build on top of it 
another custom one, with the additional things you want
3) get the original event, and using the dialog ID, make a dlg_list 
to get all the info from the dialog.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.05.2015 14:58, DanB wrote:

Hey Bogdan,

Thanks for this.

I can confirm that the hash_entry and hash_id are now attached to 
the event:


#
U 2015/05/17 13:55:45.632615 127.0.0.1:60380 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
hash_entry::1593
hash_id::82596694
old_state::4
new_state::5


As inquired in the ticket also, will it be possible here to add 
some $avp or dialog variables maybe? From the billing perspective 
we will need to know at least user and destination called to make 
use of dialog_start event.


Ta,
DanB

On 15.05.2015 17:02, Bogdan-Andrei Iancu wrote:

Hi Dan,

Could you check the patch I did (see commit e461b65) to provide 
the hash_entry and hash_id for the event ? if ok, I will backport 
to 2.1 too


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 15:08, Bogdan-Andrei Iancu wrote:

Right good one :D. We will patch it to include the DID too.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 14:54, DanB wrote:

Hi Bogdan,

That is a useful variable indeed (works perfect with 
Accounting). Unfortunately have no clue how to include/attach it 
to the E_DLG_STATE_CHANGED event.


Thanks,
DanB

On 11.05.2015 13:52, Bogdan-Andrei Iancu wrote:

Hi Dan,

Try the $DLG_did variable :
http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id297237

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.05.2015 12:23, DanB wrote:

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? 
I would need to know at least h_entry and h_id for the dialog 
(so I can kill it from outside) and some other $avps I need 
for prepaid at the start of the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, 
I suggest to use the CDR event for accounting purposes and 
for monitoring the dialog status take a look at the 
E_DLG_STATE_CHANGED event:
http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207 



Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result 
is that I get one CDR record at the end of the dialog as 
E_ACC_CDR event.


Now I would

Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-18 Thread DanB

Hey Brett,

For your info, I have tried a similar thing, raising another event out 
of the E_DLG_STATE_CHANGED route however for some reason I could not 
access the avps in there, so not much more info than the original event had.


DanB

On 18.05.2015 15:23, Brett Nemeroff wrote:

Bogdan,
How about an event route that lets you use script logic to modify the 
event prior to emitting it?


Sent from my iPhone

On May 18, 2015, at 4:57 AM, Bogdan-Andrei Iancu bog...@opensips.org 
mailto:bog...@opensips.org wrote:



Hi Dan,

I will do the backport to 1.2.0 - thank you for testing.

Now, on your comments: IMHO it is not wise to add more info to the 
event - the actual event should notify only on the change of state 
and that's it; You need extra A and B fields, somebody else C and D, 
etc... So there is no way to get a consents in term of what and how 
much additional info should be added.

The Options I see:
1) extend support for events, so you can specify extra vars to be 
pushed into the event - this is a long shot.
2) derive the event - capture the event and build on top of it 
another custom one, with the additional things you want
3) get the original event, and using the dialog ID, make a dlg_list 
to get all the info from the dialog.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.05.2015 14:58, DanB wrote:

Hey Bogdan,

Thanks for this.

I can confirm that the hash_entry and hash_id are now attached to 
the event:


#
U 2015/05/17 13:55:45.632615 127.0.0.1:60380 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
hash_entry::1593
hash_id::82596694
old_state::4
new_state::5


As inquired in the ticket also, will it be possible here to add some 
$avp or dialog variables maybe? From the billing perspective we will 
need to know at least user and destination called to make use of 
dialog_start event.


Ta,
DanB

On 15.05.2015 17:02, Bogdan-Andrei Iancu wrote:

Hi Dan,

Could you check the patch I did (see commit e461b65) to provide the 
hash_entry and hash_id for the event ? if ok, I will backport to 
2.1 too


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 15:08, Bogdan-Andrei Iancu wrote:

Right good one :D. We will patch it to include the DID too.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 14:54, DanB wrote:

Hi Bogdan,

That is a useful variable indeed (works perfect with Accounting). 
Unfortunately have no clue how to include/attach it to the 
E_DLG_STATE_CHANGED event.


Thanks,
DanB

On 11.05.2015 13:52, Bogdan-Andrei Iancu wrote:

Hi Dan,

Try the $DLG_did variable :
http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id297237

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.05.2015 12:23, DanB wrote:

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? I 
would need to know at least h_entry and h_id for the dialog (so 
I can kill it from outside) and some other $avps I need for 
prepaid at the start of the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, 
I suggest to use the CDR event for accounting purposes and for 
monitoring the dialog status take a look at the 
E_DLG_STATE_CHANGED event:
http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207 



Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result 
is that I get one CDR record at the end of the dialog as 
E_ACC_CDR event.


Now I would need to know also when dialog starts (eg: after 
INVITE is being OKed).


What is the most recommended way to achieve that? I tried 
setting evi_flag but it appears that works only if I do not 
set cdr_flag. Am I right in that assumption? Are both 
evi_flag and evi_missed_flag options suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users














___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users






___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin

Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-18 Thread DanB

Hey Bogdan,

Thanks for your answer.

I understand the part with custom things added to events. I was more 
like looking for the long shot solution, to define what to put in (maybe 
same way we do for raise_event).


Regarding solution 2) - tried that but it appears that the avps are not 
longer active in E_DLG_STATE_CHANGED route. Could that be the case?


Dan

On 18.05.2015 11:57, Bogdan-Andrei Iancu wrote:

Hi Dan,

I will do the backport to 1.2.0 - thank you for testing.

Now, on your comments: IMHO it is not wise to add more info to the 
event - the actual event should notify only on the change of state and 
that's it; You need extra A and B fields, somebody else C and D, 
etc... So there is no way to get a consents in term of what and how 
much additional info should be added.

The Options I see:
1) extend support for events, so you can specify extra vars to be 
pushed into the event - this is a long shot.
2) derive the event - capture the event and build on top of it another 
custom one, with the additional things you want
3) get the original event, and using the dialog ID, make a dlg_list to 
get all the info from the dialog.


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.05.2015 14:58, DanB wrote:

Hey Bogdan,

Thanks for this.

I can confirm that the hash_entry and hash_id are now attached to the 
event:


#
U 2015/05/17 13:55:45.632615 127.0.0.1:60380 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
hash_entry::1593
hash_id::82596694
old_state::4
new_state::5


As inquired in the ticket also, will it be possible here to add some 
$avp or dialog variables maybe? From the billing perspective we will 
need to know at least user and destination called to make use of 
dialog_start event.


Ta,
DanB

On 15.05.2015 17:02, Bogdan-Andrei Iancu wrote:

Hi Dan,

Could you check the patch I did (see commit e461b65) to provide the 
hash_entry and hash_id for the event ? if ok, I will backport to 2.1 too


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 15:08, Bogdan-Andrei Iancu wrote:

Right good one :D. We will patch it to include the DID too.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 14:54, DanB wrote:

Hi Bogdan,

That is a useful variable indeed (works perfect with Accounting). 
Unfortunately have no clue how to include/attach it to the 
E_DLG_STATE_CHANGED event.


Thanks,
DanB

On 11.05.2015 13:52, Bogdan-Andrei Iancu wrote:

Hi Dan,

Try the $DLG_did variable :
http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id297237

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.05.2015 12:23, DanB wrote:

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? I 
would need to know at least h_entry and h_id for the dialog (so 
I can kill it from outside) and some other $avps I need for 
prepaid at the start of the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, I 
suggest to use the CDR event for accounting purposes and for 
monitoring the dialog status take a look at the 
E_DLG_STATE_CHANGED event:
http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207 



Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result is 
that I get one CDR record at the end of the dialog as 
E_ACC_CDR event.


Now I would need to know also when dialog starts (eg: after 
INVITE is being OKed).


What is the most recommended way to achieve that? I tried 
setting evi_flag but it appears that works only if I do not 
set cdr_flag. Am I right in that assumption? Are both evi_flag 
and evi_missed_flag options suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users














___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users








___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-17 Thread DanB

Hey Bogdan,

Thanks for this.

I can confirm that the hash_entry and hash_id are now attached to the event:

#
U 2015/05/17 13:55:45.632615 127.0.0.1:60380 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
hash_entry::1593
hash_id::82596694
old_state::4
new_state::5


As inquired in the ticket also, will it be possible here to add some 
$avp or dialog variables maybe? From the billing perspective we will 
need to know at least user and destination called to make use of 
dialog_start event.


Ta,
DanB

On 15.05.2015 17:02, Bogdan-Andrei Iancu wrote:

Hi Dan,

Could you check the patch I did (see commit e461b65) to provide the 
hash_entry and hash_id for the event ? if ok, I will backport to 2.1 too


Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 15:08, Bogdan-Andrei Iancu wrote:

Right good one :D. We will patch it to include the DID too.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 14:54, DanB wrote:

Hi Bogdan,

That is a useful variable indeed (works perfect with Accounting). 
Unfortunately have no clue how to include/attach it to the 
E_DLG_STATE_CHANGED event.


Thanks,
DanB

On 11.05.2015 13:52, Bogdan-Andrei Iancu wrote:

Hi Dan,

Try the $DLG_did variable :
http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id297237

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.05.2015 12:23, DanB wrote:

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? I 
would need to know at least h_entry and h_id for the dialog (so I 
can kill it from outside) and some other $avps I need for prepaid 
at the start of the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, I 
suggest to use the CDR event for accounting purposes and for 
monitoring the dialog status take a look at the 
E_DLG_STATE_CHANGED event:

http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result is 
that I get one CDR record at the end of the dialog as E_ACC_CDR 
event.


Now I would need to know also when dialog starts (eg: after 
INVITE is being OKed).


What is the most recommended way to achieve that? I tried 
setting evi_flag but it appears that works only if I do not set 
cdr_flag. Am I right in that assumption? Are both evi_flag and 
evi_missed_flag options suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users














___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-12 Thread DanB

Hi Ben,

Can u please give me an example?

Ta,
DanB


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-11 Thread DanB

Hi Bogdan,

That is a useful variable indeed (works perfect with Accounting). 
Unfortunately have no clue how to include/attach it to the 
E_DLG_STATE_CHANGED event.


Thanks,
DanB

On 11.05.2015 13:52, Bogdan-Andrei Iancu wrote:

Hi Dan,

Try the $DLG_did variable :
http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id297237

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.05.2015 12:23, DanB wrote:

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? I would 
need to know at least h_entry and h_id for the dialog (so I can kill 
it from outside) and some other $avps I need for prepaid at the start 
of the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, I 
suggest to use the CDR event for accounting purposes and for 
monitoring the dialog status take a look at the E_DLG_STATE_CHANGED 
event:

http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result is that 
I get one CDR record at the end of the dialog as E_ACC_CDR event.


Now I would need to know also when dialog starts (eg: after INVITE 
is being OKed).


What is the most recommended way to achieve that? I tried setting 
evi_flag but it appears that works only if I do not set cdr_flag. 
Am I right in that assumption? Are both evi_flag and 
evi_missed_flag options suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users










___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-11 Thread DanB
For now no emergency since we went back to using Accounting Start/Stop 
over EVI. Works like a charm.
Would be interesting if we could add pseudovariables to 
E_DLG_STATE_CHANGED so we can load more useful info inside.


Thanks,
DanB

On 11.05.2015 14:08, Bogdan-Andrei Iancu wrote:

Right good one :D. We will patch it to include the DID too.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.05.2015 14:54, DanB wrote:

Hi Bogdan,

That is a useful variable indeed (works perfect with Accounting). 
Unfortunately have no clue how to include/attach it to the 
E_DLG_STATE_CHANGED event.


Thanks,
DanB

On 11.05.2015 13:52, Bogdan-Andrei Iancu wrote:

Hi Dan,

Try the $DLG_did variable :
http://www.opensips.org/html/docs/modules/1.11.x/dialog.html#id297237

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 09.05.2015 12:23, DanB wrote:

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? I 
would need to know at least h_entry and h_id for the dialog (so I 
can kill it from outside) and some other $avps I need for prepaid 
at the start of the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, I 
suggest to use the CDR event for accounting purposes and for 
monitoring the dialog status take a look at the 
E_DLG_STATE_CHANGED event:

http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result is 
that I get one CDR record at the end of the dialog as E_ACC_CDR 
event.


Now I would need to know also when dialog starts (eg: after 
INVITE is being OKed).


What is the most recommended way to achieve that? I tried setting 
evi_flag but it appears that works only if I do not set cdr_flag. 
Am I right in that assumption? Are both evi_flag and 
evi_missed_flag options suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users














___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Dialog start event over EVI

2015-05-09 Thread DanB

Hey Bogdan,

Thank you for the tip. I am trying now to use as advised 
E_DLG_STATE_CHANGED.


I get the following information in the event:

U 2015/05/09 11:19:59.018404 127.0.0.1:40817 - 127.0.0.1:2020
E_DLG_STATE_CHANGED
old_state::1
new_state::5


Can you advise me how to add some useful information inthere? I would 
need to know at least h_entry and h_id for the dialog (so I can kill it 
from outside) and some other $avps I need for prepaid at the start of 
the call.


Thanks again!
DanB

On 07.05.2015 18:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

As in ACC you cannot do START/STOP and CDRs in the same time, I 
suggest to use the CDR event for accounting purposes and for 
monitoring the dialog status take a look at the E_DLG_STATE_CHANGED 
event:

http://www.opensips.org/html/docs/modules/2.1.x/dialog.html#id297207

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.05.2015 13:39, DanB wrote:

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result is that I 
get one CDR record at the end of the dialog as E_ACC_CDR event.


Now I would need to know also when dialog starts (eg: after INVITE is 
being OKed).


What is the most recommended way to achieve that? I tried setting 
evi_flag but it appears that works only if I do not set cdr_flag. Am 
I right in that assumption? Are both evi_flag and evi_missed_flag 
options suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users






___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Dialog start event over EVI

2015-05-06 Thread DanB

Hey Guys,

I am using EVI to generate CDRs out of OpenSIPS. The result is that I 
get one CDR record at the end of the dialog as E_ACC_CDR event.


Now I would need to know also when dialog starts (eg: after INVITE is 
being OKed).


What is the most recommended way to achieve that? I tried setting 
evi_flag but it appears that works only if I do not set cdr_flag. Am I 
right in that assumption? Are both evi_flag and evi_missed_flag options 
suppressed by cdr_flag?


Thanks in advance for your feedback!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Async Event route_replies

2015-01-29 Thread DanB

Hey Bogdan,

Thanks for your input, I think we are on the same page here. Maybe I was 
the one forcing events to be the solution just because we already 
implemented the protocol for it :). The perfect solution would be as you 
said, a 2 way protocol (I was calling them events since I imagined them 
to be async).


Just one more idea, would it be possible to do some automatic call_start 
and call_stop event generation over http (events over http)? The reason 
I am asking is to avoid having that many ports opened between OpenSIPS 
and CGRateS.


I am travelling these days but will ping you starting of next week to 
sync each other and have a  phone call if possible on your side.


Thanks again!
DanB

On 29.01.2015 14:42, Bogdan-Andrei Iancu wrote:

Hi Dan,

The event mechanism is by definition an one way communication system. 
I understand what you are looking for, but the event system is not the 
answer for it (at least not anymore if you do look to get a sort of 
replies back).
You can get CDRS or others via events, but for auth purposes, the 
events are not the way to do it.


Do not get me wrong, but (1) as concept, events do not have replies 
and (2) the whole implementation is done in this regards. So, let's 
not try to have one solution fits all. Events are limited to one way 
direction.


What would be the perfect answer for you is a kind on protocol to 
interact with an external app - to be able to push to an external app 
various data and to wait for an answer (something like AAA does, but 
this is limited to couple of scenarios).


Now, for a current solution : why considering a complex approach with 
parking transactions, triggering unpark events via MI, having special 
routs and so, when you simply use the script async functions to 
execute, suspend and resume the INVITE processing - it is a much 
simpler and straight forward approach. What is needed is to 
encapsulate the interaction with your billing (request + reply) under 
one of the supported async functions (exec, REST, mysql).


Let me know if doing a short call will help in shorting this out.

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 28.01.2015 12:10, DanB wrote:

Hey Bogdan,

Thank you for your input and support!

Regarding existing mechanisms, I would still prefer the event part as 
it works now since it generates automated CDR vs http rest or exec 
where I need to make up my own one. Http would be my second choice if 
you ask me.
On the other hand, what about the idea of unparking a transaction 
over the MI commands? Would that be possible? In that way I could get 
the call authorization event generated manually and park the request 
right after. When billing answers, I could unpark it (and set maximum 
dialog timeout) over mi.


Thanks,
DanB






___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Async Event route_replies

2015-01-28 Thread DanB

Hey Bogdan,

Thank you for your input and support!

Regarding existing mechanisms, I would still prefer the event part as it 
works now since it generates automated CDR vs http rest or exec where I 
need to make up my own one. Http would be my second choice if you ask me.
On the other hand, what about the idea of unparking a transaction over 
the MI commands? Would that be possible? In that way I could get the 
call authorization event generated manually and park the request right 
after. When billing answers, I could unpark it (and set maximum dialog 
timeout) over mi.


Thanks,
DanB


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Async Event route_replies

2015-01-27 Thread DanB

Hey Guys,

Now that async script routes is an actual subject, I was wondering if 
you are considering event replies in script routes (eg: have a dedicated 
event_reply route where we can pick up a specific transaction parked and 
continue processing it).
A particular applicability is 2 way communication with an external 
application like billing engine.


Thanks in advance!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Async Event route_replies

2015-01-27 Thread DanB

Hi Bogdan,

I cannot claim IPR of the idea since we are using it already inside 
CGRateS with another proxy so it was not invented by us :).


The process should be something like: when OpenSIPS sends out an event 
over a connection, it should be also possible to receive data (answer or 
not) over these connections.
OpenSIPS should make the events received (replies or not, depending on 
the script admin to identify them) somehow available in some script 
routes where we can pick up parked transactions (sharing the ids via the 
replied events).


We use such scenario for call authorization inside billing (send 
call_auth to billing engine and receive maximum duration for it). 
Processing the answer is done in the script and whole thing would happen 
asynchronously, hence not anymore depending on the time it takes for 
billing to process the request.


Another usage would be for dialog kill when the funds available for the 
calls are emptied on billing side. The same event_route will receive the 
disconnect request from billing side, will identify there the dialog and 
kill it.


If this two way communication would be not suitable for events 
infrastructure which you have already developed, would it be possible to 
wake up the transaction over MI and send it to a script route plus 
setting some avps for it maybe?


Thanks for your thoughts on this!
DanB

On 27.01.2015 18:07, Bogdan-Andrei Iancu wrote:

Hi Dan,

Could you detail a bit more your idea ? I'm not sure I get the whole 
concept.


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 27.01.2015 13:38, DanB wrote:

Hey Guys,

Now that async script routes is an actual subject, I was wondering if 
you are considering event replies in script routes (eg: have a 
dedicated event_reply route where we can pick up a specific 
transaction parked and continue processing it).
A particular applicability is 2 way communication with an external 
application like billing engine.


Thanks in advance!
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users







___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] SMS using opensips

2011-03-24 Thread DanB
Hi Jayesh,

Another recipe would be using external application server for
gateway-ing between SIP and other protocols SMS providers are using
(eg: HTTP or SMPP) and have opensips as authenticator, registration
and load balancer. Offline messages can be handled also on OpenSIPS
side using msilo module.
I personally have used Twisted and Divmod/Sine. In this way you get
two way SMS without involving any database to keep up with speed and
be able to failover between providers.

DanB


On Thu, Mar 24, 2011 at 6:38 AM, Jayesh Nambiar jayesh.v...@gmail.com wrote:
 Hi All,
 I am trying to implement the SMS feature for my SIP clients, outgoing as
 well as incoming. I am planning to use Kannel SMS gateway to interface with
 the gsm networks.
 After googling a little on this topic i found a few approaches for sending
 out SMSs, like the following:
 Sending SMS from the SIP Client:
 1) Inserting the messages into a database and let Kannel periodically check
 and send it out.
 2) Use PHP-SIP package. Send a SIP Message from Opensips to the webserver
 address and web-server sends an http request to the Kannel server to take it
 ahead.
 Receiving SMS on SIP-Client
 1) Kannel sending an http request to the web-server supporting PHP-SIP and
 web server sending a message using the XMLRPC method, then opensips can use
 t_uac_slg to send the message to the SIP endpoint.
 Please do let me know if the above approaches are doable or if anyone else
 have got a better idea to implement SMS over SIP.
 Thanks a lot in advance.
 --- Jayesh
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Command opensipsctl dialplan reload randomly hangs

2010-07-16 Thread DanB
Hi Bogdan,

After so long time I finally got a debug for you (running in debug 5).
As higher the debug is as smaller the chances are to happen. Running
in debug 6 we could never reproduce it (even in debug 5 it took some
time). If we run it in debug 2 we get the hang every few days.
Let me know if you need additional traces.


Ta,
DanB



### Start BT
###

 sip1:~# opensipsctl ps|grep FIFO
 Process::  ID=13 PID=3838 Type=MI FIFO
 sip1:~# opensipsctl ps|grep FIFO
 Process::  ID=13 PID=3838 Type=MI FIFO
 sip1:~# opensipsctl dialplan reload
 Terminated
 sip1:~# /etc/init.d/
 sip1:~# gdb /usr/sbin/opensips 3838
 GNU gdb 6.8-debian
 Copyright (C) 2008 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-linux-gnu...
 (no debugging symbols found)
 Attaching to program: /usr/sbin/opensips, process 3838
 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
 Loaded symbols for /lib/libdl.so.2
 Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libresolv.so.2
 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.6
 Reading symbols from /lib/ld-linux-x86-64.so.2...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /usr/lib/opensips/modules/options.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/options.so
 Reading symbols from /usr/lib/opensips/modules/sl.so...
 (no debugging symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/sl.so
 Reading symbols from /usr/lib/opensips/modules/tm.so...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/opensips/modules/tm.so
 Reading symbols from /usr/lib/opensips/modules/signaling.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/signaling.so
 Reading symbols from /usr/lib/opensips/modules/db_mysql.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/db_mysql.so
 Reading symbols from /usr/lib/libmysqlclient.so.15...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/libmysqlclient.so.15
 Reading symbols from /lib/libpthread.so.0...
 (no debugging symbols found)...done.
 [Thread debugging using libthread_db enabled]
 [New Thread 0x7ffac71226e0 (LWP 3838)]
 Loaded symbols for /lib/libpthread.so.0
 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libcrypt.so.1
 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
 Loaded symbols for /lib/libnsl.so.1
 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
 Loaded symbols for /lib/libm.so.6
 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
 Loaded symbols for /usr/lib/libz.so.1
 Reading symbols from /usr/lib/opensips/modules/rr.so...
 (no debugging symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/rr.so
 Reading symbols from /usr/lib/opensips/modules/maxfwd.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/maxfwd.so
 Reading symbols from /usr/lib/opensips/modules/usrloc.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/usrloc.so
 Reading symbols from /usr/lib/opensips/modules/textops.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/textops.so
 Reading symbols from /usr/lib/opensips/modules/mi_fifo.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/mi_fifo.so
 Reading symbols from /usr/lib/opensips/modules/mi_datagram.so...
 (no debugging symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/mi_datagram.so
 Reading symbols from /usr/lib/opensips/modules/uri.so...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/opensips/modules/uri.so
 Reading symbols from /usr/lib/opensips/modules/xlog.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/xlog.so
 Reading symbols from /usr/lib/opensips/modules/acc.so...(no debugging symbols 
 found)...done.
 Loaded symbols for /usr/lib/opensips/modules/acc.so
 Reading symbols from /usr/lib/opensips/modules/dialog.so...(no debugging 
 symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/dialog.so
 Reading symbols from /usr/lib/opensips/modules/mediaproxy.so...
 (no debugging symbols found)...done.
 Loaded symbols for /usr/lib/opensips/modules/mediaproxy.so
 Reading symbols from /usr/lib/opensips/modules/nathelper.so

Re: [OpenSIPS-Users] Command opensipsctl dialplan reload randomly hangs

2010-04-29 Thread DanB
Hey Bogdan,

Hereby some more tests (I should mention that I cannot block on demand
the fifo, it simply randomly blocks, so I must be lucky when I am
trying to reproduce it).

Based on ps the cpu and memory consuption do not increase during the
hang (CPU:0.0  Memory:1.0).

Ta,
DanB

Log of the actions:
---

Before reload:

sip1:~# opensipsctl ps|grep FIFO

Process::  ID=13 PID=26368 Type=MI FIFO

sip1:~# ps uww -p 26368

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

opensips 26368  0.0  1.0 1147236 10788 ?   S07:30   0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 1024 -u opensips -g
opensips

sip1:~#



During hanging reload:

sip1:~# ps uww -p 26368

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

opensips 26368  0.0  1.0 1147644 11040 ?   R07:30   0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 1024 -u opensips -g
opensips


After reload interrupted with crtl+c and /etc/init.d/opensips restart


sip1:~# ps uww -p 26368

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

sip1:~# opensipsctl ps|grep FIFO

Process::  ID=13 PID=26716 Type=MI FIFO

sip1:~# ps uww -p 26716

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

opensips 26716  0.0  0.1 1147164 1988 ?S14:59   0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 1024 -u opensips -g
opensips

On Mon, Apr 26, 2010 at 12:25 PM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
 Hi Dan,

 Your descriptions point to a blocked fifo process. Blocking maybe
 because of some internal locking (you see 99% cpu usage) or some I/O
 (normal cpu usage).

 So, do the followings:

 1) do opensipsctl fifo ps to see the PID of the fifo process
 2) make fifo to block
 3) check if the fifo process (by pid) is there - if yes, see how much
 cpu it uses and try to attache with gdb to it to get a backtrace.

 Regards,
 Bogdan

 DanB wrote:
 Hey Bogdan,

 Thanks for coming back so fast.

 There was no error reported neither on console nor in the syslog
 (debug 7). I will need to check for dead process since all I could
 spot was no reply back and console hanging, and be able to stop it
 only with Ctrl+C. After Ctrl+C could not get the any other opensipsctl
 commands to work.
 Will need to wait few days more to know about dead process.

 DanB

 On Thu, Apr 22, 2010 at 6:55 PM, Bogdan-Andrei Iancu
 bog...@voice-system.ro wrote:

 Hi Dan,

 Did you notice any error from the fifo process during the reload ? it
 may be something related to locking (during reload) of the table - this
 may affect all the other processes.

 So, any errors? any dead processes (like fifo one) ?

 Regards,
 Bogdan

 DanB wrote:

 Hey Guys,

 I have noticed the opensipsctl dialplan reload command randomly
 hanging, sometimes even the server itself becoming non responsible,
 other times reloading the dialplan into memory but not reporting
 anything on console, the last one becoming unusable until server
 restart. This happened in the past as well but with the traffic
 increase, it becomes more and more annoying. I suspect the same bug
 which was present in the past with fifo hanging.
 I should mention that I got about 2000 records in the dialplan table,
 so I would say not that much loaded.

 The version I am running:
 sip1:/home/employee/dan# opensips -V
 version: opensips 1.6.1-notls (x86_64/linux)
 flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
 SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
 MAX_URI_SIZE 1024, BUF_SIZE 65535
 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
 svnrevision: 2:6509M
 @(#) $Id: main.c 6169 2009-09-22 12:48:37Z bogdan_iancu $
 main.c compiled on 14:43:30 Jan 11 2010 with gcc 4.3.2


 All I could find in the logs was database reconnection in the case of
 hang but no error or something else reported (running debug 7).
 Bellow some of the log:
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:mi_fifo:mi_fifo_server: entered consume
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:mi_fifo:mi_fifo_server:  done consume
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]: DBG:dialplan:dp_load_db: 
 init
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 INFO:db_mysql:db_mysql_submit_query: disconect event for 0x77f060
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 INFO:db_mysql:reset_all_statements: reseting all statements on
 connection: (0x77fd18) 0x77f060
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_connect: opening connection:
 mysql://:x...@192.168.11.253/sipeandb
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_connect: connection type is 192.168.11.253 via
 TCP/IP

Re: [OpenSIPS-Users] Command opensipsctl dialplan reload randomly hangs

2010-04-23 Thread DanB
Hey Bogdan,

Thanks for coming back so fast.

There was no error reported neither on console nor in the syslog
(debug 7). I will need to check for dead process since all I could
spot was no reply back and console hanging, and be able to stop it
only with Ctrl+C. After Ctrl+C could not get the any other opensipsctl
commands to work.
Will need to wait few days more to know about dead process.

DanB

On Thu, Apr 22, 2010 at 6:55 PM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
 Hi Dan,

 Did you notice any error from the fifo process during the reload ? it
 may be something related to locking (during reload) of the table - this
 may affect all the other processes.

 So, any errors? any dead processes (like fifo one) ?

 Regards,
 Bogdan

 DanB wrote:
 Hey Guys,

 I have noticed the opensipsctl dialplan reload command randomly
 hanging, sometimes even the server itself becoming non responsible,
 other times reloading the dialplan into memory but not reporting
 anything on console, the last one becoming unusable until server
 restart. This happened in the past as well but with the traffic
 increase, it becomes more and more annoying. I suspect the same bug
 which was present in the past with fifo hanging.
 I should mention that I got about 2000 records in the dialplan table,
 so I would say not that much loaded.

 The version I am running:
 sip1:/home/employee/dan# opensips -V
 version: opensips 1.6.1-notls (x86_64/linux)
 flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
 SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
 MAX_URI_SIZE 1024, BUF_SIZE 65535
 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
 svnrevision: 2:6509M
 @(#) $Id: main.c 6169 2009-09-22 12:48:37Z bogdan_iancu $
 main.c compiled on 14:43:30 Jan 11 2010 with gcc 4.3.2


 All I could find in the logs was database reconnection in the case of
 hang but no error or something else reported (running debug 7).
 Bellow some of the log:
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:mi_fifo:mi_fifo_server: entered consume
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:mi_fifo:mi_fifo_server:  done consume
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]: DBG:dialplan:dp_load_db: init
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 INFO:db_mysql:db_mysql_submit_query: disconect event for 0x77f060
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 INFO:db_mysql:reset_all_statements: reseting all statements on
 connection: (0x77fd18) 0x77f060
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_connect: opening connection:
 mysql://:x...@192.168.11.253/sipeandb
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_connect: connection type is 192.168.11.253 via
 TCP/IP
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_connect: protocol version is 10
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_connect: server version is 5.0.51a-24+lenny1-log
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 INFO:db_mysql:db_mysql_submit_query: re-connected successful for
 0x77f060
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:core:db_new_result: allocate 48 bytes for result set at 0x784258
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:core:db_allocate_columns: allocate 224 bytes for result columns at
 0x7842a0
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7842e0)[0]=[dpid]
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7842f0)[1]=[pr]
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784300)[2]=[match_op]
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784310)[3]=[match_exp]
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784320)[4]=[match_len]
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784330)[5]=[subst_exp]
 Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299

[OpenSIPS-Users] Command opensipsctl dialplan reload randomly hangs

2010-04-22 Thread DanB
Hey Guys,

I have noticed the opensipsctl dialplan reload command randomly
hanging, sometimes even the server itself becoming non responsible,
other times reloading the dialplan into memory but not reporting
anything on console, the last one becoming unusable until server
restart. This happened in the past as well but with the traffic
increase, it becomes more and more annoying. I suspect the same bug
which was present in the past with fifo hanging.
I should mention that I got about 2000 records in the dialplan table,
so I would say not that much loaded.

The version I am running:
sip1:/home/employee/dan# opensips -V
version: opensips 1.6.1-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:6509M
@(#) $Id: main.c 6169 2009-09-22 12:48:37Z bogdan_iancu $
main.c compiled on 14:43:30 Jan 11 2010 with gcc 4.3.2


All I could find in the logs was database reconnection in the case of
hang but no error or something else reported (running debug 7).
Bellow some of the log:
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:mi_fifo:mi_fifo_server: entered consume
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:mi_fifo:mi_fifo_server:  done consume
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]: DBG:dialplan:dp_load_db: init
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
INFO:db_mysql:db_mysql_submit_query: disconect event for 0x77f060
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
INFO:db_mysql:reset_all_statements: reseting all statements on
connection: (0x77fd18) 0x77f060
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_connect: opening connection:
mysql://:x...@192.168.11.253/sipeandb
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_connect: connection type is 192.168.11.253 via
TCP/IP
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_connect: protocol version is 10
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_connect: server version is 5.0.51a-24+lenny1-log
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
INFO:db_mysql:db_mysql_submit_query: re-connected successful for
0x77f060
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:core:db_new_result: allocate 48 bytes for result set at 0x784258
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: 8 columns returned from the query
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:core:db_allocate_columns: allocate 224 bytes for result columns at
0x7842a0
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7842e0)[0]=[dpid]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7842f0)[1]=[pr]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784300)[2]=[match_op]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784310)[3]=[match_exp]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784320)[4]=[match_len]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784330)[5]=[subst_exp]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784340)[6]=[repl_exp]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784350)[7]=[attrs]
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:db_mysql:db_mysql_fetch_result: converting row 0 of 2042 count 500
Apr 22 14:27:19 sip1 /usr/sbin/opensips[16299]:
DBG:core:db_allocate_rows: allocate 136000 bytes for result rows and
values at 0x79c5d8

Ta,
DanB

___
Users mailing list
Users@lists.opensips.org

Re: [OpenSIPS-Users] UAC_REDIRECT : get_redirectsdoesnot rewritehost

2009-12-02 Thread DanB
Hey Bogdan,

Yes, I can reproduce it (not only sometimes but all the times with my
config and version of software).

I remember you asking Julian if he can provide you access inside the
box. Let me know if you still want it and I will arrange a box as a
test environment for you.

Ta,
DanB

On Tue, Dec 1, 2009 at 9:51 PM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
 Hi Dan,

 yes, I remember about the discussion with Julian and we tried to find
 the cause but with no too much luck - it was impossible to reproduce
 (for me) and to debug it.

 So, to see where we start from - can you produce this behaviour ?

 Regards,
 Bogdan

 DanB wrote:
 Hey Guys,

 I found this issue posted back in August, and the last message I could find 
 was:
 http://www.openser.org/pipermail/users/2009-August/007680.html

 I am experiencing similar issues with uac_redirect, in the form of
 get_redirects(*:*) not being able to rewrite the host but just the
 user part of ruri.

 Can u please update me whether any other progress was made?

 I am running:
 opensips -V
 version: opensips 1.5.3-notls (x86_64/linux)
 flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
 SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
 MAX_URI_SIZE 1024, BUF_SIZE 65535
 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
 svnrevision: 2:6200M
 @(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
 main.c compiled on 14:04:07 Oct  5 2009 with gcc 4.3.2

 Ta,
 DanB

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users




 --
 Bogdan-Andrei Iancu
 www.voice-system.ro


 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] UAC_REDIRECT : get_redirectsdoesnot rewritehost

2009-11-29 Thread DanB
Hey Guys,

I found this issue posted back in August, and the last message I could find was:
http://www.openser.org/pipermail/users/2009-August/007680.html

I am experiencing similar issues with uac_redirect, in the form of
get_redirects(*:*) not being able to rewrite the host but just the
user part of ruri.

Can u please update me whether any other progress was made?

I am running:
opensips -V
version: opensips 1.5.3-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:6200M
@(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
main.c compiled on 14:04:07 Oct  5 2009 with gcc 4.3.2

Ta,
DanB

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Import

2009-09-17 Thread DanB
Hey Philipp,

I would recommend you adapting your rates plan to the one CDRTool
understands ( for more info see 'doc/RATING.txt' ), and use the
'scripts/importRatingTables.php' from CDRTool to import them
afterwards.

DanB

On Wed, Sep 16, 2009 at 2:31 PM, Philipp Hoffmann
philipp-hoffm...@arcor.de wrote:

 Hi list,

 I want to use CDRTool and Call Controll to billing congestions
 over OpenSIPS.

 We have already created a rates plan in a csv file, like this:

 Name;Price;BillingIntervall;Prefix
 Germany;0.01;60/60;+49
 Germany-Mobilphone;0.12;60/60;+49172,+49173,+49174,+49175

 Can you tell me a simple method (script) to import this in CDRTool?
 Is it posible to make 10 calls at the same time over one prepaid card?

 Thank you,
 Philipp




 Comedy-Battle! Jetzt ablachen und voten! Neue Comedians, Spontanhumoristen 
 und Nachwuchs-Spaßmacher machen gute Laune - bestimmen Sie den Wochensieger!
 http://comedy-battle.arcor.de/

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRTool billing based on routes taken

2009-09-17 Thread DanB
Hi Ashwini,

I personally use a trick for that, by overwriting the SourceIP with
the DestinationIP. Works for me!

DanB

On Thu, Sep 17, 2009 at 7:48 AM, ASHWINI NAIDU ashwini.na...@gmail.com wrote:
 hi all,
     I wanted to know if the rates can be applied based on the route taken by
 the sip call.


 User A taking route 1 should be charged 0.1
 User B taking route 2 should be charged 0.2
 User C taking route 3 should be charged 0.5

 Does anyone know how this can be done using CDRTool.


 --
 Thanking You,
 Ashwini BR Naidu

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Fwd: Storing modules parameters on AVP, as much as I can

2009-07-23 Thread DanB
Sorry, I forgot to put yesterday users list  on cc.
For the sake of transparency, doing it now ;-).

DanB

-- Forwarded message --
From: DanB d...@sms4sip.com
Date: Wed, Jul 22, 2009 at 10:34 AM
Subject: Re: [OpenSIPS-Users] Storing modules parameters on AVP, as much as
I can
To: Ricardo Martins rpopp...@gmail.com


Hi Ricardo,
With the current architecture, you cannot load the params from the database.
The only trick you can do is write your own opensips.cfg script generator
which should read your database and edit opensips.cfg before starting up the
server (outdated example at http://www.sipwise.com/). Any parameter you will
change, it will require you to restart the opensips server. Depending on
your specific needs, should be possible to implement most of the flexibility
you want for your administrators out of avps or other database stored
settings but again, its all based on your specific needs.

DanB


On Tue, Jul 21, 2009 at 10:47 PM, Ricardo Martins rpopp...@gmail.comwrote:

 Hi all! Do anybody knows if there is a trick to store the modules
 parameters on database/avps? I want to give the opensips administrator
 all the flexibility I can without having to edit cfg text file.

 I know that there is some specific parameters where you can do that like
 fr_inv_timer or fr_timer for tm module but I'm talking about storing
 other parameters that don't have an specific avp enable mode like T1 and
 T2, for example.

 Do anybody has any clue?

 Regards! Ricardo.

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRTool does not identify by IP origin from OpenSips

2009-07-22 Thread DanB
Hi Alberto,
By default CDRTool takes the gateway parameter out of Source IP (nicely
explained also in the doc/RATING.TXT) and if you don't modify the defaults,
out of radacct.SourceIP column.

In order to identify the gateway, you need to enforce that SourceIP inside
opensips script to whatever IP you want to be used as your gateway.
Example of params in opensips.cfg:
modparam(acc, radius_extra,Source-IP=$avp(s:mygtw))

Another trick you can use is to write your own radius sql query which places
the SourceIP from another radius attribute received.

Cheers,
DanB

On Tue, Jul 21, 2009 at 9:44 PM, Alberto Listas lis...@b2br.net wrote:

  Hi,

 I am having a difficulty with the rating in CDRTool. When I telnet and give
 this command:

 ShowPrice From=sip:005521810...@10.0.0.4 sip%3a005521810...@10.0.0.4 To=
 sip:00552181000...@10.0.0.1 sip%3a00552181000...@10.0.0.1Gateway=10.0.0.4 
 Duration=30
 (IPs where changed)

 The rating engine identifies the customer by the gateway and rates
 correctly.

 When the call comes from the OpenSips it doesn't identify the customer and
 uses
 the default profile:

 Start time: 2009-07-21 14:55:24
 Stop time: 2009-07-21 14:55:59
 Method:Invite from :
 From:5521083200...@10.0.0.4 from%3a5521083200...@10.0.0.4
 Domain:10.0.0.4
 To (dialed URI):005521810...@10.0.0.4
 Canonical URI: 005521810...@10.0.0.1
 Next hop URI:005521810...@10.0.0.2 uri%3a005521810...@10.0.0.2
 Destination: BRAZIL CELL (55218)
 Billing Party:5521810...@10.0.0.4 party%3a5521810...@10.0.0.4
 Reseller:
 Duration: 35 s
 App: audio
 Destination: 55218
 Customer: default
 Connect: 0. ..

 Should I set some different variable to FreeRadius for it to identify the
 GATEWAY?

 Thanks,

 Alberto

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRTool - increasing max_allowed_packet

2009-07-10 Thread DanB
Brett,
since I am not a php programmer,  was looking for some stored configuration
setting instead of running the command at starting of each mysql
session(place where I don't have access as a user).
If that is what is needed, then the CDRTool should do it when connecting to
the mysql sessions (or at least this is what docs suggesting it).

Thx,
DanB

On Thu, Jul 9, 2009 at 4:29 PM, Brett Nemeroff br...@nemeroff.com wrote:

 I would think that those params would change it for libmysqlclient. Have
 you tried it?


 On Thu, Jul 9, 2009 at 3:12 AM, DanB d...@sms4sip.com wrote:

 Hi Brett,
 Thanks for the link.

 I see (found on google many links too) how to configure both mysql-server
 or mysql_cli_client's max_allowed_packet but for some reason I miss how to
 configure libmysqlclient one (the one php is using). Is this something that
 I miss from the link you have sent me?

 Ta,
 DanB


 On Wed, Jul 8, 2009 at 7:37 PM, Brett Nemeroff br...@nemeroff.comwrote:

 Quick google got me this:
 http://www.astahost.com/info.php/Max_allowed_packet-Mysql_t2725.html

 shrug ??
 -Brett


 On Wed, Jul 8, 2009 at 11:34 AM, DanB d...@sms4sip.com wrote:

 Adrian,
 I spent quite a long time searching for a way to modify this setting,
 but could not find it anywhere.

 One extra info I found was that it was not the amount of rows returned
 which generated the error but the information in one row, so I have managed
 as work-around to alter some information inside, and the error is now gone.

 Regards,
 DanB


 On Tue, Jul 7, 2009 at 11:23 AM, Adrian Georgescu 
 a...@ag-projects.comwrote:

 Dan
 I did not see this yet but it sounds like a PHP setting, you may want
 to check your php.ini.
 Adrian

 On Jul 6, 2009, at 12:49 PM, DanB wrote:

 Hey Guys,
 I have recently discovered a problem with one of my CDRTool
 installations.
 I have about 2.2 mil destinations in cdrtool.destinations table and
 when trying to load them into cdrtool memory, the process fails with:
 Got a packet bigger than 'max_allowed_packet' bytes (1153).

 Can u please advice how to increase this value?

 Ta,
 DanB
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users





 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRTool - increasing max_allowed_packet

2009-07-09 Thread DanB
Hi Brett,
Thanks for the link.

I see (found on google many links too) how to configure both mysql-server or
mysql_cli_client's max_allowed_packet but for some reason I miss how to
configure libmysqlclient one (the one php is using). Is this something that
I miss from the link you have sent me?

Ta,
DanB

On Wed, Jul 8, 2009 at 7:37 PM, Brett Nemeroff br...@nemeroff.com wrote:

 Quick google got me this:
 http://www.astahost.com/info.php/Max_allowed_packet-Mysql_t2725.html

 shrug ??
 -Brett


 On Wed, Jul 8, 2009 at 11:34 AM, DanB d...@sms4sip.com wrote:

 Adrian,
 I spent quite a long time searching for a way to modify this setting, but
 could not find it anywhere.

 One extra info I found was that it was not the amount of rows returned
 which generated the error but the information in one row, so I have managed
 as work-around to alter some information inside, and the error is now gone.

 Regards,
 DanB


 On Tue, Jul 7, 2009 at 11:23 AM, Adrian Georgescu 
 a...@ag-projects.comwrote:

 Dan
 I did not see this yet but it sounds like a PHP setting, you may want to
 check your php.ini.
 Adrian

 On Jul 6, 2009, at 12:49 PM, DanB wrote:

 Hey Guys,
 I have recently discovered a problem with one of my CDRTool
 installations.
 I have about 2.2 mil destinations in cdrtool.destinations table and when
 trying to load them into cdrtool memory, the process fails with:
 Got a packet bigger than 'max_allowed_packet' bytes (1153).

 Can u please advice how to increase this value?

 Ta,
 DanB
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users





 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRTool - increasing max_allowed_packet

2009-07-08 Thread DanB
Adrian,
I spent quite a long time searching for a way to modify this setting, but
could not find it anywhere.

One extra info I found was that it was not the amount of rows returned which
generated the error but the information in one row, so I have managed as
work-around to alter some information inside, and the error is now gone.

Regards,
DanB


On Tue, Jul 7, 2009 at 11:23 AM, Adrian Georgescu a...@ag-projects.comwrote:

 Dan
 I did not see this yet but it sounds like a PHP setting, you may want to
 check your php.ini.
 Adrian

 On Jul 6, 2009, at 12:49 PM, DanB wrote:

 Hey Guys,
 I have recently discovered a problem with one of my CDRTool installations.
 I have about 2.2 mil destinations in cdrtool.destinations table and when
 trying to load them into cdrtool memory, the process fails with:
 Got a packet bigger than 'max_allowed_packet' bytes (1153).

 Can u please advice how to increase this value?

 Ta,
 DanB
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] CDRTool - increasing max_allowed_packet

2009-07-06 Thread DanB
Hey Guys,
I have recently discovered a problem with one of my CDRTool installations.
I have about 2.2 mil destinations in cdrtool.destinations table and when
trying to load them into cdrtool memory, the process fails with:
Got a packet bigger than 'max_allowed_packet' bytes (1153).

Can u please advice how to increase this value?

Ta,
DanB
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Radius Fallback

2009-07-01 Thread DanB
Guys,
It seems that something is wrong when handling radius fall-back with
radiusclient-ng, at least in my case.

I have tried the following scenario:
OpenSIPS with radiusclient-ng and the last one configured with more than one
radius server.

When the timeout is reached, the radiusclient will send it's packets to the
second radius server and receive Auth OK from the second one. However
opensips will still reject the auth of the UA and place the following line
in the logs:
rc_send_server: no reply from ip_of_first_server:1812

I was wondering if any of you have managed to implement such scenario with
success. It looks quite useful from the HA point of view (without using
linux heartbeat to keep a host as fallback).

Ta,
DanB
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] opensips - hiding interconnection information

2009-06-30 Thread DanB
Hi Julien,
For such scenarios you would need a B2BUA ( I personally use B2bua.org
but Yate, Freeswitch,  Asterisk can do it too).
One more concern with carrier traffic would be the SDP body, which can
reveal information about the originator too.

Cheers,
DanB

On Wed, Jul 1, 2009 at 7:08 AM, Julien Chavanton j...@atlastelecom.comwrote:

  Hi, I have a business usage security concern.

 If we take this scenario :

 carrierA --SIP-- carrierB --SIP-- carrierC

 CarrierB may not want carrierC to find out about carrierA (IP address)

 I beleive record-routing and via header can provide
 unwanted information,
 any suggestion/options on how we can deal with such requirements using a
 SIP proxy as openSIPS ?

 Regards,
 Julien

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] CDRTool - ReloadRatingTables and new destinations

2009-03-17 Thread DanB
Hey Adrian,

I have retested with the new version and now works like a charm. I noticed
that also the destinations refresh is instant, no longer depending on
normalize.php script.

Thanks for all your efforts!

Cheers,
DanB

On Mon, Mar 16, 2009 at 6:54 PM, Adrian Georgescu a...@ag-projects.comwrote:

 Hi Dan,

 I have made a change to fix your problem. Pl upgrade to 6.7.4 and let me
 know if you still have problems with reloading the tables.

 Regards,
 Adrian

 On Mar 16, 2009, at 2:16 PM, Dan-Cristian Bogos wrote:

 Adrian,

 I understand all these, but I think you don't get me.

 Please do me a favor, and let me know if you get the same behavior like
 me in your lab:

 1. Delete a destination from cdrtool.destinations table.
 2. Issue a ShowPrice command over telnet which should match the
 destination you just deleted. Nothing should happen, I understand until
 you ReloadRatingTables and run normalize.php.
 3. Issue a ReloadRatingTables and run normalize.php.
 4. Run the same ShowPrice over telnet and you will see that your
 destination is still showing up in the results (at least this is what is
 happening to me). This scenario you can repeat when adding new
 destinations or modifying the existing ones.

 Ta,
 DanB

 On Mon, 2009-03-16 at 14:03 +0100, Adrian Georgescu wrote:

 Only the normalization process reinitializes the changed data. If you

 run telnet and issue manually the ShowPrice command nothing happens

 until a normalization process runs. If you would check for every

 ShowOPrice command if a reload is required  it will affect the speed

 of the engine.



 Adrian




 On Mar 16, 2009, at 1:44 PM, Dan-Cristian Bogos wrote:


 I understand that, but I did not normalize anything in my actions. I

 just played with the ShowPrice over telnet (adding and deleting

 destinations directly from the database, and then running

 ReloadTables

 over telnet interface).


 DanB


 On Mon, 2009-03-16 at 13:39 +0100, Adrian Georgescu wrote:

 A call once normalized is stored in the radiust table and remains

 unchanged unless you re-normalize the calls that you wish to have

 updated. So changing rating tables does not have any influence

 upon

 previously normalized calls, they remain with the previous values.



 Adrian





 On Mar 16, 2009, at 12:21 PM, Dan-Cristian Bogos wrote:



 Adrian,


 On Mon, 2009-03-16 at 11:50 +0100, Adrian Georgescu wrote:

 This is a problem unrelated to the destinations reload. Most

 likely

 you did not create the correct rating table data.


 I am not sure if it is due to correct rating table data (should

 see

 no

 Span price in that case I think), so bear with me to read the

 logs.


 Here comes a more detailed usage scenario:


 I have added a new number inside destination table (like you

 said,

 no

 rating defined, just the destination one).


 * First query will identify maybe correctly the destination 31

 (since

 the reload of rating tables was not yet done and the new

 destination

 is

 not yet in the memory).


 ShowPrice from=...@itsyscom.com gateway=10.10.10.1 Duration=59

 To=003167608

 0.1200

 Duration: 60 s

   App: audio

 Destination: 31

  Customer: default

  Increment: 60 s

   Connect: 0.

 StartTime: 2009-03-16 10:08:45

 --

  Span: 1

  Duration: 60 s

 ProfileId: DEFAULT / weekday

RateId: DEFAULT / 0-24h

  Rate: 0.1200 / 60 s

 Price: 0.1200


 reloadratingtables

 1


 * Second and third attempt are after reloadratingtables succeed

 -

 saw it

 in mysql.log. Notice that the destination identified is still

 31.


 ShowPrice from=...@itsyscom.com gateway=10.10.10.1 Duration=59

 To=003167608

 0.1200

 Duration: 60 s

   App: audio

 Destination: 31

  Customer: default

  Increment: 60 s

   Connect: 0.

 StartTime: 2009-03-16 10:09:52

 --

  Span: 1

  Duration: 60 s

 ProfileId: DEFAULT / weekday

RateId: DEFAULT / 0-24h

  Rate: 0.1200 / 60 s

 Price: 0.1200


 ShowPrice from=...@itsyscom.com gateway=10.10.10.1 Duration=59

 To=003167608

 0.1200

 Duration: 60 s

   App: audio

 Destination: 31

  Customer: default

  Increment: 60 s

   Connect: 0.

 StartTime: 2009-03-16 10:18:20

 --

  Span: 1

  Duration: 60 s

 ProfileId: DEFAULT / weekday

RateId: DEFAULT / 0-24h

  Rate: 0.1200 / 60 s

 Price: 0.1200


 Connection closed by foreign host.


 * Here I have restarted the cdrtool with /etc/init.d/cdrtool

 restart.

 Now the destination is correctly identified as 3167608 (full

 length), of course without Span section since I have no rating

 defined

 yet.


 DellLaptop:/usr/local/src/cdrtool# telnet localhost 9094

 Trying 127.0.0.1...

 Connected to localhost.

 Escape character is '^]'.

 ShowPrice from=...@itsyscom.com gateway=10.10.10.1 Duration=59

 To=003167608

 0

 Duration: 60 s

   App: audio

 Destination: 3167608

  Customer: default

  Increment: 60 s



 Is my logic broken?

 Same thing happens if I

Re: [OpenSIPS-Users] CDRTool - ReloadRatingTables and new destinations

2009-03-16 Thread DanB
Hey Adrian,

thanks for the quick reaction.

Here it comes what I found out after tests (could be I am doing something
wrong):

* ReloadRatingTables produces a reload of destination table now (during
normalize.php execution, so not real-time but depending on how often this
script is run in cron).
* Even when the tables are reloaded, the new destinations are not processed,
therefore when querying ShowPrice I will get still the initial values (the
one received on cdrtool startup). So the result is that I am
adding/deleting/modifying destinations, but no effect in the ShowPrice.

My version:

version
CDRTool version 6.7.3


Ta,
DanB


On Sun, Mar 15, 2009 at 9:56 AM, Adrian Georgescu a...@ag-projects.comwrote:

 Hello Dan,
 I found the bug that affected the rating engine, I fixed it. You should
 upgrade to 6.7.3 version.
 Regards,
 Adrian

 On Mar 14, 2009, at 7:12 PM, Dan-Cristian Bogos wrote:

 Folks,

 some strange behavior I have noticed in CDRTool: both ReloadRatingTables
 and /etc/init.d/cdrtool reload are strangely removing the destinations
 and destinations.sip from cdrtool.memcached table, therefore I have the
 feeling that this is why ShowPrice does newer show newer updates in the
 destinations table.

 
 version
 CDRTool version 6.7.2
 

 The only way I made CDRTool work with newer destinations inserted into
 destinations table was restarting it. Is this behavior wanted?
 Also, ShowPrice used to insert also destination name, other than dest_id
 inside Destination field, but no longer there.


 Ta,
 DanB


 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users