Re: [OpenSIPS-Users] substitute variable names within variables

[Razvan Crainea]

Hi, Jayesh!

Unfortunately you can't do this in OpenSIPS. The 'var' pseudo-variable 
only accepts a constant name, like 'media'. There are some variables, 
like AVP, that can also receive a variable name ( ex: $avp($avp(name)) 
), but note they can only receive a pseudo-variable, not a format ( like 
$avp(media$avp(name)) ). I think this is only supported in the latest 
changes to the 'stat' pseudo-variable.
Implementing a generic solution is not that feasible, as it requires 
changes in both pvar interface and each variable implementation.


Regards,
Ra(zvan

On 12/27/2012 08:52 PM, Jayesh Nambiar wrote:

Hi,
I define some values using the varset parameters of cfgutils module.
modparam("cfgutils", "varset", "media1=1.2.3.4")
modparam("cfgutils", "varset", "media2=4.3.2.1")
modparam("cfgutils", "varset", "media3=5.6.7.8")

I need a logic to dynamically select the the variables. Say for example:
I select a value from DB and store it in an AVP say $avp(db_val) which 
I know can be either 1,2 or 3. Based on that value, I need to select 
among variables media1, media2 or media3.
I need to find a way where I can substitute the avp(db_val) value in 
the name of the variable. Basically something like this:

$avp(variable_to_be_used) = $var(media$avp(db_val))
So here if $avp(db_val) is 1, avp(variable_to_be_used) becomes 
$var(media1) which will be 1.2.3.4


Is something like this possible or allowed? Is there an alternative to 
do something similar dynamically !! I know, I cud have stored those 
values in DB and retrieved directly but I am looking at this feature 
for many other purposes too !!


Any help is much appreciated. Thanks,

--- 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] append_hf not working

[Razvan Crainea]

Hi, Peter!

Using the 'append_hf' function, the header is inserted in the Request 
message, not in the Reply. If you want to append a header to the Reply 
message, you have to use the 'append_to_reply' function [1].


[1] http://www.opensips.org/html/docs/modules/1.8.x/sipmsgops#id249124

Regards,
Ra(zvan

On 12/23/2012 10:52 PM, peter ness wrote:

Hi

I have done the minimal code for testing.


if (method=="INVITE") {
  
  append_hf("X-TEST: test test test\r\n");
  
  sl_send_reply("181","blah blah");
  
  rewritehostport( "xxx.xxx.xxx.xxx:5080" );

  if (!t_relay()) {
  sl_reply_error();
  return;
  }

  }


I see the "blah blah" in the header but no sign of "X-TEST: test test test"
Could it be that I am missing a required module or parameter set up?

  
thanks



- Original Message -
From: Bogdan-Andrei Iancu
Sent: 12/19/12 07:31 PM
To: peter ness, users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] append_hf not working

Hi,

and are you sure the script processing is getting to that append_hf() ?
put an xlog("before append\n"); before the append_hf line to check.

Regards,

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


On 12/19/2012 05:59 PM, peter ness wrote:

Hi Bogdan

I am setting it like this

append_hf("X-ACCOUNT: $avp(accnum)\r\n");

There is no effect on the sip headers

Regards

Abdul


- Original Message -
From: Bogdan-Andrei Iancu
Sent: 12/19/12 05:36 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] append_hf not working

Hi Peter,

What are you trying to do and how exactly fails (error, nothing happens,
wrong change, etc) ?

Regarding the note you find, that's about 1.8 and higher versions.

Regards,

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


On 12/19/2012 04:06 AM, peter ness wrote:

I am trying to work out why append_hf is not working for me. I am using version 
1.7.0

I have seen this note on the doc
Note: all SIP-aware functions like insert_hf, append_hf or codec operations 
have been moved to the sipmsgops module.

However I can't see sipmsgops in the module src folder.? Is this info relevent 
to my version?




___
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] Managing Opensipsctl for different instances on same server

[Razvan Crainea]

Hi, Jayesh!

No, it won't affect performance in any way, as each opensipsctl tool is 
a simple script that will communicate with different OpenSIPS instances.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/29/2012 02:40 PM, Jayesh Nambiar wrote:

Hi Razvan,
Thank you very much. This was exactly what I was looking for.
Just recollecting the other part; will this method affect the 
performance of opensips in any ways. Since all these three instances 
uses the same opensips installation !!


--- Jayesh

Hello, Jayesh!

Opensipsctl uses the opensipsctlrc configuration file in order to
detect
which FIFO file it should use. If the OSIPS_FIFO parameter is not
set in
opensipsctlrc, it uses the default value of /tmp/opensips_fifo.
In order to run different instances of opensipsctl, you first have to
make sure that the opensipsctlrc file doesn't have the OSIPS_FIFO
parameter set. If it does, you can't overwrite it and the following
solution won't work. Then if you want to send for examnple the 'ps' MI
command to an OpenSIPS instance that has the /tmp/opensips_fifo_1 file
set, you should use the following code:

OSIPS_FIFO=/tmp/opensips_fifo_1 /path/to/opensipsctl fifo ps

In this way you specify opensipsctl to use a different FIFO than the
default one.

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/28/2012 02:09 PM, Jayesh Nambiar wrote:
> Hello All,
> I am using three intances of Opensips on a single server using same
> binaries and libraries. Meaning, I have configured and intalled
> opensips once and I have three init files each which starts opensips
> looking at different configuration files viz. lcr.cfg, b2b.cfg,
> proxy.cfg. Although this runs good, I have a problem in managing
them.
> The "opensipsctl" utility only monitors any one instance of
opensips.
> How is it possible to manage all instances of opensips using
this method.
> I give different fifo paths in each configuration file but I dont
> understand how to manage them differently. For example, I need
to know
> how many transactions are running on my LCR instance and at the same
> time I need to know how many users are registered on my proxy
> instance. I wanted to understand if this approach is even
recommended
> or does it have any drawbacks that I might be missing.
>
> Thanks for any suggestions in this regards,
>
> --- 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] Managing Opensipsctl for different instances on same server

[Razvan Crainea]

Hello, Jayesh!

Opensipsctl uses the opensipsctlrc configuration file in order to detect 
which FIFO file it should use. If the OSIPS_FIFO parameter is not set in 
opensipsctlrc, it uses the default value of /tmp/opensips_fifo.
In order to run different instances of opensipsctl, you first have to 
make sure that the opensipsctlrc file doesn't have the OSIPS_FIFO 
parameter set. If it does, you can't overwrite it and the following 
solution won't work. Then if you want to send for examnple the 'ps' MI 
command to an OpenSIPS instance that has the /tmp/opensips_fifo_1 file 
set, you should use the following code:


OSIPS_FIFO=/tmp/opensips_fifo_1 /path/to/opensipsctl fifo ps

In this way you specify opensipsctl to use a different FIFO than the 
default one.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/28/2012 02:09 PM, Jayesh Nambiar wrote:

Hello All,
I am using three intances of Opensips on a single server using same 
binaries and libraries. Meaning, I have configured and intalled 
opensips once and I have three init files each which starts opensips 
looking at different configuration files viz. lcr.cfg, b2b.cfg, 
proxy.cfg. Although this runs good, I have a problem in managing them. 
The "opensipsctl" utility only monitors any one instance of opensips. 
How is it possible to manage all instances of opensips using this method.
I give different fifo paths in each configuration file but I dont 
understand how to manage them differently. For example, I need to know 
how many transactions are running on my LCR instance and at the same 
time I need to know how many users are registered on my proxy 
instance. I wanted to understand if this approach is even recommended 
or does it have any drawbacks that I might be missing.


Thanks for any suggestions in this regards,

--- 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] ERROR:nathelper:send_rtpp_command: can't send command to a RTP proxy

[Razvan Crainea]

Hi, Arjun!

Are OpenSIPS and RTPProxy on the same machine? Also you should double 
check your firewall isn't blocking the 7890 port on localhost.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/24/2012 11:01 AM, Arjun Shankar K S wrote:

Hi All,

Greeting to everyone,

I have setup openSIPS and RTP Proxy. My opensips is behind a NAT. I 
gave the below command to start the RTP Proxy,


./rtpproxy --l my_public_IP_address --s udp:127.0.0.1:7890 --F

When I start my openSIPS, I get the following error in my syslog,

#/usr/local/sbin/opensips[1292]: ERROR:nathelper:send_rtpp_command: 
can't send command to a RTP proxy
#/usr/local/sbin/opensips[1293]: ERROR:nathelper:send_rtpp_command: 
can't send command to a RTP proxy
#/usr/local/sbin/opensips[1291]: ERROR:nathelper:send_rtpp_command: 
proxy  does not respond, disable it
#/usr/local/sbin/opensips[1291]: WARNING:nathelper:rtpp_test: can't 
get version of the RTP proxy


Actually my syslog is filled up with this error.

Any help is very much appreciated since I am struck up with this error.

Thanks,
Arjun


___
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] opensips and rtpproxy

[Razvan Crainea]

  
  
Hi, Denis!

Try to use the same socket for both rtpproxy module and application:

modparam("nathelper", "rtpp_notify_socket", "tcp:127.0.0.1:")
rtpproxy -n tcp:127.0.0.1:


Regards,
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com

On 05/23/2012 05:13 PM, dpa wrote:

  
  
  
  
  
  
Hello Răzvan
 
Thank you for replay. 
But one more question 
In man for rtpproxy I read “-n timeout_socket….
The socket should be created by another  application,
preferably before starting rtpproxy….”
So as I understand “rtpp_notify_socket” should be like  modparam("nathelper", "rtpp_notify_socket", "tcp:localhost:")
and after this rtpproxy should be started with
“–n tcp:1.1.1.1:” where 1.1.1.1 – ip of opensips
serever.
Am I right?
 

  
From:
users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf
  Of Razvan Crainea
Sent: Wednesday, May 23, 2012 5:47 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips and
rtpproxy
  

 
Hi,
  Denis!

The socket can be UNIX or TCP according to the
  documentation[1].

[1] http://www.opensips.org/html/docs/modules/devel/rtpproxy.html#id250454
  
  
Regards,

  
--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com

  On 05/23/2012 04:11 PM, dpa wrote: 

Hello!
Opensips 1.6.4-2
 
There is one question. 
rtpp_notify_socket
   may be only unix socket? Or I can use UPD or
TCP too?
 
Thank you for any help
 
 
 




___
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] opensips and rtpproxy

[Razvan Crainea]

  
  
Hi, Denis!
  
  The socket can be UNIX or TCP according to the documentation[1].
  
  [1] http://www.opensips.org/html/docs/modules/devel/rtpproxy.html#id250454



  Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com

On 05/23/2012 04:11 PM, dpa wrote:

  
  
  
  
  
Hello!
Opensips 1.6.4-2
 
There is one question. 
rtpp_notify_socket  may be only unix socket? Or I can use UPD or
TCP too?
 
Thank you for any help
 
 
 
  
  
  
  
  ___
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 vars not being sync'ed from DB to memory

[Razvan Crainea]

Hi, Mariana!

Can you check if the variables are properly flushed into the DB after 200OK?
Also, if you only want to check the direction of a sequential request, 
you could use directly the $DLG_dir [1] pseudovariable from the dialog 
module.


[1] http://www.opensips.org/html/docs/modules/1.8.x/dialog.html#id295750

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/15/2012 10:03 PM, Mariana Arduini wrote:

Hello all,

We need to perform some substitutions in the R-URI and Contact header 
in order to have the following flow working as required:


caller > opensips1 > opensips2 > callee

Currently, opensips1 stores "call_id", "caller_tag" and 
"caller_contact" Dialog variables using function store_dlg_value() on 
new INVITES, and "callee_contact" on 200 OK for the INVITES. Later, 
for sequential requests, it compares the from_tag with the caller_tag, 
accessed using fetch_dlg_value(), to find out whether it is a request 
from the caller or from the callee, and it works. Then I started 
working on failover for opensips1, and that's where I'm facing 
problems. I'm playing with "db_flush_vals_profiles" new parameter and 
"dlg_db_sync" new fifo command, both on Dialog module, in order to 
have a stand by opensips1 taking over the dialogs going on in an 
active opensips1, in case it fails. This is the test:


1) active opensips is running listening on virtual ip say 10.0.0.1
2) caller sends INVITE to 10.0.0.1, which goes to active opensips
3) active opensips is stopped and it's virtual ip set down; same 
virtual ip is set up in stand by opensips and it is started; fifo 
command dlg_db_sync is run on stand by opensips

4) caller sends BYE to 10.0.0.1, which goes to stand by opensips

After loose_route(), stand by opensips cannot fetch_dlg_value for 
"caller_tag" and the R-URI is set to 0. Then I tried the following, 
using only one opensips:


1) caller sends INVITE to opensips
2) fifo command dlg_list_ctx is run and shows all of the variables I 
stored

3) opensips is restarted and fifo command dlg_db_sync is run
4) fifo command dlg_list_ctx is run again and shows only the dialog 
info, not the variables in context


I also 
tried get_dialog_info("caller_tag","$var(caller_tag)","call_id","$ci"); and 
$dlg_val(), but yet the variables are not found:


22232: DBG:dialog:fetch_dlg_value: looking for 
22232: DBG:dialog:fetch_dlg_value: var NOT found!
22232: ERROR:core:do_assign: no value in right expression
22232: ERROR:core:do_assign: error at line: 134
22232: callid(1-5150@192.168.16.154 ) 
trying dlg_val(), caller_tag: 0

22232: DBG:core:comp_scriptvar: str 20 : uac1192.168.16.154
22232: DBG:dialog:fetch_dlg_value: looking for 
22232: DBG:dialog:fetch_dlg_value: var NOT found!
22232: ERROR:core:do_assign: no value in right expression
22232: ERROR:core:do_assign: error at line: 146
22232: callid(1-5150@192.168.16.154 ) 
trying dlg_val(), caller_contact: 0

22232: DBG:tm:t_newtran: transaction on entrance=0x
22232: DBG:core:parse_headers: flags=
22232: DBG:core:parse_headers: flags=78
22232: DBG:tm:t_lookup_request: start searching: hash=5130, isACK=0
22232: DBG:tm:matching_3261: RFC3261 transaction matching failed
22232: DBG:tm:t_lookup_request: no transaction found
22232: ERROR:core:parse_uri: uri too short: <0> (1)
22232: ERROR:core:parse_sip_msg_uri: bad uri <0>
22232: DBG:core:set_err_info: ec: 1, el: 3, ei: 'error parsing r-uri'
22232: ERROR:tm:new_t: uri invalid
22232: ERROR:tm:t_newtran: new_t failed

There is no error logs when dlg_db_sync is run. I see in the dialog 
table a column called from_tag, is there a way to get its content for 
a certain dialog? It seems the functions get_dialog_info(), 
fetch_dlg_info() and $dlg_val() only look for variables in the column 
vars.


Can anyone see other type of solution that does not involve 
storing/fetching dialog variables? I could take on that.


I'd really appreciate any help on this.

This is my cfg file:

...
modparam("dialog", "db_url", 
"postgres://opensips:opensips@opensips_db_host:5432/opensips")

modparam("dialog", "db_mode", 1)
modparam("dialog", "db_flush_vals_profiles", 1)
...
route {
...
if(is_method("INVITE")) {
create_dialog();
store_dlg_value("caller_tag", "$ft");
xlog("L_INFO","Storing caller_tag: $ft");
store_dlg_value("caller_contact", "$ct.fields(uri)");
xlog("L_INFO","Storing caller_contact: $ct.fields(uri)");
store_dlg_value("call_id", "$ci");
xlog("L_INFO","Storing call_id: $ci");
route(1);
}
...
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {

$var(caller_tag) = $dlg_val(caller_tag);
xlog("L_INFO","trying dlg_val(), caller_tag: 
$var(caller_tag)\n");


if ($ft == $var(caller_tag)) {
$var(callee_contact) = $dlg_val(callee

Re: [OpenSIPS-Users] Is OpenSIPS 1.8 still 'beta'

[Razvan Crainea]

Hi, Jacek!

OpenSIPS 1.8 version is still in beta, but the stable release is coming 
soon. You will receive an update regarding this during the next week.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/08/2012 11:42 AM, Jacek Konieczny wrote:

Hello,

OpenSIPs 1.8.0 release has been announced some a while ago, so I was
considering an upgrade, but when trying to download it I found this:

http://opensips.org/pub/opensips/1.8.0/src/opensips-1.8.0-beta_src.tar.gz

How should I understand this '-beta' suffix?

Greets,
 Jacek

___
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] Acc - Can't get db_extra_bye to work

[Razvan Crainea]

Hi, Ryan!

Unfortunately calling loose_route twice won't do the trick. You'll 
somehow have to make sure that all AVPs are populated before calling 
loose_route the first time. My suggestion is to use CacheDB to keep info 
between INVITE and BYE and fetch the info before loose_route.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 05/01/2012 07:33 PM, Ryan Bullock wrote:

Thanks for the response.

I have not tried setting them before loose_route(). I guess my example
is bad, because I need to access some dialog values before I can set
the acc variables, and my understanding is that I cannot access dlg
variables until I call loose_route (or match_dialog).

Is their a way to do both? Would it hurt to call loose_route() twice?

Regards,

Ryan

On Tue, May 1, 2012 at 1:14 AM, Razvan Crainea  wrote:

Hi, Ryan!

Have you tried to set the avp values before 'loose_route' call?

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com



On 04/28/2012 06:28 PM, Ryan Bullock wrote:

Without any success I have been trying to get some values accounted
using the 'db_extra_bye'  parameter of the acc module. However,
opensips still appears to always account the values as if they were
taken from the original INVITE transaction and not the BYE.

I have cdr accounting enabled, as well as several db_extra values.

When a BYE is received I update a few avp variables. When I xlog these
variables I can see that they are properly set, however opensips
inserts empty values into the database. If I set these variables to
something in the original INVITE, then that value will be accounted
instead, but still not the updated value from the BYE.

Has anyone been able to get this to work? Am I missing something obvious?

Example Config:


modparam("acc", "db_extra_bye", "call_val=$avp(call_val);
bye_val=$avp(bye_val)")
.
..
   if (loose_route()) {
  if (is_method("BYE"))
   $avp(call_val) = "set";
   $avp(bye_val) = "set";
  }
  
   }


Thanks.

Regards,

Ryan

___
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


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

Re: [OpenSIPS-Users] Acc - Can't get db_extra_bye to work

[Razvan Crainea]

Hi, Ryan!

Have you tried to set the avp values before 'loose_route' call?

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/28/2012 06:28 PM, Ryan Bullock wrote:

Without any success I have been trying to get some values accounted
using the 'db_extra_bye'  parameter of the acc module. However,
opensips still appears to always account the values as if they were
taken from the original INVITE transaction and not the BYE.

I have cdr accounting enabled, as well as several db_extra values.

When a BYE is received I update a few avp variables. When I xlog these
variables I can see that they are properly set, however opensips
inserts empty values into the database. If I set these variables to
something in the original INVITE, then that value will be accounted
instead, but still not the updated value from the BYE.

Has anyone been able to get this to work? Am I missing something obvious?

Example Config:


modparam("acc", "db_extra_bye", "call_val=$avp(call_val);
bye_val=$avp(bye_val)")
.
..
   if (loose_route()) {
  if (is_method("BYE"))
   $avp(call_val) = "set";
   $avp(bye_val) = "set";
  }
  
   }


Thanks.

Regards,

Ryan

___
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] LB + RTPProxy

[Razvan Crainea]

Hi, Vladimir!

Please provide us a complete SIP trace of the call. You can send me on 
private if you want.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/20/2012 05:05 PM, Vladimir Vakulov wrote:


Good afternoon.

For several days I try to construct a scheme LB RTPProxy:
incoming calls -> GW [10.2.42.70] -> [10.2.42.74] OpenSIPs + RTPProxy 
[192.168.1.2] -> [192.168.1.3 (/ 4/5/6)] 4x Asterisks (in a 
test using only the 192.168.1.3)
Calls come in Asterisk, but RTP session is established directly 
between Asterisk andGW. When I add the script to 
use RTPProxy, it appears only in the INVITE message and RTP session is 
established between 192.168.1.2 and 192.168.1.3, but not with 
thecallers. In the "ACK" and "200 OK" everything as it was before.

Example of 200
"
<--- SIP read from UDP: 10.2.42.74:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.42.70:5060; received = 10.2.42.70; branch = 
z9hG4bK342cdd3c; rport = 5060

Record-Route: 
Record-Route: 
From: "New User" ; tag = as3d53f405
To: ; tag = as3b390137
Call-ID: 6e15f78d6bcdbb293620488a251174f8@10.2.42.70: 5060
CSeq: 102 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, 
INFO, PUBLISH

Supported: replaces, timer
Contact: 
Content-Type: application / sdp
Content-Length: 255

v = 0,
o = root 1604383785 1604383785 IN IP4 192.168.1.3
s = Asterisk PBX 10.3.0
c = IN IP4 192.168.1.3
t = 0 0
m = audio 18100 RTP / AVP 8 0 3111
a = rtpmap: 8 PCMA/8000
a = rtpmap: 0 PCMU/8000
a = rtpmap: 3 GSM/8000
a = rtpmap: 111 G726-32/8000
a = ptime: 20
a = sendrecv
"

I would be grateful for any help.

Vladimir.



___
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] Use of Ratelimit Module as CPS limiter

[Razvan Crainea]

Hello, Will!

You are right, the ratelimit module is the one you should choose to 
limit CPS. But unfortunately I think you misunderstood how it works. The 
parameters of the rl_check functions are the followings:


key - the entity you want to limit the CPS. For example this can be an 
IP, if you want to limit the CPS coming from a certain IP.
limit - this is the limit of CPS allowed for the specified key. If this 
limit is reached, the function will return with failure, otherwise it 
will return true.

algorithm - the algorithm used to detect a limit.

Therefore, if you would like to limit the CPS for each IP to 3, you 
should use the following snippet:


if (!rl_check("$si", "3", "RED")) {
sl_send_reply("403", "CPS Limit Exceeded");
exit;
};

You can specify how long a value should be kept in memory using the 
expire_time parameter[1] of the module.


[1] http://www.opensips.org/html/docs/modules/devel/ratelimit.html#id250152

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/18/2012 10:30 PM, Will Baz wrote:

Hi All,
I have been taking a look at the ratelimit module to limit CPS as 
suggested by a few prior posts. I believe I have the gist of it (it's 
a key/value store w/ specialized algorithms to calculate when a limit 
is reached), but I was wondering if someone could explain best 
practices for removing values from the key/value store?
Specifically I was planning on limiting CPS by entering a string for 
my key that represents the "second" and increment. So something like 
this:


rl_check("080101", 5, )

We could also add a trunk_id to the front of that string to limit CPS 
on a particular trunk or IP or whatever. Then when a call comes in at 
that specific second we increment the counter and check to see if 
there have already been 5 calls that second.


What I'm not clear on looking at the module description 
(http://www.opensips.org/html/docs/modules/devel/ratelimit.html) is 
how I could destroy certain key/value pairs once I don't need them 
anymore (because the second is over). I do not want to have 3600 
values an hour sitting in memory.


Anyways, if someone has used ratelimit in a similar fashion or may 
understand it better than I, I'd appreciate any feedback.


Thanks!
Will

PS, Apologies if this is a duplicate. I originally posted w/o being a 
member of the lists. I joined and then reposted assuming my original 
would not be posted.




___
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] ERROR:rtpproxy

[Razvan Crainea]

Hello!

The log you provided with debug 5 isn't complete, it doesn't contain the 
response received by OpenSIPS from RTPProxy. You should check RTPProxy's 
logs in order to see why it sends a command answer with port 0.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/18/2012 07:11 PM, goup2010 wrote:

Hello all,

I use opensips 1_8 svnrevision: 2:8890M.

When set debug=3 I see follow error:

Apr 18 18:56:33  /usr/local/sbin/opensips[3968]: Incoming call
conected. Call from NAT. Force RTP proxy.
Apr 18 18:56:33  /usr/local/sbin/opensips[3968]:
ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from
rtp proxy

When set debug=5 I see core without error:

Apr 18 18:40:35 /usr/local/sbin/opensips[3907]: Incoming call
conected. Call from NAT. Force RTP proxy.
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:core:parse_headers: flags=
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:core:get_hdr_field: content_length=278
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:core:get_hdr_field: found end of header
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:core:decode_mime_type: Decoding MIME type for:[application/sdp]
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:rtpproxy:force_rtp_proxy: force rtp proxy with param1<(null)>  and
param2
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:core:parse_headers: flags=40
Apr 18 18:40:35  /usr/local/sbin/opensips[3907]:
DBG:rtpproxy:force_rtp_proxy: Forcing body:#012[v=0#015#012o=root
1970869766 1970869766 IN IP4 88.99.11.22#015#012s=ITG SBC#015#012c=IN
IP4 88.99.11.22#015#012t=0 0#015#012m=audio 11262 RTP/AVP 8 0
101#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:0
PCMU/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
0-16#015#012a=silenceSupp:off - - -
-#015#012a=ptime:20#015#012a=sendrecv#015#012]
Apr 18 18:40:35  /usr/local/sbin/opensips[3903]: DBG:core:buf_init:
initializing...

This is part of opensips config:

onreply_route[incoming] {
.
if ( isbflagset(6)&&  status=~"(183)|(2[0-9][0-9])"){
xlog("L_ERR","Incoming call conected. Call from NAT. Force RTP 
proxy. \n");
rtpproxy_answer();
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
exit;
} # end

Where is problem?

Best regards,
PlayMen

___
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] Flatstore "extra" fields handling

[Razvan Crainea]

Hi, Brett!

You are right, the order of the flatstore fields is exactly the one you 
mentioned. More exactly, they are organized as follows:


method
from_tag
to_tag
callid
sip_code
sip_reason
time when the insert query is made

db_extra fields
db_extra_bye fileds, if you are using this feature

duration of the call
setuptime
dialog creation time

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/18/2012 07:09 PM, Brett Nemeroff wrote:

Hello All,
In using flatstore, I see that I don't get headers on each file 
created. I'm using db_extra, and I do see the data put in there, but 
I'm just really guessing what the columns are.


Can someone tell me how flatstore orders the columns? From what I can 
tell, for acc at least, it appears to order them like this:


 +  + 

But I'm just guessing.

Thanks,
Brett



___
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] Crash and a bug with mod auth_db

[Razvan Crainea]

Hello, Moe!

I have just committed a fix on svn. Can you please update your sources 
and try again? Let me know if the problem is not solved.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/14/2012 12:57 PM, Moe Navid wrote:
Regarding the second one, I had something really really stupid going 
on, not a bug, but the first report is still valid.


Thanks,

Moe.

On Sat, Apr 14, 2012 at 1:30 AM, Mohammad Amin Navid 
mailto:mana...@gmail.com>> wrote:


Hello,

I filed the crash with source forge, but I don't know if it got
submitted or not. I'm facing the following problems with auth_db:

*1) The crash:* When setting load_credentials with only the
column, it causes openSIPS to crash
modparam("auth_db", "load_credentials", "email_address")

here is the backtrace:

#0  0x004cf85d in tsl (lock=0x0) at evi/../fastlock.h:88
#1  get_lock (lock=0x0) at evi/../fastlock.h:178
#2  0x004d11fd in lookup_avp_alias_str (name=0x7f46abfc06e8,
avp_name=0x7fff1b26c69c, extra=1) at usr_avp.c:505
#3  parse_avp_spec_aux (name=0x7f46abfc06e8,
avp_name=0x7fff1b26c69c, extra=1)
at usr_avp.c:566
#4  0x004d1403 in get_avp_id (name=0x0) at usr_avp.c:587
#5  0x7f46a7996a4a in parse_aaa_avps () at aaa_avps.h:145
#6  mod_init () at authdb_mod.c:209
#7  0x0049e034 in init_mod (m=0x7f46abfc1b30) at
sr_module.c:458
#8  0x0049dfcc in init_mod (m=0x7f46abfc1c00) at
sr_module.c:453
#9  0x0049dfcc in init_mod (m=0x7f46abfc1cd0) at
sr_module.c:453
#10 0x0049dfcc in init_mod (m=0x7f46abfc2078) at
sr_module.c:453
#11 0x0049dfcc in init_mod (m=0x7f46abfc2148) at
sr_module.c:453
#12 0x0049dfcc in init_mod (m=0x7f46abfc2218) at
sr_module.c:453
#13 0x0049dfcc in init_mod (m=0x7f46abfc22e8) at
sr_module.c:453
#14 0x0049dfcc in init_mod (m=0x7f46abfc23b8) at
sr_module.c:453
#15 0x0049dfcc in init_mod (m=0x7f46abfc2488) at
sr_module.c:453
#16 0x0049dfcc in init_mod (m=0x7f46abfc2558) at
sr_module.c:453
#17 0x0049dfcc in init_mod (m=0x7f46abfc2628) at
sr_module.c:453
#18 0x0049dfcc in init_mod (m=0x7f46abfc2be0) at
sr_module.c:453
#19 0x00431c37 in main (argc=,
argv=) at main.c:1466

*2) The bug:* The named AVPs for load_credentials works just fine
with a MySQL backend however, the AVPs for load_credentials are
not accessible when using PostgreSQL as a db backend. When using
PostgreSQL as backend, I can see in logs that it's querying
correctly and I can even see the values from DB but somehow they
are not being accessible through the AVP.

Thank you.




___
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] enum_pv_query response

[Razvan Crainea]

Hello, Andrew!

You should see the enum response stored in the $ru variable just after 
the enum_pv_query function.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/10/2012 09:25 AM, Andrew Melton wrote:

Ok, thanks Razvan.

Can you help me narrow down the response?  I am using the 
enum_pv_query along with t_reply to return the enum results to the caller:


route[1] {
...
enum_pv_query("$ru", "enum.local");
 t_reply("302", "ENUM");
...


This results in something like (from sip_trace):

| 1089 | 2012-04-09 20:33:23 | 
7f995e292bec90f904dd33f9764af0bb@10.10.81.28 
<mailto:7f995e292bec90f904dd33f9764af0bb@10.10.81.28>  | | 
SIP/2.0 302 ENUM
Via: SIP/2.0/UDP 
10.10.81.28:5060;received=10.10.81.28;branch=z9hG4bK2bfcb565;rport=5060
From: <mailto:sip%3A12105856325@10.10.81.28>>;tag=as6c204346
To: <mailto:sip%3A%2B13104849395@10.10.141.97>>;tag=3e30cad664f79af6351b92d4153bfe13.b8f4
Call-ID: 7f995e292bec90f904dd33f9764af0bb@10.10.81.28 
<mailto:7f995e292bec90f904dd33f9764af0bb@10.10.81.28>

CSeq: 102 INVITE
Contact: ;q=0.99
Server: OpenSIPS (1.8.0-beta-notls (x86_64/linux))
Content-Length: 0

It would seem that either $(ct.fields(uri) or $ru would grab the 
Contact header string:


Contact: ;q=0.99

but xlog copies the received URI instead of the enum_pv_query results.

Is there something in addition to $ru that I need to look for to 
capture the URI response?


Thank you.









On Mon, Apr 9, 2012 at 1:17 AM, Razvan Crainea <mailto:raz...@opensips.org>> wrote:


Hello, Andrew!

You cannot access the raw NAPTR response from the script, you can
only see the R-URI modified according to the ENUM regexp response.
Therefore, you can search for the rn param in the R-URI ($ru
pseudovariable).

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/06/2012 11:58 PM, Andrew Melton wrote:

I am attempting to use the NAPTR response from an enum_pv_query,
but I can't find the variable being used to store it.  Debug
shows a response value:

DBG:enum:enum_pv_query_3: ENUM query on
5.2.1.5.7.2.8.2.1.5.1.enum.local: order 100, pref 50, flen 1,
flags 'u', slen 12, services 'E2U+pstn:tel', rlen 44, regexp
'!^(.*)$!tel:\1;npdi;rn=5125599976 ;spid=1086!'

Based on that, I was expecting to redirect the call by parsing
the rn=5125599976  from the enum response, and
using it to either rewrite the uri or construct a simple 302 from
scratch.  Can I store the response or use it in a script?

Thanks.




___
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 <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/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Failed to Initialize Module Nathelper, Opensips 1.6.3

[Razvan Crainea]

Hi, Apenk!

Try to increase the debugging level to 6 and check if there is any 
useful information there.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/09/2012 12:13 PM, apenk wrote:

Hi,

I'm trying to make opensips work with nathelper and rtpproxy.
I used opensips 1.6.3-no-tls, compiled it with all the needed modules. 
I also used the same config (modified module path & ip address) as the 
working Opensips 1.6 Live CD.


But everytime I tried to start opensips, it failed. It said that 
opensips failed to initialize module nathelper. This one is the error log.

http://pastebin.com/be2CRD3R

The rtpproxy was up, of course. I used netstat.
udp0  0 127.0.0.1:7890   
0.0.0.0:*   1595/rtpproxy


I know there's no one to debug except me. But, just in case, these are 
my config file and my modules list.

http://pastebin.com/pAqpCeBZ
http://pastebin.com/J4EVKGhN

Is there something wrong with the nathelper module?

Thanks in advance.

Kind regards,
Apenk Satria


___
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] enum_pv_query response

[Razvan Crainea]

Hello, Andrew!

You cannot access the raw NAPTR response from the script, you can only 
see the R-URI modified according to the ENUM regexp response. Therefore, 
you can search for the rn param in the R-URI ($ru pseudovariable).


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/06/2012 11:58 PM, Andrew Melton wrote:
I am attempting to use the NAPTR response from an enum_pv_query, but I 
can't find the variable being used to store it.  Debug shows a 
response value:


DBG:enum:enum_pv_query_3: ENUM query on 
5.2.1.5.7.2.8.2.1.5.1.enum.local: order 100, pref 50, flen 1, flags 
'u', slen 12, services 'E2U+pstn:tel', rlen 44, regexp 
'!^(.*)$!tel:\1;npdi;rn=5125599976;spid=1086!'


Based on that, I was expecting to redirect the call by parsing the 
rn=5125599976 from the enum response, and using it to either rewrite 
the uri or construct a simple 302 from scratch.  Can I store the 
response or use it in a script?


Thanks.




___
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 and avp_timeout

[Razvan Crainea]

Hi, Marcello!

The dialog is matched by the loose_route function. And this is when all 
the dialog structures are updated. If you are changing anything after 
the loose_route, the changes won't be visible in the dialog.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/05/2012 11:06 AM, Marcello Lupo wrote:

Hi,
effectively i was using it after the loose_route().
I will try to do it after the loose_route().
Why it have to be done in this way? Just for information.
Thank you for the answer.
Regards
Marcello

On Apr 5, 2012, at 9:36 AM, Razvan Crainea wrote:


Hi, Marcello!

The block used to handle the ACK timeout is executed before loose_route or 
after? It should be before.

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/04/2012 11:59 PM, Marcello Lupo wrote:

Hi,
I'm using opensips 1.6.4 with dialog support.
I use dialog default timeout to close automatically calls after 3 hours and it 
works great.
Sometimes happen that some dialog remain in state 3 (200 OK received but ACK 
not received) till the default_timeout is reached.
I was trying to set default_timeout to 120 seconds and change the avp_timeout 
on the ACK to a greater value so the calls in state 3 will be automatically 
closed form the system after 120 sec.
I read around the docs that the timeout can be changed everywhere in the script 
after the dialog has been created but it is not working for me.

Every time the system give me:

DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout

and never update the timeout_avp.

I have in the config:

modparam("dialog", "default_timeout", 120)
modparam("dialog", "timeout_avp", "$avp(i:104)")
modparam("dialog", "bye_on_timeout_flag", 21)

In routing block when dialog start:

create_dialog();
setflag(21);


In routing block to check ACK:

 if(method=="ACK"&&   $DLG_status!=NULL) {
 $avp(i:104)="10800";
# $avp(i:104)=10800;
 setflag(21);
 }

I tried to put the avp_timeout value as INT or as STRING but no difference. 
Looking in the source code seems that default_timeout is INT but timeout_avp 
expect string value.

Someone can help?
Thank you
Bye
Marcello


___
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 and avp_timeout

[Razvan Crainea]

Hi, Marcello!

The block used to handle the ACK timeout is executed before loose_route 
or after? It should be before.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 04/04/2012 11:59 PM, Marcello Lupo wrote:

Hi,
I'm using opensips 1.6.4 with dialog support.
I use dialog default timeout to close automatically calls after 3 hours and it 
works great.
Sometimes happen that some dialog remain in state 3 (200 OK received but ACK 
not received) till the default_timeout is reached.
I was trying to set default_timeout to 120 seconds and change the avp_timeout 
on the ACK to a greater value so the calls in state 3 will be automatically 
closed form the system after 120 sec.
I read around the docs that the timeout can be changed everywhere in the script 
after the dialog has been created but it is not working for me.

Every time the system give me:

DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout

and never update the timeout_avp.

I have in the config:

modparam("dialog", "default_timeout", 120)
modparam("dialog", "timeout_avp", "$avp(i:104)")
modparam("dialog", "bye_on_timeout_flag", 21)

In routing block when dialog start:

create_dialog();
setflag(21);


In routing block to check ACK:

 if(method=="ACK"&&  $DLG_status!=NULL) {
 $avp(i:104)="10800";
# $avp(i:104)=10800;
 setflag(21);
 }

I tried to put the avp_timeout value as INT or as STRING but no difference. 
Looking in the source code seems that default_timeout is INT but timeout_avp 
expect string value.

Someone can help?
Thank you
Bye
Marcello


___
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] opensips.pid does not exist -- OpenSIPS start failed

[Razvan Crainea]

Hi, Miha!

You should add the module in your configuration file (I think you can 
find it in /usr/local/etc/opensips/opensips.cfg), in the modules 
section. You should add this line, preferably before any other loadmodule:

loadmodule "db_mysql.so"

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 03/29/2012 11:34 AM, Miha wrote:

On 3/29/2012 10:26 AM, Razvan Crainea wrote:

Hi, Miha!

If you take a closer look at your logs, you will find this error:
"No database module found"
This means that you haven't loaded any database module (i.e. 
db_mysql) in your configuration script.


Regards,
--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com

On 03/29/2012 11:18 AM, Miha wrote:

Hi,

I was searching in google and noticed that there was I lot of themes 
about this threat.


In opensipsctlrc I have this:

 $Id: opensipsctlrc 8290 2011-08-23 14:14:10Z razvancrainea $
#
# The OpenSIPS configuration file for the control tools.
#
# Here you can set variables used in the opensipsctl and 
opensipsdbctl setup
# scripts. Per default all variables here are commented out, the 
control tools

# will use their internal default values.

## your SIP domain
# SIP_DOMAIN=opensips.org

## chrooted directory
# $CHROOT_DIR="/path/to/chrooted/directory"

## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, or DBTEXT,
## by default none is loaded
# If you want to setup a database with opensipsdbctl, you must at 
least specify

# this parameter.
 DBENGINE=MYSQL

## database host
 DBHOST=127.0.0.1

## database name (for ORACLE this is TNS name)
 DBNAME=opensips

# database path used by dbtext or db_berkeley
# DB_PATH="/usr/local/etc/opensips/dbtext"

## database read/write user
 DBRWUSER=opensips

## password for database read/write user
 DBRWPW="opensips"

## database super user (for ORACLE this is 'scheme-creator' user)
 DBROOTUSER="root"

# user name column
 USERCOL="username"

Than I have created database with opensipsdbctl create .
After I start opensips I get this:

[root@localhost opensips]# opensipsctl start

INFO: Starting OpenSIPS :

ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS 
start failed

[root@localhost opensips]#

This is my log message:

Mar 29 10:15:02 localhost opensips: INFO:core:daemonize: pre-daemon 
process exiting with -1
Mar 29 10:17:40 localhost opensips: WARNING:core:fix_socket_list: 
could not rev. resolve 172.31.1.191
Mar 29 10:17:40 localhost opensips: WARNING:core:fix_socket_list: 
could not rev. resolve 172.31.1.191
Mar 29 10:17:40 localhost opensips: INFO:core:init_tcp: using 
epoll_lt as the TCP io watch method (auto detected)
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
NOTICE:core:main: version: opensips 1.7.0-notls (x86_64/linux)
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:core:main: using 32 Mb shared memory
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:core:main: using 2 Mb private memory per process
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
NOTICE:signaling:mod_init: initializing module ...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:sl:mod_init: Initializing StateLess engine
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:tm:mod_init: TM - initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:rr:mod_init: rr - initializing
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:maxfwd:mod_init: initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:usrloc:ul_init_locks: locks array size 512
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:registrar:mod_init: initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:textops:mod_init: initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:core:db_check_api: module db_mysql does not export 
db_use_table function
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:uri:mod_init: No database module found
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:core:init_mod: failed to initialize module uri
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:core:main: error while initializing modules
Mar 29 10:17:40 localhost opensips: INFO:core:daemonize: pre-daemon 
process exiting with -1



Thanks!

Regards,
Miha


___
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

Hi @Ra(zvan,

thank you for your quick replay. I noticed that but I do not know how 
to load mysql modul(db_mysql).


I compile it like this:
[root@opensips1~]# make all include_modules="db_mysql&q

Re: [OpenSIPS-Users] opensips.pid does not exist -- OpenSIPS start failed

[Razvan Crainea]

Hi, Miha!

If you take a closer look at your logs, you will find this error:
"No database module found"
This means that you haven't loaded any database module (i.e. db_mysql) 
in your configuration script.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 03/29/2012 11:18 AM, Miha wrote:

Hi,

I was searching in google and noticed that there was I lot of themes 
about this threat.


In opensipsctlrc I have this:

 $Id: opensipsctlrc 8290 2011-08-23 14:14:10Z razvancrainea $
#
# The OpenSIPS configuration file for the control tools.
#
# Here you can set variables used in the opensipsctl and opensipsdbctl 
setup
# scripts. Per default all variables here are commented out, the 
control tools

# will use their internal default values.

## your SIP domain
# SIP_DOMAIN=opensips.org

## chrooted directory
# $CHROOT_DIR="/path/to/chrooted/directory"

## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, or DBTEXT,
## by default none is loaded
# If you want to setup a database with opensipsdbctl, you must at 
least specify

# this parameter.
 DBENGINE=MYSQL

## database host
 DBHOST=127.0.0.1

## database name (for ORACLE this is TNS name)
 DBNAME=opensips

# database path used by dbtext or db_berkeley
# DB_PATH="/usr/local/etc/opensips/dbtext"

## database read/write user
 DBRWUSER=opensips

## password for database read/write user
 DBRWPW="opensips"

## database super user (for ORACLE this is 'scheme-creator' user)
 DBROOTUSER="root"

# user name column
 USERCOL="username"

Than I have created database with opensipsdbctl create .
After I start opensips I get this:

[root@localhost opensips]# opensipsctl start

INFO: Starting OpenSIPS :

ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start 
failed

[root@localhost opensips]#

This is my log message:

Mar 29 10:15:02 localhost opensips: INFO:core:daemonize: pre-daemon 
process exiting with -1
Mar 29 10:17:40 localhost opensips: WARNING:core:fix_socket_list: 
could not rev. resolve 172.31.1.191
Mar 29 10:17:40 localhost opensips: WARNING:core:fix_socket_list: 
could not rev. resolve 172.31.1.191
Mar 29 10:17:40 localhost opensips: INFO:core:init_tcp: using epoll_lt 
as the TCP io watch method (auto detected)
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
NOTICE:core:main: version: opensips 1.7.0-notls (x86_64/linux)
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:core:main: using 32 Mb shared memory
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:core:main: using 2 Mb private memory per process
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
NOTICE:signaling:mod_init: initializing module ...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:sl:mod_init: Initializing StateLess engine
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:tm:mod_init: TM - initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:rr:mod_init: rr - initializing
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:maxfwd:mod_init: initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:usrloc:ul_init_locks: locks array size 512
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:registrar:mod_init: initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
INFO:textops:mod_init: initializing...
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:core:db_check_api: module db_mysql does not export db_use_table 
function
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:uri:mod_init: No database module found
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:core:init_mod: failed to initialize module uri
Mar 29 10:17:40 localhost /usr/local/sbin/opensips[25216]: 
ERROR:core:main: error while initializing modules
Mar 29 10:17:40 localhost opensips: INFO:core:daemonize: pre-daemon 
process exiting with -1



Thanks!

Regards,
Miha


___
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] cdr_flag not working in v1.7

[Razvan Crainea]

Sorry, small typo. The proper code should be:

if (is_method("INVITE") && !has_totag())
setflag(2);

Regards!

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 03/23/2012 06:20 PM, Razvan Crainea wrote:

Hello, Sebastien!

The problem is that you should set the cdr_flag only for the initial 
INVITEs. If you also set it for the BYE messages, the acc module will 
consider that you want to separately dump the BYE in the database, 
regardless the cdr automatic behaviour.


So the proper way to use the cdr accounting is to set the cdr_flag 
only for initial INVITEs:


if (is_method("INVITE") && has_totag())
setflag(2);

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 03/23/2012 04:41 PM, Sebastien CRUAUX wrote:

Hi Razvan,

I dug up this thread because I am facing the same issue as John and I 
am not sure I understood your answer.
What should be done in order to make the cdr_flag work with opensips 
1.7 ?


Regards,

Sebastien

Le 20/09/2011 18:23, Razvan Crainea a écrit :

Hi John,

The problem is here:

if (method=="INVITE" || method=="BYE") {
# Write CDR records to the database
setflag(2);
}

For any sequential request, the CDR engine ignores the flag (2 in 
your case). But the standard accounting will still notice it, and 
therefore will log the
BYE into the database. Deleting this lines above should no longer 
account it.
Anyway, I guess that the INVITE has all the fields filled properly 
(especially duration and setuptime), right?


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 20.09.2011 19:07, John Quick wrote:
My favourite module (dialog) got even better when the cdr_flag 
option was

added. I use it all the time now.

But it doesn't seem to be working in version 1.7. I know the call is
creating a dialog because db_mode is set to 1 and the record can be 
seen in
the dialog table while the call is active. However, 2 records are 
written to
the acc table - one for the INVITE and another for the BYE. So 
cdr_flag is
being ignored. Is this a problem in v1.7 or have I done something 
wrong?


Here's the relevant bits from opensips.cfg:
modparam("acc", "db_flag", 2)
modparam("acc", "cdr_flag", 2)
modparam("acc", "db_missed_flag", 3)
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 1)
modparam("acc", "db_extra", "authid=$avp(authid); srcip=$si; 
called=$rU;

route=$rd; cli=$fU")

modparam("dialog", "db_mode", 1)# 1 during testing; 0 or 3 for
production
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "rr_param", "scdg")  # unique rr tag value in 
case other

opensips servers in route
modparam("dialog", "default_timeout", 14400)   # default timeout 
set to 4

hours

route[3]
 if (method=="INVITE" || method=="BYE") {
 # Write CDR records to the database
 setflag(2);
 # ...and missed calls too
 setflag(3);
 }

 if (method=="INVITE") {
 # make OpenSIPS create a dialog record (see dialog module 
for info)

 create_dialog();
 }

...and my loose routing section:
 if (has_totag()) {
 if (loose_route()) {
 # Attempt to match this request with an existing dialog
 match_dialog();

 # Check authentication of re-invites - don't challenge 
if from a

known address
 if(method=="INVITE"&&
(!check_address("0","$si","$sp","$proto"))) {
 if (!proxy_authorize("","subscriber")) {
   proxy_challenge("","1");
   exit;
 };
 };

 if (method=="INVITE" || method=="BYE") {
 # Write CDR records to the database
 setflag(2);
 }


John Quick
Smartvox Limited
Web: www.smartvox.co.uk

Smartvox is a limited company, registered in England and Wales, number
5005263.
Registered office: Spectrum House, Dunstable Road, Redbourn, 
St.Albans,

Herts AL3 7PR




___
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


___
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] cdr_flag not working in v1.7

[Razvan Crainea]

Hello, Sebastien!

The problem is that you should set the cdr_flag only for the initial 
INVITEs. If you also set it for the BYE messages, the acc module will 
consider that you want to separately dump the BYE in the database, 
regardless the cdr automatic behaviour.


So the proper way to use the cdr accounting is to set the cdr_flag only 
for initial INVITEs:


if (is_method("INVITE") && has_totag())
setflag(2);

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 03/23/2012 04:41 PM, Sebastien CRUAUX wrote:

Hi Razvan,

I dug up this thread because I am facing the same issue as John and I 
am not sure I understood your answer.
What should be done in order to make the cdr_flag work with opensips 
1.7 ?


Regards,

Sebastien

Le 20/09/2011 18:23, Razvan Crainea a écrit :

Hi John,

The problem is here:

if (method=="INVITE" || method=="BYE") {
# Write CDR records to the database
setflag(2);
}

For any sequential request, the CDR engine ignores the flag (2 in 
your case). But the standard accounting will still notice it, and 
therefore will log the
BYE into the database. Deleting this lines above should no longer 
account it.
Anyway, I guess that the INVITE has all the fields filled properly 
(especially duration and setuptime), right?


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 20.09.2011 19:07, John Quick wrote:
My favourite module (dialog) got even better when the cdr_flag 
option was

added. I use it all the time now.

But it doesn't seem to be working in version 1.7. I know the call is
creating a dialog because db_mode is set to 1 and the record can be 
seen in
the dialog table while the call is active. However, 2 records are 
written to
the acc table - one for the INVITE and another for the BYE. So 
cdr_flag is
being ignored. Is this a problem in v1.7 or have I done something 
wrong?


Here's the relevant bits from opensips.cfg:
modparam("acc", "db_flag", 2)
modparam("acc", "cdr_flag", 2)
modparam("acc", "db_missed_flag", 3)
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 1)
modparam("acc", "db_extra", "authid=$avp(authid); srcip=$si; 
called=$rU;

route=$rd; cli=$fU")

modparam("dialog", "db_mode", 1)# 1 during testing; 0 or 3 for
production
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "rr_param", "scdg")  # unique rr tag value in 
case other

opensips servers in route
modparam("dialog", "default_timeout", 14400)   # default timeout set 
to 4

hours

route[3]
 if (method=="INVITE" || method=="BYE") {
 # Write CDR records to the database
 setflag(2);
 # ...and missed calls too
 setflag(3);
 }

 if (method=="INVITE") {
 # make OpenSIPS create a dialog record (see dialog module 
for info)

 create_dialog();
 }

...and my loose routing section:
 if (has_totag()) {
 if (loose_route()) {
 # Attempt to match this request with an existing dialog
 match_dialog();

 # Check authentication of re-invites - don't challenge 
if from a

known address
 if(method=="INVITE"&&
(!check_address("0","$si","$sp","$proto"))) {
 if (!proxy_authorize("","subscriber")) {
   proxy_challenge("","1");
   exit;
 };
 };

 if (method=="INVITE" || method=="BYE") {
 # Write CDR records to the database
 setflag(2);
 }


John Quick
Smartvox Limited
Web: www.smartvox.co.uk

Smartvox is a limited company, registered in England and Wales, number
5005263.
Registered office: Spectrum House, Dunstable Road, Redbourn, St.Albans,
Herts AL3 7PR




___
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


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

Re: [OpenSIPS-Users] Using dispatcher and t_replicate()

[Razvan Crainea]

Hi, Alex!

Yes, the t_replicate function hasn't changed. Your problem is that you 
are not passing properly the first parameter of the t_replicate() 
function. It should be:


t_replicate("$du", "0x4");

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 02/29/2012 03:07 PM, a.n.ryzhov wrote:

Hello, Razvan

I have try to use psevdo variable in opensips (1.7.2) script like this:

t_replicate($du,"0x4");

But i catch a  bad arguments error:
CRITICAL:core:yyerror: parse error in config file, line 197, column 26-27:
bad arguments for command

Is this functional
"t_replicate can also receive a pseudo-variable as argument." ported  to
1.7.2 opensips ?

Regards,
Alex
uiptel.com

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Using-dispatcher-and-t-replicate-tp5592900p7329158.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
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] Distributed Dialog and CacheDB Persistence

[Razvan Crainea]

Hi, Ryan!

The CacheDB feature was only added for the dialog profiles. This allows 
you to do load balancing scenarios through multiple OpenSIPS instances 
that share the same profiles.
Regarding the persistence of the dialog data, you will also have to use 
a database backend. But if we are talking about the dialog profiles 
persistence, then the discussion is more complex, as it depends on the 
CacheDB backend.
In conclusion, this new feature does not provide persistence, but opens 
some doors for new scenarios, like distributed load balancing as pointed 
above.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 02/22/2012 08:50 PM, Ryan Bullock wrote:

Does the new distributed dialog with cached also allow for dialogs to
persist through a restart of opensips? Or would that still require a
database backend?

Maybe a better question what actually gets distributed with the dialog
(e.g. dialog flags, dialog variables, etc)?

The new distributed system is very exciting. Can't wait to start
building with it.

Regards,

Ryan Bullock

___
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] [NEW] SIP validation function

[Razvan Crainea]

Hello, all!

OpenSIPS has been enhanced with a new function, sipmsg_validate, that 
verifies if the received SIP request or reply is compliant with the 
RFC3261[1]. The function can be found in the new sipmsgops module[2], 
along with all the SIP aware messages from the textops module[3]. In 
consequence, all the SIP related functions were moved from the textops 
module to the sipmsgops module.


The new sipmsg_validate function can be used to prevent malformed SIP 
messages from propagating through your network, and also avoid expensive 
processing them from the start.


Any feedback will be really appreciated.

[1] http://www.ietf.org/rfc/rfc3261.txt
[2] http://www.opensips.org/html/docs/modules/devel/sipmsgops.html
[3] http://www.opensips.org/html/docs/modules/devel/textops.html

Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


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

Re: [OpenSIPS-Users] Problem with uac_replace_from

[Razvan Crainea]

Hi, Steven!

The dialog module only stores the TO and FROM URIs, not the display 
names. Also, the uac_replace_from function keeps track only of the URIs. 
Therefore, the display names are ignored and they will not be 
automatically restored on any sequential requests.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 02/16/2012 07:08 PM, Steven Lam, KeenSystems B.V. wrote:

Hi,

Replying to myself...

Also looking at the "opensipsctl fifo dlg_list_ctx" output I can see only the 
changed uri is stored in the dialog.

Should the display not be stored? or am I missing something here?

Steven


-Original Message-
From: users-boun...@lists.opensips.org [mailto:users-
boun...@lists.opensips.org] On Behalf Of Steven Lam, KeenSystems B.V.
Sent: donderdag 16 februari 2012 17:49
To: users@lists.opensips.org
Subject: [OpenSIPS-Users] Problem with uac_replace_from

Hi list!

When playing with uac_replace_from to replace both display and uri like this:
 uac_replace_from("anonymous","sip:anonymous@anonymous.invalid");
I found that on subsequential (ACK) messages only the uri was changed again
and display had the original value.

Also when using uac_replace_from to replace only uri and remove display
like this:
 uac_replace_from("","sip:anonymous@anonymous.invalid");
On subsequential (ACK) messages the uri is changed as expected but display
had the original value.

To me this looks wrong.

Steven


___
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] DRouting Madness

[Razvan Crainea]

Hello, Anil!

You should replace the routeid column from your your dr_rules table with 
an empty value. Otherwise that routeid will be called every time the 
"do_routing" function is called, that's why the loop appears.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 01/26/2012 07:56 PM, Anil M Pannikode wrote:


I am running in to the same issue as the below attached post. Any 
solutions ?


My dr tables have the following entries.

+--+--+--+---++---++---+

| gwid | type | address  | strip | pri_prefix | attrs | probe_mode 
| description   |


+--+--+--+---++---++---+

|3 |1 | 10.10.20.201 | 0 | NULL   | NULL  |  2 
| eivr1  |


|4 |1 | 10.10.20.202 | 0 | NULL   | NULL  |  2 
| eivr2  |


|5 |2 | 10.10.20.181 | 0 | NULL   | NULL  |  2 
| eivr3  |


+--+--+--+---++---++---+

++--++-+-+

| id | username | domain | groupid | description |

++--++-+-+

|  1 | .*   | .* |   0 | Everyone|

++--++-+-+

+++-+

| id | gwlist | description |

+++-+

|  2 | 3,4| list1 |

|  3 | 5  | list2  |

+++-+

++-+-+-+--+-++---+---+

| ruleid | groupid | prefix  | timerec | priority | routeid | 
gwlist | description   | attrs |


++-+-+-+--+-++---+---+

|  7 | 0   | 1206555 | |0 | 4   | 
#3 | Route 1   | NULL  |


|  8 | 0   || |0 | 
4   | #2 | Default Route | NULL  |


++-+-+-+--+-++---+---+

Anil

>/  /
>/  Hello All,/
>/  /
>/  I've been posing this question in IRC, but haven't had/
>/  any luck with a lead.../
>/  /
>/  I'm trying to setup DRouting and I think I'm really/
>/  close, but for some reason when I get into my drouting subroute (in/
>/  this case route[4]) it matches from a row in the database on the first/
>/  try, but continues to loop through that subroute up to 32 additional/
>/  times before starting to throw errors. I'll attach a snippet here to/
>/  illustrate:/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DEBUG:>>>BEGIN: route[4]/
>/  Block -->/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DBG:core:parse_headers:/
>/  flags=10/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DBG:core:parse_to_param:/
>/  tag=as3cde8572/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DBG:core:parse_to: end of/
>/  header reached, state=29/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DBG:core:parse_to:/
>/  display={"username_of_caller"},/
>/  ruri={sip:username_of_caller at address_of_caller  
}/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DBG:drouting:do_routing:/
>/  using dr group 0/
>/  /
>...
//
/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]:/
>/  DBG:drouting:internal_check_rt: found rgid 0 (rule list 0xa741465c)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DEBUG:>>>BEGIN: route[4]/
>/  Block -->/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DBG:drouting:do_routing:/
>/  using dr group 0/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]:/
>/  DBG:drouting:internal_check_rt: found rgid 0 (rule list 0xa741465c)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DEBUG:>>>BEGIN: route[4]/
>/  Block -->/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: CRITICAL:core:eval_expr:/
>/  too many expressions (101)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: WARNING:core:do_action:/
>/  error in expression (l=387)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: CRITICAL:core:eval_expr:/
>/  too many expressions (101)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: WARNING:core:do_action:/
>/  error in expression (l=391)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: DEBUG:>>>BEGIN: route[1]/
>/  Block -->/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: CRITICAL:core:eval_expr:/
>/  too many expressions (101)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: WARNING:core:do_action:/
>/  error in expression (l=369)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: CRITICAL:core:eval_expr:/
>/  too many expressions (101)/
>/  /
>/  Jan 18 01:39:06 core01 /sbin/opensips[8489]: WARNING:core:do_action:/
>/  error in expressio

[OpenSIPS-Users] [NEW] Distributed dialog profiles

[Razvan Crainea]

Hello all!

The dialog profiles have been enhanced with support for the CacheDB 
Key-Value Interface[1] in order to provide support for distributed 
profiles. This new feature will allow script writers to share dialog 
profiles between multiple instances of OpenSIPS that share the same 
NoSQL backend.
In order to use the new distributed profiles, you will only have to 
define the CacheDB URL [2] and mark the profiles as shared[3].


[1] http://www.opensips.org/Resources/DocsTutKvinterface
[2] http://www.opensips.org/html/docs/modules/devel/dialog.html#id293910
[3] http://www.opensips.org/html/docs/modules/devel/dialog.html#id293790

Best regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com

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

Re: [OpenSIPS-Users] Allow scripting variables in call to rtpproxy_offer/answer?

[Razvan Crainea]

Hi, Jan!

I am glad you are interested in developing a small feature in OpenSIPS, 
but you should have opened this discussion on the devel list[1].
Your assumption is right, the rtpproxy_offer/answer functions don't 
accept variables as arguments.
In order to change that, you will have to modify the 
rtpproxy_offer/answer functions interface. Each module has to declare a 
"static cmd_export_t" structure, that contains information about the 
functions the module exports. For nathelper, this structure is declared 
in "modules/nathelper/nathelper.c", line ~430. Each function contains 
the name used in the script, the equivalent C function that handles the 
processing, the number of parameters it can take, a fixup function, plus 
some other information. This fixup function is the one that parses the 
string ("wz$avp(s:mode)" in your case), and builds a structure that can 
be evaluated when the function is called.
If you need an example of how this is done, you can take a look at the 
registrar module. You can find the export structure in 
"modules/registrar/reg_mod.c", line ~138. "save" and "lookup" are two 
functions that accept variables in the second argument (take a look at 
the "registrar_fixup" C function, that parses the 3 parameters). This 
approach is also used in textops module for the "add_body" function, or 
"append_hf", "insert_hf", in the exec module for all the functions and 
other places.

If you need any more help, please send a mail on the devel list.

[1] de...@lists.opensips.org

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://www.opensips-solutions.com


On 02/09/2012 12:26 AM, Jan Blom wrote:


Hello,

I am using OpenSIPS 1.6.4-2 and rtpproxy 1.2.1. I was trying to use an 
avp as part of the argument to Nathelper's rtpproxy_offer() and 
rtpproxy_answer() functions. Like:


rtpproxy_offer("wz$avp(s:mode)");

This doesn't work and results in the following log line:

ERROR:nathelper:force_rtp_proxy_body: unknown option `$'

I guess these functions are not prepared to handle variables as 
arguments. I would like to fix this in the source, but would 
appreciate some pointers on what to actually change. I guess there are 
number of similar places that does this right.


Thanks!

Best regards,

Jan Blom



___
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] Problems compiling OpenSIPS 1.7 on OpenBSD 5.0 (error: expected specifier-qualifier-list, etc)

[Razvan Crainea]

Hi, Taisto!

It is a fix that was not ported to 1.7 until now. I have just backported it.
Please update your svn sources and let me know if this doens't solve 
your problem.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/



On 02/03/2012 05:24 PM, Taisto Qvist wrote:

Hi Folks,

I am trying to compile OpenSIPS 1.7(latest svn src) on OpenBSD 5.0,
but I stumble fairly quickly on the below errors.

Anyone who can explain what simple things I've messed up?

Any help appreciated!

Regards
Taisto Qvist
IP-Solutions.se

*[root@sip] /usr/source/opensips_1_7 ># gmake*
Compiling evi/evi_core.c
In file included from evi/evi_transport.h:30,
from evi/event_interface.h:29,
from evi/evi_modules.h:30,
from evi/evi_core.c:26:
/usr/include/sys/socket.h:166: error: expected 
specifier-qualifier-list before 'u_int8_t'
/usr/include/sys/socket.h:184: error: expected 
specifier-qualifier-list before 'u_int8_t'
/usr/include/sys/socket.h:254: error: expected 
specifier-qualifier-list before 'uid_t'
/usr/include/sys/socket.h:400: error: expected 
specifier-qualifier-list before 'socklen_t'
/usr/include/sys/socket.h:426: error: expected 
specifier-qualifier-list before 'socklen_t'
/usr/include/sys/socket.h:482: error: expected 
specifier-qualifier-list before 'caddr_t'

In file included from evi/evi_transport.h:30,
from evi/event_interface.h:29,
from evi/evi_modules.h:30,
from evi/evi_core.c:26:
/usr/include/sys/socket.h:497: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:498: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:499: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:500: error: expected declaration specifiers 
or '...' before 'uid_t'
/usr/include/sys/socket.h:500: error: expected declaration specifiers 
or '...' before 'gid_t'
/usr/include/sys/socket.h:501: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:502: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:503: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:505: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recv'
/usr/include/sys/socket.h:506: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recvfrom'
/usr/include/sys/socket.h:507: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recvmsg'
/usr/include/sys/socket.h:508: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'send'
/usr/include/sys/socket.h:509: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'sendto'
/usr/include/sys/socket.h:511: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'sendmsg'
/usr/include/sys/socket.h:512: error: expected declaration specifiers 
or '...' before 'socklen_t'

In file included from evi/evi_transport.h:33,
from evi/event_interface.h:29,
from evi/evi_modules.h:30,
from evi/evi_core.c:26:
evi/../ip_addr.h: In function 'sockaddr2ip_addr':
evi/../ip_addr.h:220: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su_cmp':
evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:251: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su_getport':
evi/../ip_addr.h:275: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su_setport':
evi/../ip_addr.h:291: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su2ip_addr':
evi/../ip_addr.h:308: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'init_su':
evi/../ip_addr.h:338: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'hostent2su':
evi/../ip_addr.h:375: error: 'struct sockaddr' has no member named 
'sa_family'

In file included from evi/../fastlock.h:54,
from evi/../lock_ops.h:70,
from evi/../locking.h:67,
from e

Re: [OpenSIPS-Users] dispatcher problem

[Razvan Crainea]

Hi, Matt!

So for different hashed strings like:

DBG:dispatcher:ds_hash_pvar: Hashing "061002"!

you always get the same output:

DBG:dispatcher:ds_select_dst: alg hash [1], id [1]


Also, are you assigning different weights for any of the Asterisk?

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/



On 02/03/2012 12:16 AM, Matt Hamilton wrote:

Hi Ra(zvan,

Yes, I'm using the same hashing values - the values I assign to the PV are also
passed to the ds_select_dst correctly as far as I can see. Here is a typical
debug output:

DBG:dispatcher:ds_hash_pvar: Hashing "061002"!
DBG:dispatcher:ds_select_dst: alg hash [1], id [1]
DBG:dispatcher:ds_select_dst: selected [7-1/1]
DBG:dispatcher:ds_select_dst: using entry [1/0]


I ran some test with 3 Asterisk servers with interesting results:

With 3 Asterisk servers specified in dispatcher.list, here is the distribution:

Server1: 061003
Server2: 061002, 061007, 061008
Server3: 061005, 061006

With only Server1 and Server2 specified in dispatcher.list:

Server1:
Server2: 061002, 061003, 061005, 061006, 61007, 061008


Likewise, with Server1 and Server3, Server3 gets everything.
   with Server2 and Server3, Server3 gets everything.

Is there anything I can do to fix this (somehow trick the function assuming the 
way I do is the correct way)?

Thanks,
Matt








Date: Thu, 2 Feb 2012 22:51:46 +0200
From: razvancrai...@opensips.org
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dispatcher problem

Hi, Matt!

Are you sure you are not using the same hashing value all the time?
If yes, can you increase your debugging level to 6 and provide more 
information? I would be looking in the opensips log for lines that 
contain the following strings: "ds_hash_pvar: Hashing " and 
"ds_select_dst: alg hash ".


Regards,
--
Ra(zvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/


On 02/02/2012 10:15 PM, Matt Hamilton wrote:

Hi,

I'm using Opensips to dispatch to 2 servers - serverA, serverB.
When one of the servers is down, Opensips is dispatching to the
active one correctly. However, when both of them are Active, it's
picking only one of them and ignoring the other; e.g.,

when serverB is down, dispatches to serverA
when serverA is down, dispatches to serverB
when both up, dispatches to serverB
while dispatching to serverA when serverB is down, if I activate
serverB, all requests dispatched to serverB


Here is my code:

modparam("dispatcher", "hash_pvar", "$avp(75)")


in the script, I'm setting $avp(75) to one of the following
"061002", "061003", "061004", "061005", "061006" just before
calling ds_select_dst.

$avp(75)=..
ds_select_dst("1", "7");

Any ideas why this is happening?

Regards,
Matt


___
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] dispatcher problem

[Razvan Crainea]

Hi, Matt!

Are you sure you are not using the same hashing value all the time?
If yes, can you increase your debugging level to 6 and provide more 
information? I would be looking in the opensips log for lines that 
contain the following strings: "ds_hash_pvar: Hashing " and 
"ds_select_dst: alg hash ".


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/



On 02/02/2012 10:15 PM, Matt Hamilton wrote:

Hi,

I'm using Opensips to dispatch to 2 servers - serverA, serverB. When 
one of the servers is down, Opensips is dispatching to the active one 
correctly. However, when both of them are Active, it's picking only 
one of them and ignoring the other; e.g.,


when serverB is down, dispatches to serverA
when serverA is down, dispatches to serverB
when both up, dispatches to serverB
while dispatching to serverA when serverB is down, if I activate 
serverB, all requests dispatched to serverB



Here is my code:

modparam("dispatcher", "hash_pvar", "$avp(75)")


in the script, I'm setting $avp(75) to one of the following "061002", 
"061003", "061004", "061005", "061006" just before calling ds_select_dst.


$avp(75)=..
ds_select_dst("1", "7");

Any ideas why this is happening?

Regards,
Matt


___
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] can't force rtpproxy use a new IP in SDP

[Razvan Crainea]

Hello, Matt!

This part was not changed in OpenSIPS. The flags you are passing ("IE") 
are simply forwarded to RTPProxy, and he is the one who decides what IP 
to return to OpenSIPS. So I don't see why changing the rtpproxy.c 
behaves differently.
You could try to capture the traffic sent by OpenSIPS to RTPProxy and 
see if anything is different in the first part of the command.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/23/2012 03:16 AM, Matt Hamilton wrote:

Hi Ra(zvan,

As I said in my previous email I got the revision 8639 on 1.7.1 and 
that issue is fixed. However, I ran into a scenario where one of my 
scripts stopped working (audio issues).


In this scenario, I have a multihomed opensips with rtpproxy server 
bridging between opensips and and asterisk server.



 uac- opensips/rtpproxy   asterisk
   65.30.40.50
   192.168.100.76192.168.100.101



Very briefly, my cfg looks like:

route:
if (dst_ip == 65.30.40.50) # (SRC: 1.2.3.4)  call coming in from 
public uac

rtpproxy_offer("IE");


onreply:
if (dst_ip == 192.168.100.76)  # (SRC: 192.168.100.101) asterisk replying
rtpproxy_answer("IE");

This runs fine with the rtpproxy.c that came with 1.7.1, but not with 
the revised rtpproxy.c


rtpproxy_answer places 192.168.100.76 instead of 65.30.40.50in SDP (c) 
when replying to 1.2.3.4


I'm new to all this, so probably I'm doing something wrong, but jut 
wanted to let you know just in case. (I converted to the old 
rtpproxy.c, and it's working now.)


Regards,
Matt




Date: Sun, 22 Jan 2012 20:01:34 +0200
From: razvancrai...@opensips.org
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] can't force rtpproxy use a new IP in SDP

Hi, Matt!

The fix was only reported by Ovidiu and I was the one that fixed it in 
OpenSIPS's revision 8616 on trunk and 8639 on 1.7.1. This doesn't have 
anything to do with Kamailio. Can you please check if you have these 
changes? Because otherwise I don't think it will work.


Regards,
Ra(zvan

On 01/22/2012 07:49 PM, Matt Hamilton wrote:

Hi Ra(zvan,

I'm using Opensips 1.7.1. I have seen Ovidiu's changes, but I
think they are on the Kamailio side. if I'm not mistaken, sources
are a little different, so I didn't want to mess with it (for now).

I don't think there are any changes in Opensips (not in the trunk,
either).

> Both scenarios you presented can be implemented using the
rtpproxy module.

Can I still use rtpproxy (without the fix) to get the first
scenario going? Second one is all set.

Thanks a lot,
Matt



Date: Sun, 22 Jan 2012 19:25:04 +0200
From: razvancrai...@opensips.org 
To: users@lists.opensips.org 
Subject: Re: [OpenSIPS-Users] can't force rtpproxy use a new IP in SDP

Hi, Matt!

What version of OpenSIPS are you using? There was a bug reported
by Ovidiu and fixed in revision 8639.
Both scenarios you presented can be implemented using the rtpproxy
module.

Regards,
Ra(zvan

On 01/22/2012 07:15 PM, Matt Hamilton wrote:

Hi,

I can't seem to force a new IP to change the connection in
SDP; e.g.,

rtpproxy_offer("c", "1.2.3.4");

IP address I enter is always ignored. Any thoughts how I can
resolve this?


Here is my setup:

private   NAT   public NAT  private
phones |-- internet |---
opensips/rtpproxy-asterisk cluster


I would like to force rtpproxy use the NATted public ip
instead of the private ip of the opensips server when sending
messages to UACs. advertised_address doesn't help btw.


I was able to get the following going using the bridge mode.
Can bridge mode be somehow used for the above?


private   NAT   public   
NATprivate

phones |-- internet --
opensips/rtpproxy--|---asterisk cluster



Thanks,
Matt





___
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


___ Users mai

Re: [OpenSIPS-Users] can't force rtpproxy use a new IP in SDP

[Razvan Crainea]

Hi, Matt!

The fix was only reported by Ovidiu and I was the one that fixed it in 
OpenSIPS's revision 8616 on trunk and 8639 on 1.7.1. This doesn't have 
anything to do with Kamailio. Can you please check if you have these 
changes? Because otherwise I don't think it will work.


Regards,
Ra(zvan

On 01/22/2012 07:49 PM, Matt Hamilton wrote:

Hi Ra(zvan,

I'm using Opensips 1.7.1. I have seen Ovidiu's changes, but I think 
they are on the Kamailio side. if I'm not mistaken, sources are a 
little different, so I didn't want to mess with it (for now).


I don't think there are any changes in Opensips (not in the trunk, 
either).


> Both scenarios you presented can be implemented using the rtpproxy 
module.


Can I still use rtpproxy (without the fix) to get the first scenario 
going? Second one is all set.


Thanks a lot,
Matt



Date: Sun, 22 Jan 2012 19:25:04 +0200
From: razvancrai...@opensips.org
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] can't force rtpproxy use a new IP in SDP

Hi, Matt!

What version of OpenSIPS are you using? There was a bug reported by 
Ovidiu and fixed in revision 8639.

Both scenarios you presented can be implemented using the rtpproxy module.

Regards,
Ra(zvan

On 01/22/2012 07:15 PM, Matt Hamilton wrote:

Hi,

I can't seem to force a new IP to change the connection in SDP; e.g.,

rtpproxy_offer("c", "1.2.3.4");

IP address I enter is always ignored. Any thoughts how I can
resolve this?


Here is my setup:

private   NAT   public NAT  private
phones |-- internet |---
opensips/rtpproxy-asterisk cluster


I would like to force rtpproxy use the NATted public ip instead of
the private ip of the opensips server when sending messages to
UACs. advertised_address doesn't help btw.


I was able to get the following going using the bridge mode. Can
bridge mode be somehow used for the above?


private   NAT   publicNAT   
private

phones |-- internet --
opensips/rtpproxy--|---asterisk cluster



Thanks,
Matt





___
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] can't force rtpproxy use a new IP in SDP

[Razvan Crainea]

Hi, Matt!

What version of OpenSIPS are you using? There was a bug reported by 
Ovidiu and fixed in revision 8639.

Both scenarios you presented can be implemented using the rtpproxy module.

Regards,
Ra(zvan

On 01/22/2012 07:15 PM, Matt Hamilton wrote:

Hi,

I can't seem to force a new IP to change the connection in SDP; e.g.,

rtpproxy_offer("c", "1.2.3.4");

IP address I enter is always ignored. Any thoughts how I can resolve this?


Here is my setup:

private   NAT   public NAT  private
phones |-- internet |--- 
opensips/rtpproxy-asterisk cluster



I would like to force rtpproxy use the NATted public ip instead of the 
private ip of the opensips server when sending messages to UACs. 
advertised_address doesn't help btw.



I was able to get the following going using the bridge mode. Can 
bridge mode be somehow used for the above?



private   NAT   publicNATprivate
phones |-- internet -- opensips/rtpproxy--|---asterisk 
cluster




Thanks,
Matt





___
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] Identify CDR accounting on dialog-timeout

[Razvan Crainea]

Hi, Jayesh!

First of all, there are not so many changes between the 1.7.1 and trunk 
for the accounting module. Only this new parameter was added as far as I 
know, and it should be pretty stable. If you do want to use the module 
from trunk, you can simply copy it in your OpenSIPS 1.7.1 folder, and 
apply the patch I've attached in order to compile properly.


If you are using the automatic CDR accounting, then the scenario you 
described above can not be implemented. The accounting backend is only 
set at the initial invite.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/18/2012 04:53 PM, Jayesh Nambiar wrote:

Hi Razvan,
Not a very relevant question to ask, but is it possible to disable 
accounting when dialog times out?? So that no record is entered in the 
DB because of dialog timeout. I can probably setflag for syslog 
accounting where such calls will also get logged !!


--- Jayesh

On Wed, Jan 18, 2012 at 7:14 PM, Jayesh Nambiar > wrote:


Hi Razvan,
Thanks for your reply. Is it possible to use only the acc module
of trunk version with the 1.7.1 stable version or do I have to
download and configure the entire latest trunk version of opensips.
I intend to use this in production setup, so just a little more
worried about the reliability.

Thanks again,

--- Jayesh


Hello, Jayesh!

You can not achieve this scenario in OpenSIPS 1.7.1, but you
can wit the
acc module from trunk version. There you have a new parameter,
db_extra_bye[1], that can evaluate the pseudo variables after
the BYE
message is received.

An easier way to implement this, is to initialize a dlg_val
with the
value 1, and if you receive a BYE message, change it to 0. If
you don't
receive any BYE and a timeout is triggered, then the value
will remain 1
and that is what you will see in the database. Otherwise, for
a normal
hang up, you should set it to 0 and this will  reflect in the
DB. But
once again, this will only work with the trunk version, adding the
dlg_val to the db_extra_bye parameter.

[1]
http://www.opensips.org/html/docs/modules/devel/acc.html#id293815

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer



On 01/18/2012 01:35 PM, Jayesh Nambiar wrote:
> Hi,
> I am using CDR accounting with mysql in my script. I want a
way to
> know if the CDR record is because of a dialog_timeout. Is
there some
> standard way of notifying it from the script. I was thinking of
> something like this:
> I have an extra column "timeout" in  my acc table which is
inserted
> using db_extra parameter $avp(timeout) which is initialized
to 0. If I
> know somewhere in the script that dialog has timed out, I
set this
> $avp(timeout) to 1, so that the record inserted will have
timeout
> column value as 1 and it will be easily identifiable.
>
> I understand that AVPs are not dialog persistent, but
probably I can
> use some dlg_val variables. Also I dont find any function that
> indicates the dialog_timeout event. Another idea was to set the
> bye_on_timeout flag by calling create_dialog("B") and in
local_route
> catch the BYE request and set the dlg_val variables there.
>
> Wanted to know if any of these ideas can work or is there
some more
> standard way of doing it.
>
> --- Jayesh
>
>



Index: modules/acc/acc.c
===
--- modules/acc/acc.c	(revision 8673)
+++ modules/acc/acc.c	(working copy)
@@ -1490,7 +1490,7 @@
 	dlg = dlg_api.get_dlg();
 	if (!dlg) {
 		/* if the dialog doesn't exist we try to create it */
-		if ( dlg_api.create_dlg(req,0) < 0) {
+		if ( dlg_api.create_dlg(req) < 0) {
 			LM_ERR("error creating new dialog\n");
 			return -1;
 		}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Identify CDR accounting on dialog-timeout

[Razvan Crainea]

Hello, Jayesh!

You can not achieve this scenario in OpenSIPS 1.7.1, but you can wit the 
acc module from trunk version. There you have a new parameter, 
db_extra_bye[1], that can evaluate the pseudo variables after the BYE 
message is received.


An easier way to implement this, is to initialize a dlg_val with the 
value 1, and if you receive a BYE message, change it to 0. If you don't 
receive any BYE and a timeout is triggered, then the value will remain 1 
and that is what you will see in the database. Otherwise, for a normal 
hang up, you should set it to 0 and this will  reflect in the DB. But 
once again, this will only work with the trunk version, adding the 
dlg_val to the db_extra_bye parameter.


[1] http://www.opensips.org/html/docs/modules/devel/acc.html#id293815

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/18/2012 01:35 PM, Jayesh Nambiar wrote:

Hi,
I am using CDR accounting with mysql in my script. I want a way to 
know if the CDR record is because of a dialog_timeout. Is there some 
standard way of notifying it from the script. I was thinking of 
something like this:
I have an extra column "timeout" in  my acc table which is inserted 
using db_extra parameter $avp(timeout) which is initialized to 0. If I 
know somewhere in the script that dialog has timed out, I set this 
$avp(timeout) to 1, so that the record inserted will have timeout 
column value as 1 and it will be easily identifiable.


I understand that AVPs are not dialog persistent, but probably I can 
use some dlg_val variables. Also I dont find any function that 
indicates the dialog_timeout event. Another idea was to set the 
bye_on_timeout flag by calling create_dialog("B") and in local_route 
catch the BYE request and set the dlg_val variables there.


Wanted to know if any of these ideas can work or is there some more 
standard way of doing it.


--- 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] uac_replac​e_from from branch_route

[Razvan Crainea]

Hi, Plamen!

I have backported to 1.7.1 a fix from trunk for the uac module. Please 
update your svn sources and try again. Let me know if you still have 
problems.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 01/04/2012 04:17 PM, Razvan Crainea wrote:

Hello!

Are you sure you only call uac_replace_from/to only from the branch 
route, not from main route? Also, what version of OpenSIPS are you using?


Regards!
--
Răzvan Crainea
OpenSIPS Developer

On 01/04/2012 01:34 PM, goup2010 wrote:


Every use of uac_replac​e_from from branch_route appends FROM info in 
BYE header.


Example:

branch_route[1] {
   ...
   uac_replace_from("$avp(from_uri)");
   ...
}

The first using branch_route:
BYE message:
From: mailto:sip%3A440301234567@1.2.3.4> 
>;tag=as4012f1b6


The second using branch_route:
BYE message:
From: <mailto:sip%3A00440301234567@5.6.7.8> sip:440301234567@1.2.3.4 
<mailto:sip%3A440301234567@1.2.3.4> >;tag=as4012f1b6


What I do to correct this problem?



___
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] uac_replac​e_from from branch_route

[Razvan Crainea]

Hello!

Are you sure you only call uac_replace_from/to only from the branch 
route, not from main route? Also, what version of OpenSIPS are you using?


Regards!

--
Răzvan Crainea
OpenSIPS Developer


On 01/04/2012 01:34 PM, goup2010 wrote:


Every use of uac_replac​e_from from branch_route appends FROM info in 
BYE header.


Example:

branch_route[1] {
   ...
   uac_replace_from("$avp(from_uri)");
   ...
}

The first using branch_route:
BYE message:
From: mailto:sip%3A440301234567@1.2.3.4> 
>;tag=as4012f1b6


The second using branch_route:
BYE message:
From:  sip:440301234567@1.2.3.4 
 >;tag=as4012f1b6


What I do to correct this problem?



___
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] (no subject)

[Razvan Crainea]

Hi, Plamen!

I have just committed a fix for this. Please update your sources and try 
again.


Regards,
Ra(zvan Crainea

On 01/03/2012 06:47 PM, goup2010 wrote:
I use svnrevision: 2:8632M. When try to compile revision 8639 get 
follow error:

flatstore.c: In function 'flat_db_insert':
flatstore.c:307: error: 'DB_BIGINT' undeclared (first use in this 
function)

flatstore.c:307: error: (Each undeclared identifier is reported only once
flatstore.c:307: error: for each function it appears in.)
flatstore.c:310: warning: implicit declaration of function 'VAL_BIGINT'
flatstore.c:310: warning: format '%llu' expects type 'long long 
unsigned int', but argument 4 has type 'int'
flatstore.c:310: warning: format '%llu' expects type 'long long 
unsigned int', but argument 4 has type 'int'

make[1]: *** [flatstore.o] Error 1
make[1]: Leaving directory `/root/opensips_1_7/modules/db_flatstore'
make: *** [modules] Error 2
Best regards,
Plamen


___
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] load_balance not using group id in failure route

[Razvan Crainea]

Hi, Steven!

This is not strange, the usual scenario is to do failover within the 
gateways from the same group. My question is that if you have only one 
resource, why don't you use the dispatcher[1] module? I think it will 
meet better your requirements, as load balancer is usually used when you 
want to dispatch requests based on multiple resources. Also, there you 
can disable the automatic failover behavior.


[1] http://www.opensips.org/html/docs/modules/1.7.x/dispatcher.html

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/03/2012 04:31 PM, Steven Lam, KeenSystems B.V. wrote:


Hi Ra(zvan,

Thank you for your answer!

The table was just for illustrating the problem as simple as possible...

What I want to achieve is this: 3 servers for everyday use and 2 
servers for fallback, so simple RURI rewriting won't do the trick :-(


Can you tell me what the problem is with resetting the AVPs?

It is good to hear it is not a bug, but this makes me thinking... in 
this example the resources in all groups are "all". If I change the 
one from group 2 to "foobar" and then call load_balance in the 
failure_route like "load_balance("2","foobar")", I get a line telling 
me resource "foobar" is not found in group 1???


So in a failure_route load_balance does care about the resource and 
does NOT care about the group number, is this not strange?


Steven

*From:*users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Razvan Crainea

*Sent:* dinsdag 3 januari 2012 14:36
*To:* users@lists.opensips.org
*Subject:* Re: [OpenSIPS-Users] load_balance not using group id in 
failure route


Hi, Steven!

This is not wrong, this is the desired behaviour in order to use the 
failover features.
I see that you have only one destination in group 2. Will this be the 
final scenario? If yes, then you shouldn't use load balance, but a 
simple RURI rewriting.
However, if you want to use multiple gateways from failure route, 
there is a hack you can do, but I don't recommend it. You can reset 
the *lb_mask*, *lb_id* and *lb_grp* AVPs just before calling the 
load_balance function.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/03/2012 02:34 PM, Steven Lam, KeenSystems B.V. wrote:

Is nobody using this? :-(

I really want to know if I'm doing something wrong here...

Steven

*From:*users-boun...@lists.opensips.org 
<mailto:users-boun...@lists.opensips.org> 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Steven Lam, 
KeenSystems B.V.

*Sent:* donderdag 29 december 2011 14:48
*To:* users@lists.opensips.org <mailto:users@lists.opensips.org>
*Subject:* [OpenSIPS-Users] load_balance not using group id in failure 
route


Hi all,

Using the load balancer on OpenSIPS 1.7.1 I found that when calling 
load_balance in a failure_route with a group other than the one on the 
initial call, the load_balance still uses the "old" group.


For example:

The table looks like this:

++--+--+---+

| id | group_id | dst_uri  | resources |

++--+--+---+

|  1 |1 | sip:192.168.9.22 | all=10|

|  2 |1 | sip:192.168.9.27 | all=20|

|  3 |2 | sip:192.168.9.18 | all=10|

++--+--+---+

Script looks like this:

...

if ( load_balance("1","all") ) {

 xlog("==> Destination is $du\n");

 t_on_failure("1");

 t_relay();

 exit;

}

...

failure_route[1] {

 lb_disable();

  if ( load_balance("2","all") ) {

t_on_failure("1");

xlog("==> New destination is $du\n");

t_relay();

  } else {

t_reply("500","Error");

  }

}

This will result in routing a INVITE to sip:192.168.9.27, when this 
fails the INVITE will be routed to sip:192.168.9.22 _/NOT/_ 
192.168.9.18. To me this looks wrong.


Is this by design? If so how can I force load_balance to use a uri 
from group 2 after using one from group 1?


Hope someone can give me some advice on this.

Steven




___
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/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Getting error while Starting Opensips

[Razvan Crainea]

Hi, Faisal!

Only the load_balancer table is requiered. Your problem is that you 
didn't specify the db_url parameter for the load_balancer module. See 
http://www.opensips.org/html/docs/modules/devel/load_balancer.html#id249159 
for more details.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/03/2012 04:15 PM, Faisal Rehman wrote:

Hi Sammy,

Is that manadatory, because I think we can put the values in 
load_balancer table only?


Regards,

Faisal Rehman

*From:* Sammy Govind 
*To:* Faisal Rehman ; OpenSIPS users 
mailling list 

*Sent:* Tuesday, January 3, 2012 7:08 PM
*Subject:* Re: [OpenSIPS-Users] Getting error while Starting Opensips

Hi,
you probably forgot to add destination URIs in some table for 
dispatcher module.


 ERROR:dispatcher:mod_init: could not initiate a connect to the database

Regards,
Sammy.


On Tue, Jan 3, 2012 at 7:04 PM, Faisal Rehman 
mailto:faisal.rehma...@yahoo.com>> wrote:


Hi Everyone,

I am using Open sips version: opensips 1.7.1-notls (x86_64/linux)
for load balancing project, but I am getting the following error
while Starting OpenSIPS:


Jan  3 08:52:52 lb-sf-mc /usr/local/sbin/opensips[16405]:
ERROR:core:parse_uri: uri too short: <> (0)
Jan  3 08:52:52 lb-sf-mc /usr/local/sbin/opensips[16405]:
ERROR:dispatcher:add_dest2list: bad uri []
Jan  3 08:52:52 lb-sf-mc /usr/local/sbin/opensips[16405]:
ERROR:dispatcher:mod_init: could not initiate a connect to the
database
Jan  3 08:52:52 lb-sf-mc /usr/local/sbin/opensips[16405]:
ERROR:core:init_mod: failed to initialize module dispatcher
Jan  3 08:52:52 lb-sf-mc /usr/local/sbin/opensips[16405]:
ERROR:core:main: error while initializing modules
Jan  3 08:52:52 lb-sf-mc opensips: INFO:core:daemonize: pre-daemon
process exiting with -1


Any help would be highly appreciated :)
Regards,

Faisal Rehman

___
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] load_balance not using group id in failure route

[Razvan Crainea]

Hi, Steven!

This is not wrong, this is the desired behaviour in order to use the 
failover features.
I see that you have only one destination in group 2. Will this be the 
final scenario? If yes, then you shouldn't use load balance, but a 
simple RURI rewriting.
However, if you want to use multiple gateways from failure route, there 
is a hack you can do, but I don't recommend it. You can reset the 
*lb_mask*, *lb_id* and *lb_grp* AVPs just before calling the 
load_balance function.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 01/03/2012 02:34 PM, Steven Lam, KeenSystems B.V. wrote:


Is nobody using this? :-(

I really want to know if I'm doing something wrong here...

Steven

*From:*users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Steven Lam, 
KeenSystems B.V.

*Sent:* donderdag 29 december 2011 14:48
*To:* users@lists.opensips.org
*Subject:* [OpenSIPS-Users] load_balance not using group id in failure 
route


Hi all,

Using the load balancer on OpenSIPS 1.7.1 I found that when calling 
load_balance in a failure_route with a group other than the one on the 
initial call, the load_balance still uses the "old" group.


For example:

The table looks like this:

++--+--+---+

| id | group_id | dst_uri  | resources |

++--+--+---+

|  1 |1 | sip:192.168.9.22 | all=10|

|  2 |1 | sip:192.168.9.27 | all=20|

|  3 |2 | sip:192.168.9.18 | all=10|

++--+--+---+

Script looks like this:

...

if ( load_balance("1","all") ) {

 xlog("==> Destination is $du\n");

 t_on_failure("1");

 t_relay();

 exit;

}

...

failure_route[1] {

 lb_disable();

  if ( load_balance("2","all") ) {

t_on_failure("1");

xlog("==> New destination is $du\n");

t_relay();

  } else {

t_reply("500","Error");

  }

}

This will result in routing a INVITE to sip:192.168.9.27, when this 
fails the INVITE will be routed to sip:192.168.9.22 _/NOT/_ 
192.168.9.18. To me this looks wrong.


Is this by design? If so how can I force load_balance to use a uri 
from group 2 after using one from group 1?


Hope someone can give me some advice on this.

Steven



___
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] exec_avp in timer route

[Razvan Crainea]

Hello,

Starting from revision 8637, the exec_* functions are allowed to be 
called from timer route. The commit was done on both trunk and 1.7.1.


--
Răzvan Crainea
OpenSIPS Developer


On 12/28/2011 03:45 PM, Bogdan-Andrei Iancu wrote:

Hi guys,

I just opened a ticket, to allow these functions in STARTUP route.

Regards,
Bogdan

On 12/20/2011 11:35 PM, ddgiants wrote:
Hmmm thats what I am doing using startup and timer routes except I 
don't use

avp query to get data I use exec_avp.

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/exec-avp-in-timer-route-tp7103327p7113390.html

Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
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] Simple User Scenario to get two way audio working (Please Help)

[Razvan Crainea]

Hi, Nick!

In the traces you sent, it seems that the callee's RTP traffic doesn't 
reach the media relay server. This is most likely because the RTPProxy 
is behind NAT. In this case you have to double check two things:

* if the SDP is properly changed for the INVITEs and 200OKs
* if the media ports are properly forwarded to RTPProxy.

The second thing I noticed is that you use both engage_rtp_proxy and 
rtpproxy_* functions. I don't think this is such a good idea to mix 
them. Anyway, in your script, engage_rtp_proxy doesn't have any effect 
because you are not supposed to call it on sequential requests, only on 
initial request. So you can simply delete it.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/23/2011 05:25 AM, Nick Khamis wrote:

Hello Everyone,

I am testing a simple case where we have:

UC--->OpenSIPS>ITSP Gateway

The UC and OpenSIPS are on the same network behind a router. The
related parts of my config look like:

route{

 .

if (is_method("INVITE")&&  has_totag()) 
engage_rtp_proxy("ie","127.0.0.1");


 .
}

route[1] {  
if (is_method("INVITE")) {
xlog("Start Call for route [ fu=$fu/ tu=$tu /ru=$ru/ ci=$ci]");
prefix("00111");
rewritehostport("itsp.serviceprovider.com:5060");
if (has_body("application/sdp")) {
if (rtpproxy_offer()) t_on_reply("1");
else t_on_reply("2");
}

t_on_branch("2");
t_on_failure("1");
}

if (is_method("ACK")&&  has_body("application/sdp")) rtpproxy_answer();


if (!t_relay()) {
sl_reply_error();
}   

exit;
}

onreply_route[1] {
xlog("incoming reply\n");

if (has_body("application/sdp")) rtpproxy_answer();
exit;
}

onreply_route[2] {
xlog("incoming reply\n");

if (has_body("application/sdp")) rtpproxy_offer();
exit;
}

Everything seems to be starting fine except there is no audio both
ways. RTPProxy is started using the following:

./rtpproxy -s udp:127.0.0.1:7789 -l 192.168.2.102 -m 1 -M 2 -u
root root -F -f -d INFO LOG_LOCAL0
INFO:main: rtpproxy started, pid 2185
INFO:handle_command: new session
7e6a2939-599870c3-1f489940@192.168.2.11, tag D6D9E7BD-BC7B6732;1
requested, type strong
INFO:handle_command: new session on a port 11420 created, tag
D6D9E7BD-BC7B6732;1
INFO:handle_command: pre-filling caller's address with 192.168.2.11:
INFO:handle_command: lookup on ports 11420/15872, session timer restarted
INFO:handle_command: pre-filling callee's address with 95.211.119.251:36076
INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 0 in from callee, 326 in from caller,
326 relayed, 0 dropped
INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
relayed, 0 dropped
INFO:remove_session: session on ports 11420/15872 is cleaned up

A short sip trace:

  4.714356 192.168.2.11 ->  192.168.2.102 SIP/SDP Request: INVITE
sip:15078392...@opensips1.test.com;user=phone, with session
description
   4.790394 192.168.2.102 ->  192.168.2.11 SIP Status: 100 Giving a try
   4.802400 192.168.2.102 ->  202.163.224.113 DNS Standard query A
itsp.serviceprovider.com
   4.982490 202.163.224.113 ->  192.168.2.102 DNS Standard query
response A 93.221.112.231
   4.982490 192.168.2.102 ->  93.221.112.231 SIP/SDP Request: INVITE
sip:001110315148392...@sbc.voxbeam.com:5060;user=phone, with session
description
   5.070534 93.221.112.231 ->  192.168.2.102 SIP Status: 100 Trying
incoming reply
   6.339168 93.221.112.231 ->  192.168.2.102 SIP/SDP Status: 183 Session
Progress, with session description
   6.339168 192.168.2.102 ->  192.168.2.11 SIP/SDP Status: 183 Session
Progress, with session description
   6.467232 192.168.2.11 ->  192.168.2.102 RTP PT=ITU-T G.711 PCMU,
SSRC=0x7E7F31B9, Seq=38666, Time=2196142936, Mark

As mentioned earlier the UC and OpenSIPS+RTPProxy are behind a router
with ports 5060, and 1-2 being forwarded to the OpenSIPS
server.
I even tried putting the server in the DMZ, but still to no avail.


Thanks in Advance, and Happy Holidays,

Nick

___
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] is this valid naming for avps - $avp($var(i))

[Razvan Crainea]

Hi, Darren!

There is indeed a bug there, but the patch I've attached should fix it. 
Can you please apply it and test again? Let me know if this solves your 
issue.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 12/16/2011 06:47 AM, Darren DeLitizia wrote:

Is this valid naming for avp's - $avp($var(i))

I am trying to loop through exec_avp results as I will never know how 
many rows are being returned. It is in a startup route and I am using 
a while statement to loop through. It is not recognizing naming. 
$avp($avp(i)) always returns NULL while something like $avp(2) will 
return the data


Tx
DD

  exec_avp("/usr/bin/php /usr/local/etc/opensips/name_of_script.php 
ips");#gets list of ips and other carrier info

  if (is_avp_set("$avp(1)")) {
$var(x) = $avp(1); #$avp(1) is the amount of rows returned so I 
know how many to loop through

$var(x) = $(var(x){s.int }) + 1;
avp_delete("$avp(1)");
$avp(i) = 2;
while($avp(i) <= $var(x)) {
  xlog("TEST -- $avp(i)\n");
  xlog("TEST -- $avp($avp(i))\n"); #
  $avp(ip) = $(avp($var(i)){s.select,0,;});
  $avp(carrier_ids) = $(avp($var(i)){s.select,1,;});
  $avp(route_types) = $(avp($var(i)){s.select,2,;});
  $avp(carrier_names) = $(avp($var(i)){s.select,0,;});
  cache_store("local", "ips_carrier_ids_$avp(ip)", 
"$avp(carrier_ids)");#
  cache_store("local", "ips_carrier_names_$avp(ip)", 
"$avp(carrier_names)");#
  cache_store("local", "ips_carrier_types_$avp(ip)", 
"$avp(route_types)");#

  avp_delete("$avp($var(i))");
  $avp(i) = $avp(i) + 1;
}
  }
}



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Index: pvar.c
===
--- pvar.c	(revision 8626)
+++ pvar.c	(working copy)
@@ -3879,16 +3879,14 @@
 		return -1;
 	}
 		
-	if((tv.flags&PV_TYPE_INT) && (tv.flags&PV_VAL_INT))
-	{
-		*avp_name = tv.ri;
-	} else {
-		/* search the name here */
-		*avp_name = get_avp_id(&tv.rs);
-		if (*avp_name == 0) {
-			LM_ERR("cannot find avp %.*s\n", tv.rs.len, tv.rs.s);
-			return -1;
-		}
+	if(!(tv.flags&PV_VAL_STR))
+		tv.rs.s = int2str(tv.ri, &tv.rs.len);
+
+	/* search the name here */
+	*avp_name = get_avp_id(&tv.rs);
+	if (*avp_name == 0) {
+		LM_ERR("cannot find avp %.*s\n", tv.rs.len, tv.rs.s);
+		return -1;
 	}
 	return 0;
 }
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] uac_replace_from corruption

[Razvan Crainea]

Hi, Brett!

I was talking about the DEBUG info (debug core parameter set to 6). If 
you can provide the logs for such a corruption on pastebin.com or 
something it would be great. Otherwise I will try to reproduce myself 
this scenario and see what's happening.
I'm not sure what version are you using, but the dialog based version 
was only added in 1.7. In 1.6 this function was indeed using the vst/vsf 
headers, and if you don't see them any more in your traces it might mean 
that you somehow copied the uac module from 1.7 to 1.6. Please double 
check that.


Regards,
Răzvan

On 12/15/2011 11:40 PM, Brett Nemeroff wrote:

Razvan,
I'm using the new dialog based method. If I remember right the old way 
was with vsf/vst headers and I'm definitely not using that anymore.


The version I'm using is a svn pull from 1.6.3 (7919), which I think 
is how I'm doing the dialog based version. I'm not quite ready to move 
to 1.7 but I'm close.


These servers I'm having this issue on have quite a bit of load on 
them; but I can try to isolate the issue. Here's some entries that are 
in my log that might help you out:


Dec 15 21:28:07 lcr02 /usr/local/sbin/opensips[1433]: 
ERROR:core:parse_from_header: bad msg or missing FROM header
Dec 15 21:28:07 lcr02 /usr/local/sbin/opensips[1433]: 
ERROR:uac:restore_uris_reply: failed to find/parse FROM hdr
Dec 15 21:30:55 lcr02 /usr/local/sbin/opensips[1432]: 
ERROR:core:parse_to: unexpected char [>] in status 10: 
<<<mailto:sip%3A4056807913@38.123.240.1>>>> .
Dec 15 21:30:55 lcr02 /usr/local/sbin/opensips[1432]: 
ERROR:core:parse_from_header: bad from header
Dec 15 21:30:55 lcr02 /usr/local/sbin/opensips[1432]: 
ERROR:uac:restore_uris_reply: failed to find/parse FROM hdr


What kind of debug would you need? I may be able to replace it on a 
smaller scale.


Thanks!
-Brett

On Thu, Dec 15, 2011 at 4:25 AM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hi, Brett!

Are you using uac_replace_from function with dialog support or the
old approach with route parameters? Would it be possible to
increase OpenSIPS debugging level and paste some extra information?

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/15/2011 12:41 AM, Brett Nemeroff wrote:

Hello List,
I'm sure I brought this up sometime before, but I'm still having
this issue. I have to imagine that some of you out there are
having it as well. Running OpenSIP-1.6.4

I perform a uac_replace_from. It works just fine, But on
subsequent transactions within the dialog, like a BYE that comes
from the destination, the restored From is corrupted IF there was
a port in the original From. This appears to be isolated to cases
where the URI has a port in it.

For example, here's the From from the original INVITE
From: "8005551212 " http://sip:8005551212@1.2.3.4:5070>>;tag=as3371c611.

And then the far end sends a BYE later on:
From: "18705551313 " mailto:sip%3A18705551313@2.3.4.5>>;tag=SDsjh0f99-eb402829

And I relay the BYE:
From: "18705551313 " mailto:sip:18705551313@14.5><4)2$6:^E7>;tag=SDsjh0f99-eb402829

So aside from getting the client to stop sending the port in the
From header, is there another fix for this?

Thanks!
-Brett



___
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 <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/mailman/listinfo/users

Re: [OpenSIPS-Users] uac_replace_from corruption

[Razvan Crainea]

Hello,

Jeff, I was wrong, this feature is not available in 1.6, only in 1.7 .
Anyway, according to Brett's traces it seems to be a problem with the 
function and I would really appreciate if he could help me debugging this.


Regards,
Ra(zvan

On 12/15/2011 07:27 PM, Jeff Pyle wrote:

Brett,

Is the other end an Acme?  If so, they need to implement some custom 
parameters (which I do not have) to//honor some parts of section 12 of 
RFC3261 in such a way that won't break uac_replace_from().  Let me 
know if this is the case and we'll talk more.



Rasvan,

Can you share more about the "new" way to do it with the dialog 
module?  Is this available in 1.6?




- Jeff


___
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_replace_from corruption

[Razvan Crainea]

Hi, Brett!

Are you using uac_replace_from function with dialog support or the old 
approach with route parameters? Would it be possible to increase 
OpenSIPS debugging level and paste some extra information?


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 12/15/2011 12:41 AM, Brett Nemeroff wrote:

Hello List,
I'm sure I brought this up sometime before, but I'm still having this 
issue. I have to imagine that some of you out there are having it as 
well. Running OpenSIP-1.6.4


I perform a uac_replace_from. It works just fine, But on subsequent 
transactions within the dialog, like a BYE that comes from the 
destination, the restored From is corrupted IF there was a port in the 
original From. This appears to be isolated to cases where the URI has 
a port in it.


For example, here's the From from the original INVITE
From: "8005551212" >;tag=as3371c611.


And then the far end sends a BYE later on:
From: "18705551313" >;tag=SDsjh0f99-eb402829


And I relay the BYE:
From: "18705551313" 
;tag=SDsjh0f99-eb402829


So aside from getting the client to stop sending the port in the From 
header, is there another fix for this?


Thanks!
-Brett



___
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] handle_command: delete request failed

[Razvan Crainea]

Hello, Nick!

You should check in your OpenSIPS configuration file if you somehow call 
the unforce_rtp_proxy() command twice. Or perhaps you actually receive 
two BYE messages from the IP phone 2. Perhaps extra debugging for 
RTPProxy will help you understand what really happens.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 12/08/2011 08:39 AM, Nick wrote:

Hi

When Ip phone 1 call to ip phone 2. It's worked.
But When Ip phone 2 interrupt the call.  Ip phone 1 can't interrupt 
the call.


This is my message.

Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:handle_delete: 
forcefully deleting session 1 on ports 36050/36858
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:remove_session: RTP 
stats: 412 in from callee, 320 in from caller, 732 relayed, 0 dropped
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:remove_session: RTCP 
stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:remove_session: 
session on ports 36050/36858 is cleaned up
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:handle_delete: 
forcefully deleting session 2 on ports 53112/55448
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:remove_session: RTP 
stats: 423 in from callee, 39 in from caller, 462 relayed, 0 dropped
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:remove_session: RTCP 
stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped
Dec  8 14:32:51 sfs-staging rtpproxy[19226]: INFO:remove_session: 
session on ports 53112/55448 is cleaned up
Dec  8 14:32:51 sfs-staging /usr/local/sbin/opensips[20252]: ACC: 
transaction answered: 
timestamp=1323325971;method=BYE;from_tag=901652835;to_tag=461a6c34;call_id=5344ebbc-9dbd-4046-8232-9e98bdb56051;code=404;reason=Not 
here
Dec  8 14:33:15 sfs-staging /usr/local/sbin/opensips[20254]: ACC: 
transaction answered: 
timestamp=1323325995;method=BYE;from_tag=461a6c34;to_tag=901652835;call_id=5344ebbc-9dbd-4046-8232-9e98bdb56051;code=404;reason=Not 
here


rtpproxy[19226]: INFO:handle_command: delete request failed: session 
3077c9fd-eaef-6050-5b71-74076673e8dd, tags 2026267135/2030291358 not 
found

rtpproxy can't delete session.

Can everyone can give me a suggest?
Thanks
Nick

___
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] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Ryan!

Unfortunately it won't work. The problem is that the mysql library 
detects both VARCHAR and VARBINARY as string types. Only BLOB and TEXT 
are mapped as binary objects. You can find more information here[1].
As far as I know, only the CDR accounting can generate binary data in 
dialog variables, so if you don't use this feature you can leave it as 
it is for now. But if you find any problems related to dialog 
persistence over restart I strongly advise you to change your columns 
type to the default ones.


[1] http://dev.mysql.com/doc/refman/5.0/en/c-api-data-structures.html

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 08:40 PM, Ryan Bullock wrote:

Could a VARBINARY be used here instead?

We actually use a memory table for the dialog table to reduce load on
our disk and it does not support BLOB or TEXT, so instead we changed
it to a large VARCHAR. The mysql docs suggest you can treat a TEXT the
same as a VARCHAR, but obviously there are differences.


Regards,

Ryan


On Wed, Dec 7, 2011 at 9:51 AM, Jayesh Nambiar  wrote:

Hi Razvan,
This actually solved the problem. Thank you very much. It was defined as
VARCHAR instead of TEXT.
Thank you very much for all the efforts. Really appreciate it. Need to get
hold of my DB guy for the stupid mistake !!

--- Jayesh


On Wed, Dec 7, 2011 at 8:13 PM, Razvan Crainea
wrote:

Hi, Jayesh!

Can you check in your mysql database if the vars column from the dialog
table is declared as TEXT or BLOB and not CHAR? If not, please change your
column into BLOB:

ALTER TABLE dialog CHANGE vars vars BLOB;

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 02:27 PM, Jayesh Nambiar wrote:

Hi Razwan,

This is the pastebin of logs after shutdown:
http://pastebin.com/tvmrSqwB

This is the pastebin of logs after start which is huge:
http://pastebin.com/C6K4Jt5y

--- 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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh!

Can you check in your mysql database if the vars column from the dialog 
table is declared as TEXT or BLOB and not CHAR? If not, please change 
your column into BLOB:


ALTER TABLE dialog CHANGE vars vars BLOB;

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 02:27 PM, Jayesh Nambiar wrote:

Hi Razwan,
This is the pastebin of logs after shutdown:
http://pastebin.com/tvmrSqwB

This is the pastebin of logs after start which is huge:
http://pastebin.com/C6K4Jt5y

--- Jayesh


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

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh!

I need the logs after opensips restarts. The result might also be pretty 
large.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 02:14 PM, Jayesh Nambiar wrote:

Hi Razwan,
I have applied the patch and made it working. Do you still only need 
the logs after opensips shutdown or also the logs after opensips restarts.


--- Jayesh


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

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh!

It seems like the problem appears while parsing the string got from the 
database, so after opensips is restarted. The patch attached should give 
us more information about the error.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 12:37 PM, Jayesh Nambiar wrote:

This is the string what I see when I query the dialog table for vars:

accX_flags#   |accX_db#(  2 1
 11 1002
 12013386166
 919833171405 0 203.153.53.158 203.153.53.136 0 17 0 2 IP India - 
Mobile 919 9198 2 1 2 4 0.0150 0.0130 0 0. 0.0226 1. 6 1 6 1 1 
2 2 2

 Aal Izz Well
 Aal Izz Well 1 3 1.2.3.4|accX_leg#|accX_core# INVITE/ 
100eb870-9e3599cb-13c4-50029-3b71-60de50d0-3b71\# 
97.208.30.751120+1+31850054+b8c0a68/ 
100f7670-9e3599cb-13c4-50029-3b71-3c625412-3b71 200 O á=ÃN
|accX_created#Ã=ÃN|


--- Jayesh

On Wed, Dec 7, 2011 at 4:00 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hi, Jayesh!

And what is the string in the database? You can see it in the
database after you kill opensips with the following command:

select vars from dialog;


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 12:24 PM, Jayesh Nambiar wrote:

Hi Razvan,
Applied the patch and re-tested it. Here the logs that you are
interested in specifically:

Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: Dumping var name:  value: <#026>
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: compare char 22 - 0 - 11
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: compare char 0 - 1 - 12
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: compare char 0 - 2 - 13
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: compare char 0 - 3 - 14
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: Serialized string  (16)
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 0) char: a hex: 61
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 1) char: c hex: 63
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 2) char: c hex: 63
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 3) char: X hex: 58
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 4) char: _ hex: 5F
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 5) char: f hex: 66
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 6) char: l hex: 6C
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 7) char: a hex: 61
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 8) char: g hex: 67
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 9) char: s hex: 73
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 10) char: # hex: 23
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 11) char: #026 hex: 16
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 12) char: #000 hex: 00
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 13) char: #000 hex: 00
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 14) char: #000 hex: 00
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: 15) char: | hex: 7C
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]:
DBG:dialog:write_pair: Dumping var name:  value: <(>

Apart from this, I have pasted everything in syslog after
opensips shutdown in the paste-bin here:
http://pastebin.com/gx0ZxFLb

Let me know if there is anything more to test.

--- Jayesh

On Wed, Dec 7, 2011 at 3:36 PM, Razvan Crainea
mailto:razvancrai...@opensips.org>>
wrote:

Sorr, I forgot to attach it. Here it is.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 11:59 AM, Jayesh Nambiar wrote:

Hi Razvan,
I don't see the patch attached !!

--- Jayesh

On Wed, Dec 7, 2011 at 2:57 PM, Razvan Crainea
mailto:razvancrai...@opensips.org>> wrote:

Hi, Jayesh !

The root of the problem is the accX_flags dialog
variable isn't properly serialized. What I'm trying to
find out is why this happens, that's why I will need
some extra debug as I can't figure out the problem
there. So please apply this last patch and try again. It
should be applied after the previous patch I've sent
you, so you won't need another fresh chec

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh!

And what is the string in the database? You can see it in the database 
after you kill opensips with the following command:


select vars from dialog;

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 12:24 PM, Jayesh Nambiar wrote:

Hi Razvan,
Applied the patch and re-tested it. Here the logs that you are 
interested in specifically:


Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: Dumping var name:  value: <#026>
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: compare char 22 - 0 - 11
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: compare char 0 - 1 - 12
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: compare char 0 - 2 - 13
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: compare char 0 - 3 - 14
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: Serialized string  (16)
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 0) char: a hex: 61
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 1) char: c hex: 63
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 2) char: c hex: 63
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 3) char: X hex: 58
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 4) char: _ hex: 5F
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 5) char: f hex: 66
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 6) char: l hex: 6C
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 7) char: a hex: 61
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 8) char: g hex: 67
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 9) char: s hex: 73
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 10) char: # hex: 23
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 11) char: #026 hex: 16
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 12) char: #000 hex: 00
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 13) char: #000 hex: 00
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 14) char: #000 hex: 00
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: 15) char: | hex: 7C
Dec  7 15:50:33 dev /usr/local/sbin/opensips[8011]: 
DBG:dialog:write_pair: Dumping var name:  value: <(>


Apart from this, I have pasted everything in syslog after opensips 
shutdown in the paste-bin here:

http://pastebin.com/gx0ZxFLb

Let me know if there is anything more to test.

--- Jayesh

On Wed, Dec 7, 2011 at 3:36 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Sorr, I forgot to attach it. Here it is.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 11:59 AM, Jayesh Nambiar wrote:

Hi Razvan,
I don't see the patch attached !!

--- Jayesh

On Wed, Dec 7, 2011 at 2:57 PM, Razvan Crainea
mailto:razvancrai...@opensips.org>>
wrote:

Hi, Jayesh !

The root of the problem is the accX_flags dialog variable
isn't properly serialized. What I'm trying to find out is why
this happens, that's why I will need some extra debug as I
can't figure out the problem there. So please apply this last
patch and try again. It should be applied after the previous
patch I've sent you, so you won't need another fresh checkout.
This time there will be a lot of dumped info in the log, so I
would really appreciate if you could send them over pastebin.
The only part that I will be interested in is between these
lines:


DBG:dialog:write_pair: Dumping var name:  value:
<#026>

and


DBG:dialog:write_pair: Dumping var name:  value: <(>

Thank you very much for testing!
Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 07:57 PM, Jayesh Nambiar wrote:

Hi Razvan,
I just did a fresh download from
http://opensips.org/pub/opensips/latest/src/. I did apply
the patch successfully and I still have the problem of CDR
not being recorded after restart. Here is the syslog pasted
after opensips was being shut down:

Dec  6 20:20:13 dev /usr/local/sbin/opensips[
15700]: DBG:dialog:dialog_update_db: inserting new dialog
0x7f3d323bd5f8
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value:
<#026>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Seria

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Sorr, I forgot to attach it. Here it is.

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/07/2011 11:59 AM, Jayesh Nambiar wrote:

Hi Razvan,
I don't see the patch attached !!

--- Jayesh

On Wed, Dec 7, 2011 at 2:57 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hi, Jayesh !

The root of the problem is the accX_flags dialog variable isn't
properly serialized. What I'm trying to find out is why this
happens, that's why I will need some extra debug as I can't figure
out the problem there. So please apply this last patch and try
again. It should be applied after the previous patch I've sent
you, so you won't need another fresh checkout.
This time there will be a lot of dumped info in the log, so I
would really appreciate if you could send them over pastebin. The
only part that I will be interested in is between these lines:


DBG:dialog:write_pair: Dumping var name:  value: <#026>

and


DBG:dialog:write_pair: Dumping var name:  value: <(>

Thank you very much for testing!
Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 07:57 PM, Jayesh Nambiar wrote:

Hi Razvan,
I just did a fresh download from
http://opensips.org/pub/opensips/latest/src/. I did apply the
patch successfully and I still have the problem of CDR not being
recorded after restart. Here is the syslog pasted after opensips
was being shut down:

Dec  6 20:20:13 dev /usr/local/sbin/opensips[
15700]: DBG:dialog:dialog_update_db: inserting new dialog
0x7f3d323bd5f8
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value: <#026>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (16)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value: <(>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (263)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value: <>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (14)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value: <#006>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: escaping char 53
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (165)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value:
<<95>+ÃN>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string +ÃN> (22)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_dialog_vars: var string is (480)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value:
<1002>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (21)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value:
<1003>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (21)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Dumping var name:  value:
<1007>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_pair: Serialized string  (21)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:dialog:write_dialog_profiles: profile string is
(63)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:db_mysql:has_stmt_ctx: ctx found for dialog
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x810858
(tail=8454488) MC=0x8101b8
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]:
DBG:db_mysql:db_mysql_do_prepared_query: set values for the
statement run

I hope this will help you figure out something more relevant.


--- Jayesh


On Tue, Dec 6, 2011 at 7:56 PM, Razvan Crainea
mailto:razvancrai...@opensips.org>>
wrote:

Hi, Jayesh!

Can you post your dlg_db_handler.c file on pastebin? I think
you are using an old version of the dialog module, and that's
why you have this problem.


Regards,

--
Răzvan Crainea
OpenSIPS Developer



--- modules/dialog/dlg_db_handler.c	2011-12-06 15:48:48.112479173 +0200
+++ modules/dialog/dlg_db_handler.c	2011-12-07 11:22:38.332347513 +0200
@@ -799,6 +799,7 @@
 	}
 	b[j++] = '#';
 	for( i=0 ; val && ilen ; i++) {
+		LM_DBG("compare char 

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh !

The root of the problem is the accX_flags dialog variable isn't properly 
serialized. What I'm trying to find out is why this happens, that's why 
I will need some extra debug as I can't figure out the problem there. So 
please apply this last patch and try again. It should be applied after 
the previous patch I've sent you, so you won't need another fresh checkout.
This time there will be a lot of dumped info in the log, so I would 
really appreciate if you could send them over pastebin. The only part 
that I will be interested in is between these lines:


DBG:dialog:write_pair: Dumping var name:  value: <#026>

and

DBG:dialog:write_pair: Dumping var name:  value: <(>

Thank you very much for testing!
Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 07:57 PM, Jayesh Nambiar wrote:

Hi Razvan,
I just did a fresh download from 
http://opensips.org/pub/opensips/latest/src/. I did apply the patch 
successfully and I still have the problem of CDR not being recorded 
after restart. Here is the syslog pasted after opensips was being shut 
down:


Dec  6 20:20:13 dev /usr/local/sbin/opensips[
15700]: DBG:dialog:dialog_update_db: inserting new dialog 0x7f3d323bd5f8
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <#026>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (16)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <(>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (263)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (14)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <#006>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: escaping char 53
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (165)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <<95>+ÃN>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string +ÃN> (22)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_dialog_vars: var string is (480)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <1002>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (21)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <1003>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (21)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Dumping var name:  value: <1007>
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_pair: Serialized string  (21)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:dialog:write_dialog_profiles: profile string is 
(63)
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:db_mysql:has_stmt_ctx: ctx found for dialog
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x810858 (tail=8454488) 
MC=0x8101b8
Dec  6 20:20:13 dev /usr/local/sbin/opensips[15700]: 
DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run


I hope this will help you figure out something more relevant.


--- Jayesh


On Tue, Dec 6, 2011 at 7:56 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hi, Jayesh!

Can you post your dlg_db_handler.c file on pastebin? I think you
are using an old version of the dialog module, and that's why you
have this problem.


Regards,

--
Răzvan Crainea
OpenSIPS Developer

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

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh!

Something is really weird there. I've attached attached a new patch done 
against a fresh copy. Can you please try this one?


Thanks and regards!

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 01:52 PM, Jayesh Nambiar wrote:

Hi Razvan,
Here are the logs with Dumping var name:

Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:dialog_update_db: inserting new dialog 0x7fa29f2d0708
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <#026>
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <(>
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <>
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <#006>
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: 
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_dialog_vars: var string is (481)
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <1002>
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <1003>
Dec  6 17:24:13 dev /usr/local/sbin/opensips[1958]: 
DBG:dialog:write_pair: Dumping var name:  value: <1007>


Let me know if this helps.

Thanks,

--- Jayesh


On Tue, Dec 6, 2011 at 4:32 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hi, Jayesh!

Can you please apply the patch I've attached? And then mail me
back the log, but this time taken just after OpenSIPS shuts down
with an active dialog. The log should contain the following strings:

"Dumping var name: "

and

"var string is <"

They should appear before OpenSIPS stops with an active dialog, so

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 12:13 PM, Jayesh Nambiar wrote:

Hi Razvan,
The logs with debug level 9 are pasted here:

After restarting I disconnected the call, the dialog matched
perfectly but no CDR record.

--- Jayesh


On Tue, Dec 6, 2011 at 2:50 PM, Razvan Crainea
mailto:razvancrai...@opensips.org>>
wrote:

Hi, Jayesh!

Yes, I will need extra debugging to see what's happening. Can
you send[1] the log in full debugging, taken after OpenSIPS
is restarted?

[1] pastebin.com <http://pastebin.com>


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 08:13 AM, Jayesh Nambiar wrote:

Hi Razvan,
The dialogs are definitely loaded on startup and it also
matches with existing dialog. I use this to make sure the
dialog is matched in my script. So even after a restart, I
see the Dialog Matched in my syslog.

if(has_totag()) {
  if(match_dialog()) {
 log(1, "Dialog Matched");
 route(default_relay);
 exit;
  }
}

But it is just that the cdr insert does not take place after
the restart !!
My debug level was at 3. Do you want more detailed logs to
check??

Thanks,

--- Jayesh

On Mon, Dec 5, 2011 at 7:12 PM, Razvan Crainea
mailto:razvancrai...@opensips.org>> wrote:

Hi Jayesh,

Can you please check if the dialogs are loaded back
after a restart. Also, do you see any errors in your log?

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/05/2011 02:31 PM, Bogdan-Andrei Iancu wrote:

Hi Jayesh,

Razvan is checking the code for you and running some tests.

Regards,
Bogdan

On 12/03/2011 02:49 PM, Jayesh Nambiar wrote:

Hi Bogdan,
Just writing to ask if you got a chance to check if
this is a bug or some error in my config !!

Thanks,

--- Jayesh

On Fri, Dec 2, 2011 at 11:23 AM, Jayesh Nambiar
mailto:jayesh.v...@gmail.com>>
wrote:

Hi Bogdan,
The exact version used is 1.7.1 stable release
compiled from src. Output of opensips -V is:
version: opensips 1.7.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,
 

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi, Jayesh!

Yes, I will need extra debugging to see what's happening. Can you 
send[1] the log in full debugging, taken after OpenSIPS is restarted?


[1] pastebin.com

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/06/2011 08:13 AM, Jayesh Nambiar wrote:

Hi Razvan,
The dialogs are definitely loaded on startup and it also matches with 
existing dialog. I use this to make sure the dialog is matched in my 
script. So even after a restart, I see the Dialog Matched in my syslog.


if(has_totag()) {
  if(match_dialog()) {
 log(1, "Dialog Matched");
 route(default_relay);
 exit;
  }
}

But it is just that the cdr insert does not take place after the 
restart !!

My debug level was at 3. Do you want more detailed logs to check??

Thanks,

--- Jayesh

On Mon, Dec 5, 2011 at 7:12 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hi Jayesh,

Can you please check if the dialogs are loaded back after a
restart. Also, do you see any errors in your log?

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 12/05/2011 02:31 PM, Bogdan-Andrei Iancu wrote:

Hi Jayesh,

Razvan is checking the code for you and running some tests.

Regards,
Bogdan

On 12/03/2011 02:49 PM, Jayesh Nambiar wrote:

Hi Bogdan,
Just writing to ask if you got a chance to check if this is a
bug or some error in my config !!

Thanks,

--- Jayesh

On Fri, Dec 2, 2011 at 11:23 AM, Jayesh Nambiar
mailto:jayesh.v...@gmail.com>> wrote:

Hi Bogdan,
The exact version used is 1.7.1 stable release compiled from
src. Output of opensips -V is:
version: opensips 1.7.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: unknown
@(#) $Id: main.c 8537 2011-11-08 17:02:11Z bogdan_iancu $
main.c compiled on 16:59:52 Dec  1 2011 with gcc 4.4.5

The CDR does not survive a restart. Anything else to be
enabled or added in the script or to be looked at?
Thanks,

--- Jayesh


On Thu, Dec 1, 2011 at 10:35 PM, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Jayesh,

If dialog module has restart persistence ( db modes 1, 2
and 3) the CDRs should survive across a restart. If this
is not the case for you, let me know the exact version
of opensips you are running (do "opensips -V").

Regards,
Bogdan


On 12/01/2011 12:28 PM, Jayesh Nambiar wrote:

Hello All,
I am planning to use CDR accounting in my script
starting from version 1.7 and it looks fine and working
as expected. Although I had one doubt, how do I make
sure the CDR accounting still happens if the opensips
is restarted and BYE comes after the restart. I have
tried db_mode 3 for dialog module so that it dumps all
the dialogs while shutdown and on start it fetches the
dialog from the DB. This method makes sure the dialog
is matched when BYE comes after the restart but the CDR
record is not entered.
Is there any flag or dialog variable that I should set
to insert that value in the table for all dialogs when
opensips shuts off so that opensips knows that the CDR
flag was set for this dialog when started again and it
has to insert the record?
Do let me know for any pointers or ideas to get this done.
Thanks in advance.

--- Jayesh


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



-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
OpenSIPS solutions and "know-how"






-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
OpenSIPS solutions and "know-how"



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

Re: [OpenSIPS-Users] cdr accounting on opensips restart

[Razvan Crainea]

Hi Jayesh,

Can you please check if the dialogs are loaded back after a restart. 
Also, do you see any errors in your log?


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 12/05/2011 02:31 PM, Bogdan-Andrei Iancu wrote:

Hi Jayesh,

Razvan is checking the code for you and running some tests.

Regards,
Bogdan

On 12/03/2011 02:49 PM, Jayesh Nambiar wrote:

Hi Bogdan,
Just writing to ask if you got a chance to check if this is a bug or 
some error in my config !!


Thanks,

--- Jayesh

On Fri, Dec 2, 2011 at 11:23 AM, Jayesh Nambiar 
mailto:jayesh.v...@gmail.com>> wrote:


Hi Bogdan,
The exact version used is 1.7.1 stable release compiled from src.
Output of opensips -V is:
version: opensips 1.7.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: unknown
@(#) $Id: main.c 8537 2011-11-08 17:02:11Z bogdan_iancu $
main.c compiled on 16:59:52 Dec  1 2011 with gcc 4.4.5

The CDR does not survive a restart. Anything else to be enabled
or added in the script or to be looked at?
Thanks,

--- Jayesh


On Thu, Dec 1, 2011 at 10:35 PM, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Jayesh,

If dialog module has restart persistence ( db modes 1, 2 and
3) the CDRs should survive across a restart. If this is not
the case for you, let me know the exact version of opensips
you are running (do "opensips -V").

Regards,
Bogdan


On 12/01/2011 12:28 PM, Jayesh Nambiar wrote:

Hello All,
I am planning to use CDR accounting in my script starting
from version 1.7 and it looks fine and working as expected.
Although I had one doubt, how do I make sure the CDR
accounting still happens if the opensips is restarted and
BYE comes after the restart. I have tried db_mode 3 for
dialog module so that it dumps all the dialogs while
shutdown and on start it fetches the dialog from the DB.
This method makes sure the dialog is matched when BYE comes
after the restart but the CDR record is not entered.
Is there any flag or dialog variable that I should set to
insert that value in the table for all dialogs when opensips
shuts off so that opensips knows that the CDR flag was set
for this dialog when started again and it has to insert the
record?
Do let me know for any pointers or ideas to get this done.
Thanks in advance.

--- Jayesh


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



-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
OpenSIPS solutions and "know-how"






--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
OpenSIPS solutions and "know-how"
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Event module setup

[Razvan Crainea]

Hi, Pete!

I think that registering an event notification using the event_datagram 
module requires a timeout, but the event_rabbitmq doesn't. But what you 
can do is to subscribe the command directly from OpenSIPS script. There 
if you don't specify a timeout, the subscriber will be registered 
forever. You can find more information here[1]


[1] http://www.opensips.org/Resources/DocsCoreFcn#toc148

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 11/30/2011 04:20 PM, Pete Kelly wrote:
One other quick question, the fifo for setting up the listeners 
specifies a timeout...


is it possible to set that to infinity (or until opensips is stopped?)

On 30 November 2011 14:16, Pete Kelly <mailto:pke...@gmail.com>> wrote:


Thanks Razvan.

I used a really simply python script for this... don't know if you
would want to include in the docs?

import socket
server_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server_socket.bind(("", 8085))

print "Server up on 8085"

while 1:
data, address = server_socket.recvfrom(256)
print "( " ,address[0], " " , address[1] , " ) said : ", data






On 30 November 2011 13:14, Razvan Crainea
mailto:razvancrai...@opensips.org>>
wrote:

Hi, Pete!

In order to use OpenSIPS Event Interface, you need to create
an external application that listens for an event. This
application should create the UNIX socket used for
communication, and then subscribe to OpenSIPS for a certain
event, using the event_subscribe MI command. When the event is
raised, OpenSIPS searches all the subscribers registered for
that specific event, and notifies them through the socket
provided at subscription. Therefore it's not OpenSIPS's duty
to create the socket, but the external application.
Let me know if you need any more help.

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 11/30/2011 02:58 PM, Pete Kelly wrote:

Hi

I am using opensips 1.7 and would like to raise an event when
I see a BYE, however I am struggling with the documentation
as it stands. This is what I am doing:

In the script:

if(is_method("BYE")) {
xlog("BYE seen, raising event");
$avp(s:attr) = "number";
$avp(s:val) = 0;
$avp(s:attr) = "string";
$avp(s:val) = "dummy value";
raise_event("E_DUMMY", $avp(s:attr), $avp(s:val));
}


When opensips is started I am issuing this FIFO:

opensipsctl fifo event_subscribe E_DUMMY
unix:/tmp/opensips_event.sock 1800


and I see this in the logs (debug=6)

Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:mi_fifo:mi_parse_tree: adding node <> ; val 
Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:mi_fifo:mi_parse_tree: adding node <> ; val

Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:mi_fifo:mi_parse_tree: adding node <> ; val <1800>
Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:mi_fifo:mi_parse_node: end of input tree
Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:event_datagram:datagram_parse: address is

Nov 30 12:57:00 pk-lenny
/usr/local/opensips/sbin/opensips[4561]:
DBG:event_datagram:datagram_match: socket matched
/tmp/opensips_event.sock:0


However the file /tmp/opensips_event.sock is not created at
all, even when the raise_event function is called.

Am I doing something wrong?


___
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 <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/mailman/listinfo/users

Re: [OpenSIPS-Users] Event module setup

[Razvan Crainea]

Hi, Pete!

In order to use OpenSIPS Event Interface, you need to create an external 
application that listens for an event. This application should create 
the UNIX socket used for communication, and then subscribe to OpenSIPS 
for a certain event, using the event_subscribe MI command. When the 
event is raised, OpenSIPS searches all the subscribers registered for 
that specific event, and notifies them through the socket provided at 
subscription. Therefore it's not OpenSIPS's duty to create the socket, 
but the external application.

Let me know if you need any more help.

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/30/2011 02:58 PM, Pete Kelly wrote:

Hi

I am using opensips 1.7 and would like to raise an event when I see a 
BYE, however I am struggling with the documentation as it stands. This 
is what I am doing:


In the script:

if(is_method("BYE")) {
xlog("BYE seen, raising event");
$avp(s:attr) = "number";
$avp(s:val) = 0;
$avp(s:attr) = "string";
$avp(s:val) = "dummy value";
raise_event("E_DUMMY", $avp(s:attr), $avp(s:val));
}


When opensips is started I am issuing this FIFO:

opensipsctl fifo event_subscribe E_DUMMY unix:/tmp/opensips_event.sock 
1800



and I see this in the logs (debug=6)

Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:mi_fifo:mi_parse_tree: adding node <> ; val 
Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:mi_fifo:mi_parse_tree: adding node <> ; val 

Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:mi_fifo:mi_parse_tree: adding node <> ; val <1800>
Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:mi_fifo:mi_parse_node: end of input tree
Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:event_datagram:datagram_parse: address is 
Nov 30 12:57:00 pk-lenny /usr/local/opensips/sbin/opensips[4561]: 
DBG:event_datagram:datagram_match: socket matched 
/tmp/opensips_event.sock:0



However the file /tmp/opensips_event.sock is not created at all, even 
when the raise_event function is called.


Am I doing something wrong?


___
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] RabbitMQ functionality question

[Razvan Crainea]

Hi, Pete!

Yes, indeed the RabbitMQ currently uses the same value for the exchange 
name and routing key. Also only the '/' vhost can be used for the 
moment, as it is hardcoded in the code. But this module is still under 
development and any new ideas are welcome.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/30/2011 01:52 PM, Pete Kelly wrote:

Hi

I have a question about the RabbitMQ functionality.

The documentation states that the 'exchange' will also be used as the 
'queue' used in RabbitMQ.


In my experience you do not send messages directly to a queue in 
RabbitMQ, you send message which contains


- exchange name
- routing key
- message payload


RabbitMQ then uses the routing key to route the message to the correct 
queue (or onward exchange).


Can you tell me if the RabbitMQ implementation supports this, as it 
sounds like it does not currently... it seems it uses the exchange as 
the routing key as well as exchange?


Pete


___
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] RTPproxy + Opensips 1.7.0

[Razvan Crainea]

e
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: node->rn_disabled = 1, 
node->rn_recheck_ticks = 70, get_ticks = 72
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:rtpp_test: force = 0
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it re-enabled
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 0
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: INFO:handle_command: new 
session 944821033294@192.168.1.206, tag z9hG4bK74406739;1 requested, 
type strong
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18013 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18007 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18017 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18009 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18005 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18001 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18015 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:force_rtp_proxy_body: command sent to rtpproxy, cp = 
E10 , err = 10
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18011 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:force_rtp_proxy_body: rtpproxy returned an error, we 
disable the node
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:create_twinlistener: 
bind to the 18003 port failed, errno = 98: Address already in use
Nov  8 17:53:52 WWW_64Bits rtpproxy[22611]: ERR:handle_command: can't 
create listener
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: node->rn_disabled = 1, 
node->rn_recheck_ticks = 132, get_ticks = 72
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 1
Nov  8 17:53:52 WWW_64Bits ./opensips[22671]: 
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies


However, when I run netstat none of these ports seems to be used...

Best regards,

Sebastien

Le 08/11/2011 13:48, Razvan Crainea a écrit :

Hi Sebastien,

Taking a look into RTPProxy's code, I see that the error 10 is 
returned when it can't create a listener. This happens when RTPProxy 
can't create or bind a socket, or doesn't have enough ports 
allocated. My guess is that in your case it can't bind a socket on 
the interface specified by the "-l" parameter.


Best regards,

--
Ra(zvan Crainea
OpenSIPS Developer


___
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] RTPproxy + Opensips 1.7.0

[Razvan Crainea]

Hi Sebastien,

Taking a look into RTPProxy's code, I see that the error 10 is returned 
when it can't create a listener. This happens when RTPProxy can't create 
or bind a socket, or doesn't have enough ports allocated. My guess is 
that in your case it can't bind a socket on the interface specified by 
the "-l" parameter.


Best regards,

--
Răzvan Crainea
OpenSIPS Developer


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

Re: [OpenSIPS-Users] RTPproxy + Opensips 1.7.0

[Razvan Crainea]

Hi Sebastien,

I think I found out what is your problem. As you noted, there are two 
"select_rtpp_node" functions calls for only one INVITE. The problem is 
that the first time OpenSIPS sends a command to RTPProxy, it receives an 
error. If OpenSIPS detecs the error, it automatically disables the node 
for a while (exactly for rn_recheck_ticks seconds, your second question) 
and tries a new node. As you don't have any different node in the set, 
no RTPProxy can be used and an error is triggered.
You should try to see why RTPProxy returns an error to OpenSIPS 
requests. You can check RTPProxy logs, or try to trace the communication 
between them. I'd be happy to help you if you can provide me any of this 
information.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/08/2011 01:22 PM, Sebastien CRUAUX wrote:

Hi Razvan,

Actually we don't even enter in the rtpp_test function. I added some 
other traces in the select_rtpp_node function :


if (selected_rtpp_set->rtpp_node_count == 1) {
LM_INFO("rtpproxy node count = 1\n");
node = selected_rtpp_set->rn_first;
LM_INFO("node->rn_disabled = %d, 
node->rn_recheck_ticks = %d, get_ticks = 
%d\n",node->rn_disabled,node->rn_recheck_ticks,get_ticks());
if (node->rn_disabled && node->rn_recheck_ticks <= 
get_ticks())

node->rn_disabled = rtpp_test(node, 1, 0);
LM_INFO("result rtpp_test = %d\n", node->rn_disabled);
return node->rn_disabled ? NULL : node;
}

and here is what I get when an INVITE is received :

Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: INFO :: (INVITE) 
rtpproxy set 1
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: node->rn_disabled = 0, 
node->rn_recheck_ticks = 0, get_ticks = 121
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 0
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: node->rn_disabled = 1, 
node->rn_recheck_ticks = 181, get_ticks = 121
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 1
Nov  8 11:19:01 WWW_64Bits ./opensips[24317]: 
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies


You can see we never enter in the "if" :(
Consequently, I have several questions :
- why do we see 2 calls to select_rtpp_node while we have chosen only 
the rtpproxy set 1 ?

- what does the node->rn_recheck_ticks parameter means ?
- do you think the bug is in my opensips.cfg or in the rtpproxy module ?

Thanks a lot for your help.

Best regards,

Sebastien

Le 08/11/2011 12:10, Razvan Crainea a écrit :

Hi Sebastien,

No, if rtpp_test returns 1, it means that the chosen rtpproxy node 
should be disabled for a while. You should try to see why OpenSIPS 
detects the node as disabled.


Regards,
--
Ra(zvan Crainea
OpenSIPS Developer

On 11/07/2011 04:31 PM, Sebastien CRUAUX wrote:

Hi Razvan,

I added some INFO traces in the select_rtpp_node function in order 
to get some clues about what happens (see enclosed file).
Here is what is displayed in my /var/log/messages when an INVITE is 
received :


Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: INFO :: (INVITE) 
rtpproxy set 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 0
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies


This is really weird, if rtpp_test returns 1, it should mean that 
the rtpproxy socket was found right ? Then why do we have an error 
message saying that there are no available proxies ? I'm confused...


Best regards,

Sebastien

Le 04/11/2011 15:23, Razvan Crainea a écrit :

Hi Sebastien,

I will try to replicate this scenario and see if I am getting the 
same behaviour. I will get back to you later.


Regards,
--
Ra(zvan Crainea
OpenS

Re: [OpenSIPS-Users] RTPproxy + Opensips 1.7.0

[Razvan Crainea]

Hi Sebastien,

No, if rtpp_test returns 1, it means that the chosen rtpproxy node 
should be disabled for a while. You should try to see why OpenSIPS 
detects the node as disabled.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/07/2011 04:31 PM, Sebastien CRUAUX wrote:

Hi Razvan,

I added some INFO traces in the select_rtpp_node function in order to 
get some clues about what happens (see enclosed file).
Here is what is displayed in my /var/log/messages when an INVITE is 
received :


Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: INFO :: (INVITE) 
rtpproxy set 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 0
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: entering select_rtpp_node
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: rtpproxy node count = 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
INFO:rtpproxy:select_rtpp_node: result rtpp_test = 1
Nov  7 15:21:38 WWW_64Bits ./opensips[19884]: 
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies


This is really weird, if rtpp_test returns 1, it should mean that the 
rtpproxy socket was found right ? Then why do we have an error message 
saying that there are no available proxies ? I'm confused...


Best regards,

Sebastien

Le 04/11/2011 15:23, Razvan Crainea a écrit :

Hi Sebastien,

I will try to replicate this scenario and see if I am getting the 
same behaviour. I will get back to you later.


Regards,
--
Ra(zvan Crainea
OpenSIPS Developer

On 11/04/2011 04:20 PM, Sebastien CRUAUX wrote:
I also tried to enter the rtpproxy_sock parameters and the set IDs 
in the nh_sockets table and to load the rtpproxy sets from the 
database but it did not work either :(


Sebastien

Le 04/11/2011 11:52, Sebastien CRUAUX a écrit :

Hi Razvan,

Yes I think I declared the rtpproxy sets correctly, unless there is 
some new parameter in the new rtpproxy module that I forgot :


# - rtpproxy params -
modparam("rtpproxy", "rtpproxy_sock", "1 == udp:localhost:12221")
modparam("rtpproxy", "rtpproxy_sock", "2 == udp:localhost:1")

Regards,

Sebastien

Le 04/11/2011 11:44, Razvan Crainea a écrit :

Hi Sebastien,

Are you sure that when you declare the RTPProxy sets you allocate 
them the set identifiers (1 and 2)? Can you send us the 
rtpproxy_sock parameters declaration?


Regards,
--
Ra(zvan Crainea
OpenSIPS Developer

On 11/04/2011 12:27 PM, Sebastien CRUAUX wrote:

Hi,

I am currently migrating my old Opensips 1.6.2 to the new 
Opensips 1.7.0 but I am facing some issues with the configuration 
of rtpproxy.
The version of rtpproxy I am using is the commit 
6b82ff914543d21ff9ddbb797b40a77516348308.


When I start Opensips, the two sets of rtpproxies I configured 
are detected :


INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it enabled
INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it enabled


However, when an INVITE is received by Opensips it seems rtpproxy 
is not found, consequently the SDP body is not rewritten :


INFO :: (INVITE) rtpproxy set 1
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies

More information about my configuration :
- my Opensips/rtpproxy server has 2 IP addresses, one opened on 
the internet, one internal used to communicate with my VoIP/PSTN 
gateway
- I have 2 sets of rtpproxies : the 1st one is in bridge mode for 
VoIP to PSTN or PSTN to VoIP calls, the 2nd one only listens on 
the external IP and is used for SIP to SIP calls


./rtpproxy -u seb -l 172.17.1.126 172.17.1.131 -s 
udp:localhost 12221 -m 18000 -M 18020
./rtpproxy -u seb -l 172.17.1.131 -s udp:localhost 1 -m 
18021 -M 18030


- below is the part of my opensips.cfg file which handles the 
INVITE requests (I just replaced my public IP address with 
xx.xx.xx.xx) :


if (is_method("INVITE")) {
if (registered("location","$fu") && 
registered("location")) {  # if From and To are SIP 
registered : we use rtpproxy 2 (external IP)

setflag(22);
xlog("INFO :: (INVITE) rtpproxy set 2");
}
else 
{ # 
otherwise, SIP to ISUP or ISUP to SIP call : we use rtpproxy 1 
(bridge mode)

xlog("INFO :: (INVITE) rtpproxy set 1");
}
if (has_body("application/sdp")) {
if (isflagset(22)) {
set_rtp_proxy_set("2");
if 
(rtpproxy_offer("",&

Re: [OpenSIPS-Users] RTPproxy + Opensips 1.7.0

[Razvan Crainea]

Hi Sebastien,

I will try to replicate this scenario and see if I am getting the same 
behaviour. I will get back to you later.


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/04/2011 04:20 PM, Sebastien CRUAUX wrote:
I also tried to enter the rtpproxy_sock parameters and the set IDs in 
the nh_sockets table and to load the rtpproxy sets from the database 
but it did not work either :(


Sebastien

Le 04/11/2011 11:52, Sebastien CRUAUX a écrit :

Hi Razvan,

Yes I think I declared the rtpproxy sets correctly, unless there is 
some new parameter in the new rtpproxy module that I forgot :


# - rtpproxy params -
modparam("rtpproxy", "rtpproxy_sock", "1 == udp:localhost:12221")
modparam("rtpproxy", "rtpproxy_sock", "2 == udp:localhost:12222")

Regards,

Sebastien

Le 04/11/2011 11:44, Razvan Crainea a écrit :

Hi Sebastien,

Are you sure that when you declare the RTPProxy sets you allocate 
them the set identifiers (1 and 2)? Can you send us the 
rtpproxy_sock parameters declaration?


Regards,
--
Ra(zvan Crainea
OpenSIPS Developer

On 11/04/2011 12:27 PM, Sebastien CRUAUX wrote:

Hi,

I am currently migrating my old Opensips 1.6.2 to the new Opensips 
1.7.0 but I am facing some issues with the configuration of rtpproxy.
The version of rtpproxy I am using is the commit 
6b82ff914543d21ff9ddbb797b40a77516348308.


When I start Opensips, the two sets of rtpproxies I configured are 
detected :


INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it enabled
INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it enabled


However, when an INVITE is received by Opensips it seems rtpproxy 
is not found, consequently the SDP body is not rewritten :


INFO :: (INVITE) rtpproxy set 1
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies

More information about my configuration :
- my Opensips/rtpproxy server has 2 IP addresses, one opened on the 
internet, one internal used to communicate with my VoIP/PSTN gateway
- I have 2 sets of rtpproxies : the 1st one is in bridge mode for 
VoIP to PSTN or PSTN to VoIP calls, the 2nd one only listens on the 
external IP and is used for SIP to SIP calls


./rtpproxy -u seb -l 172.17.1.126 172.17.1.131 -s udp:localhost 
12221 -m 18000 -M 18020
./rtpproxy -u seb -l 172.17.1.131 -s udp:localhost 1 -m 
18021 -M 18030


- below is the part of my opensips.cfg file which handles the 
INVITE requests (I just replaced my public IP address with 
xx.xx.xx.xx) :


if (is_method("INVITE")) {
if (registered("location","$fu") && 
registered("location")) {  # if From and To are SIP registered 
: we use rtpproxy 2 (external IP)

setflag(22);
xlog("INFO :: (INVITE) rtpproxy set 2");
}
else 
{ # 
otherwise, SIP to ISUP or ISUP to SIP call : we use rtpproxy 1 
(bridge mode)

xlog("INFO :: (INVITE) rtpproxy set 1");
}
if (has_body("application/sdp")) {
if (isflagset(22)) {
set_rtp_proxy_set("2");
if (rtpproxy_offer("","xx.xx.xx.xx")) {
t_on_reply("1");
}
}
else {
set_rtp_proxy_set("1");
if (dst_ip == 172.17.1.131) {
  # my IP address opened to the internet (external IP)
if 
(rtpproxy_offer("ei","xx.xx.xx.xx")) {

t_on_reply("1");
}
}
if (dst_ip == 172.17.1.126) {
  # my internal IP address
if 
(rtpproxy_offer("ie","xx.xx.xx.xx")) {

t_on_reply("1");
}
}
}

}
else {
t_on_reply("2");
}
}


Any idea ? I have been stuck on this issue for a few days, this 
configuration worked fine with my previous versions of Opensips and 
rtpproxy.


Best Regards,

Sebastien


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

Re: [OpenSIPS-Users] RTPproxy + Opensips 1.7.0

[Razvan Crainea]

Hi Sebastien,

Are you sure that when you declare the RTPProxy sets you allocate them 
the set identifiers (1 and 2)? Can you send us the rtpproxy_sock 
parameters declaration?


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 11/04/2011 12:27 PM, Sebastien CRUAUX wrote:

Hi,

I am currently migrating my old Opensips 1.6.2 to the new Opensips 
1.7.0 but I am facing some issues with the configuration of rtpproxy.
The version of rtpproxy I am using is the commit 
6b82ff914543d21ff9ddbb797b40a77516348308.


When I start Opensips, the two sets of rtpproxies I configured are 
detected :


INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it enabled
INFO:rtpproxy:rtpp_test: rtp proxy  found, 
support for it enabled


However, when an INVITE is received by Opensips it seems rtpproxy is 
not found, consequently the SDP body is not rewritten :


INFO :: (INVITE) rtpproxy set 1
ERROR:rtpproxy:force_rtp_proxy_body: no available proxies

More information about my configuration :
- my Opensips/rtpproxy server has 2 IP addresses, one opened on the 
internet, one internal used to communicate with my VoIP/PSTN gateway
- I have 2 sets of rtpproxies : the 1st one is in bridge mode for VoIP 
to PSTN or PSTN to VoIP calls, the 2nd one only listens on the 
external IP and is used for SIP to SIP calls


./rtpproxy -u seb -l 172.17.1.126 172.17.1.131 -s udp:localhost 
12221 -m 18000 -M 18020
./rtpproxy -u seb -l 172.17.1.131 -s udp:localhost 1 -m 18021 
-M 18030


- below is the part of my opensips.cfg file which handles the INVITE 
requests (I just replaced my public IP address with xx.xx.xx.xx) :


if (is_method("INVITE")) {
if (registered("location","$fu") && 
registered("location")) {  # if From and To are SIP registered : 
we use rtpproxy 2 (external IP)

setflag(22);
xlog("INFO :: (INVITE) rtpproxy set 2");
}
else 
{ # 
otherwise, SIP to ISUP or ISUP to SIP call : we use rtpproxy 1 (bridge 
mode)

xlog("INFO :: (INVITE) rtpproxy set 1");
}
if (has_body("application/sdp")) {
if (isflagset(22)) {
set_rtp_proxy_set("2");
if (rtpproxy_offer("","xx.xx.xx.xx")) {
t_on_reply("1");
}
}
else {
set_rtp_proxy_set("1");
if (dst_ip == 172.17.1.131) {
  # my IP address opened to the internet (external IP)
if 
(rtpproxy_offer("ei","xx.xx.xx.xx")) {

t_on_reply("1");
}
}
if (dst_ip == 172.17.1.126) {
  # my internal IP address
if 
(rtpproxy_offer("ie","xx.xx.xx.xx")) {

t_on_reply("1");
}
}
}

}
else {
t_on_reply("2");
}
}


Any idea ? I have been stuck on this issue for a few days, this 
configuration worked fine with my previous versions of Opensips and 
rtpproxy.


Best Regards,

Sebastien


___
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] [NEW] Enhancements of Ratelimit Module

[Razvan Crainea]

Hi all,

The new version of "ratelimit" module on 1.8.0 (trunk) comes with a set 
of major enhancements:



1) Dynamic and flexible pipes

The new version of ratelimit module allows you to create an unlimited 
number of pipes and even more, in a dynamic way at runtime (versus the 
old version where the number of pipes was limited to 16 and they had to 
be statically defined).
This is very helpful when you want to do rate-limiting on a per 
subscriber-base, on a per trunk-base, etc. ; you can create on the fly 
pipes for each subscriber / trunk / gw, etc, without the need of 
pre-defining them.


2) Distributed across multi opensips instances

A major enhancement for this new module is the distributed support for 
rate limiting. Until now, the scope of a pipe was limited to a single 
OpenSIPS instance. This is a problem when you need to perform rate 
limiting for an entire platform. The new ratelimit module has been 
integrated with the CacheDB interface (with redis, memcache support) in 
order to provide distributed pipes, that are visible in all the 
platform. Hence the limitation will no longer be applied for a single 
instance, but for the entire platform as a whole.
Such feature is useful if you have multiple opensips instancing acting 
as a single platform (like a cluster of load-balancers or dispatchers , 
or active-active setups, or multi-SBCs, etc)


You can find documentation about the new module at: 
http://www.opensips.org/html/docs/modules/devel/ratelimit.html


Best regards,

--
Răzvan Crainea
OpenSIPS Developer


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

Re: [OpenSIPS-Users] nathelper config

[Razvan Crainea]

Hi Nick,

What version of OpenSIPS are you using?
Since 1.6.3, the force_rtp_proxy function does exist anymore. It has 
been replaced with rtpproxy_offer/answer functions.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 13.10.2011 11:30, Nick wrote:

Hello

When I start opensips. It display error. Can you give me any suggest? 
Thanks
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t:  
not found
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t:  
not found
Oct 13 16:27:49 [20343] CRITICAL:core:yyerror: parse error in config 
file, line 231, column 19-20: unknown command , 
missing loadmodule?
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t: found 
(1) in module tm [/usr/local/lib64/opensips/modules/]
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t: found (0) 
in module tm [/usr/local/lib64/opensips/modules/]
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t: found 
(0) in module sl [/usr/local/lib64/opensips/modules/]
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t: found 
(0) in module nathelper 
[/usr/local/lib64/opensips/modules/]
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t:  
not found
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t:  
not found
Oct 13 16:27:49 [20343] CRITICAL:core:yyerror: parse error in config 
file, line 251, column 19-20: unknown command , 
missing loadmodule?
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t: found 
(1) in module nathelper 
[/usr/local/lib64/opensips/modules/]
Oct 13 16:27:49 [20343] DBG:core:find_cmd_export_t: found 
(0) in module nathelper 
[/usr/local/lib64/opensips/modules/]

Oct 13 16:27:49 [20343] ERROR:core:main: bad config file (2 errors)

It's my config for nat
#
# $Id: nathelper.cfg 8160 2011-07-12 15:54:30Z bogdan_iancu $
#
# simple quick-start config script including nathelper support

# This default script includes nathelper support. To make it work
# you will also have to install Maxim's RTP proxy. The proxy is enforced
# if one of the parties is behind a NAT.
#
# If you have an endpoing in the public internet which is known to
# support symmetric RTP (Cisco PSTN gateway or voicemail, for example),
# then you don't have to force RTP proxy. If you don't want to enforce
# RTP proxy for some destinations than simply use t_relay() instead of
# route(1)
#
# Sections marked with !! Nathelper contain modifications for nathelper
#
# NOTE !! This config is EXPERIMENTAL !
#
# --- global configuration parameters 

debug=4 # debug level (cmd line: -dd)
fork=yes
log_stderror=yes # (cmd line: -E)

/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/

check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4

db_default_url="postgres://opensips:opensipsrw@10.10.12.100/opensips"
# -- module loading --

#set module path
mpath="/usr/local/lib64/opensips/modules/"

# Uncomment this if you want to use SQL database
#loadmodule "db_mysql.so"

loadmodule "db_postgres.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "signaling.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "uri.so"
loadmodule "acc.so"

# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
#loadmodule "auth.so"
#loadmodule "auth_db.so"

# !! Nathelper
loadmodule "nathelper.so"
#loadmodule "nat_traversal.so"
#loadmodule "rtpproxy.so"
loadmodule "dialog.so"

# - setting module-specific parameters ---

# -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")

# -- usrloc params --
modparam("usrloc", "db_mode", 0)

# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam("usrloc", "db_mode", 2)
# - uri params -
modparam("uri", "use_uri_table", 0)


# - acc params -
/* what sepcial events should be accounted ? */
modparam("acc", "early_media", 1)
modparam("acc", "report_cancels", 1)
/* by default ww do not adjust the direct of the sequential requests.
if you enable this parameter, be sure the enable "append_fromtag"
in "rr" module */
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "log_flag", 1)
modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)

# -- auth params --
# Uncomment if you are using auth module
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this 
config),

# uncomment also the following parameter)
#modparam("auth_db", "password_column", "password")

# !! Nathelper
modparam("usrloc","nat_bflag",6)
modparam("nathelper","sipping_bflag",8)
modparam("nathelper", "ping_nated_only", 1) # Ping only clients b

[OpenSIPS-Users] OpenSIPS RabbitMQ client

[Razvan Crainea]

Hi all,

OpenSIPS has been enhanced with a new module called **event_rabbitmq**. 
This module allows the proxy to feed a RabbitMQ server with useful 
runtime events and information about OpenSIPS.


More exactly, **event_rabbitmq** is designed as a transport module for 
the new OpenSIPS Event Interface and implements a RabbitMQ client able 
to send information to a server using the AMQP protocol. Therefore you 
can take advantage of all the features the Event Interface provides[2]: 
subscribe multiple servers for different events, raise custom events 
from script etc.


For more information about functionalities and usage please visit the 
OpenSIPS **event_rabbitmq** module documentation page[1].


[1] http://www.opensips.org/html/docs/modules/devel/event_rabbitmq.html
[2] http://www.opensips.org/Development/EventNotification

Best regards,

--
Ra(zvan Crainea
OpenSIPS Developer

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

Re: [OpenSIPS-Users] what parameter to use for duration in db extra

[Razvan Crainea]

Hi Akib,

In order to get the call duration, you will have to use the new cdr 
accounting, found in both OpenSIPS 1.7 and trunk.
To do that, you will only have to set the 'cdr_flag' on all the initial 
Invites and the duration will be automatically inserted into the 
database. Therefore the extra field should no longer be present into the 
db_extra list.


Regards,

Răzvan Crainea
OpenSIPS Developer


On 09/16/2011 05:56 PM, Akib Sayyed wrote:
hello guys please tell me what parameter to add in modparam of acc to 
get duration

modparam("acc", "db_extra","caller_id=$fu; callee_id=$tu; \
rpid=$avp(s:rpid); \
duration=$avp(s:duration)\
src_ip=$avp(s:source_ip); \
src_port=$avp(s:source_port); \

sip_proxy_ip=$avp(s:sip_proxy_ip); \

user_agent=$hdr(user-agent); \
contact=$hdr(contact)
")

is it correct

--
Akib Sayyed
Matrix-Shell
akibsay...@gmail.com 
akibsay...@matrixshell.com 
Mob:- +91-966-514-2243



___
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] ACC Module Problem

[Razvan Crainea]

Hi Federico,

Make sure that you set the corresponding flag for the SIP Requests you 
want to account.
Also, I saw you have two extra columns configured in the cfg. Have you 
added those columns into the database too? Because otherwise the mysql 
returns an error (can't find the 'from_uri' and 'to_uri') and the insert 
fails.


Regards,
Ra(zvan

On 09/15/2011 11:00 PM, Federico Varela wrote:

Jeff, thanks for your reply.
No, my acc table is empty (missed_calls table too).

My connection with mysql is true (i use loadbalancer, registration 
store in MySQL).


Thanks.
Federico


From: jp...@fidelityvoice.com
To: users@lists.opensips.org
Date: Thu, 15 Sep 2011 15:13:06 -0400
Subject: Re: [OpenSIPS-Users] ACC Module Problem

Hi Federico,

That's not an error.  That's Opensips letting you know it has 
initialized the prepared statement in the MySQL database.  The ?s are 
part of the statement format.  Depending on your config, you may see 
these for other modules in addition to acc.  I see them a lot for 
dialog in my config after a restart.  Once a statement has been 
initialized for each child process, you won't see them anymore.


Are you sure the data isn't in the table?  If it isn't, there isn't 
any indication here as to why.



- Jeff



On Sep 15, 2011, at 3:07 PM, Federico Varela wrote:

Hello:
My name is Federico. I have a problem with Acc Module in Opensips 1.6.
I can complete a call perfectly, but opensips dont insert data in
mysql acc table.

My configuration is this:

modparam("acc", "early_media", 1)
modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "log_flag", 1)
modparam("acc", "log_missed_flag", 2)
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_url","mysql://root:@localhost/opensips_db")
modparam("acc", "db_extra","from_uri=$fu; to_uri=$tu")

And, my log is this:

Sep 15 16:05:20 oepnsips /usr/sbin/opensips[6663]:
INFO:db_mysql:re_init_statement:  query  is , ptr=(nil)

Why in this SQL string, the values are "?"..

Thanks a lot!!!

Federico



___ 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] invites from registrar through opensips and rtpproxy

[Razvan Crainea]

Hi Alex,

According to your scenario, there is a late negotiation (SDP is 
advertised in 200OK and ACK). I see there is 'rtpproxy_offer' called for 
a 200OK, but I can't see any 'rtpproxy_answer' for an ACK message. 
Perhaps that's why the SDP in the ACK remains the same and I don't think 
it is a correct behaviour.


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 21.09.2011 19:19, hart323 wrote:

Hi All!

I have the following type of problem.

1) Registrar send INVITE to the phone1 and phone2 (through Opensips)
2) Phone1 reply with OK/SDP1 , phone2 reply with OK/SDP2 (through Opensips)
3) Opensips modifies SDP info (IP to RTPPROXY IP and port to some random
port)
4) Registrar send ACK/SDP1 to phone2 and ACK/SDP2 to phone1 (through
Opensips)
5) Opensips only relay

The result is one direction voice.

Here is the following config:

 if (is_method("INVITE") || (is_method("ACK")&&  src_ip !=
"REGISTRAR_IP")) {
 if (rtpproxy_offer("f")) {
 t_on_reply("1");
 } else {
 t_on_reply("2");
 }
 }
 if (is_method("ACK")&&  src_ip == "REGISTRAR_IP") {
 }

onreply_route[1] {
 if(status =~ "180|200"&&  search("Content-Type: application/sdp")) {
 if (nat_uac_test("1")) {
 fix_nated_contact();
 }
 rtpproxy_answer("f");
 }
}

onreply_route[2] {
 if(status =~ "180|200"&&  search("Content-Type: application/sdp")) {
 if (nat_uac_test("1")) {
 fix_nated_contact();
 }
 rtpproxy_offer("f");
 }
}

Here is the debug from rtpproxy when the sessions timeout:

INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 29 in from callee, 25 in from caller, 54
relayed, 0 dropped
INFO:remove_session: RTCP stats: 1 in from callee, 9 in from caller, 10
relayed, 0 dropped
INFO:remove_session: session on ports 39742/*45048 *is cleaned up
INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 867 in from callee, 239 in from caller, 1106
relayed, 0 dropped
INFO:remove_session: RTCP stats: 14 in from callee, 2 in from caller, 16
relayed, 0 dropped
INFO:remove_session: session on ports *42616*/38680 is cleaned up

In the packet dumps bolded values are the ports in modified SDP packet(
after rtpproxy_offer).
Why it is different order of these values? phone2 send to 42616 and goes out
from 38680 (working), but phone1 tries to send to 45048 and opensips drop
this.

Any help?! Plz!

Best regards,
Alex

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/invites-from-registrar-through-opensips-and-rtpproxy-tp6816755p6816755.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
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] cdr_flag not working in v1.7

[Razvan Crainea]

Hi John,

The problem is here:

if (method=="INVITE" || method=="BYE") {
# Write CDR records to the database
setflag(2);
}

For any sequential request, the CDR engine ignores the flag (2 in your 
case). But the standard accounting will still notice it, and therefore 
will log the
BYE into the database. Deleting this lines above should no longer 
account it.
Anyway, I guess that the INVITE has all the fields filled properly 
(especially duration and setuptime), right?


Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 20.09.2011 19:07, John Quick wrote:

My favourite module (dialog) got even better when the cdr_flag option was
added. I use it all the time now.

But it doesn't seem to be working in version 1.7. I know the call is
creating a dialog because db_mode is set to 1 and the record can be seen in
the dialog table while the call is active. However, 2 records are written to
the acc table - one for the INVITE and another for the BYE. So cdr_flag is
being ignored. Is this a problem in v1.7 or have I done something wrong?

Here's the relevant bits from opensips.cfg:
modparam("acc", "db_flag", 2)
modparam("acc", "cdr_flag", 2)
modparam("acc", "db_missed_flag", 3)
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 1)
modparam("acc", "db_extra", "authid=$avp(authid); srcip=$si; called=$rU;
route=$rd; cli=$fU")

modparam("dialog", "db_mode", 1)# 1 during testing; 0 or 3 for
production
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "rr_param", "scdg")  # unique rr tag value in case other
opensips servers in route
modparam("dialog", "default_timeout", 14400)   # default timeout set to 4
hours

route[3]
 if (method=="INVITE" || method=="BYE") {
 # Write CDR records to the database
 setflag(2);
 # ...and missed calls too
 setflag(3);
 }

 if (method=="INVITE") {
 # make OpenSIPS create a dialog record (see dialog module for info)
 create_dialog();
 }

...and my loose routing section:
 if (has_totag()) {
 if (loose_route()) {
 # Attempt to match this request with an existing dialog
 match_dialog();

 # Check authentication of re-invites - don't challenge if from a
known address
 if(method=="INVITE"&&
(!check_address("0","$si","$sp","$proto"))) {
 if (!proxy_authorize("","subscriber")) {
   proxy_challenge("","1");
   exit;
 };
 };

 if (method=="INVITE" || method=="BYE") {
 # Write CDR records to the database
 setflag(2);
 }


John Quick
Smartvox Limited
Web: www.smartvox.co.uk

Smartvox is a limited company, registered in England and Wales, number
5005263.
Registered office: Spectrum House, Dunstable Road, Redbourn, St.Albans,
Herts AL3 7PR




___
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] opensips rtpproxy and nat traversal for invite without register

[Razvan Crainea]

Hi Alexander,

When I try to open the diagram you sent, I receive the following error:

Error 500

java.io.IOException: Operation not permitted
Message: Operation not permitted
RequestURI: /file/n6775967/sip_flow.jpg
Server: n2.nabble.com

Please provide a valid image so we can investigate your scenario.

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 09.09.2011 16:42, hart323 wrote:

Hi!
I have the following type of problem:
http://opensips-open-sip-server.1449251.n2.nabble.com/file/n6775967/sip_flow.jpg

Calls (sip and media) from the outside (ip phone B)  to the inside are
successful (top part of the diagram)
But calls from inside to outside are not (bottom), because Avaya SES send
invites directly to ip-phone B and not forward it to opensips. How can I fix
this?
I think I need to rewrite CONTACT header in the register request of the
phone B to proxy's IP. But what else? How to route to Phone B after proxy
got the packets?

Thanks in advance!

Best regards,
Alexander

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/opensips-rtpproxy-and-nat-traversal-for-invite-without-register-tp6775967p6775967.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
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] cannot resolve hostname

[Razvan Crainea]

Hi,

It seems there is a parsing error. Can you please try again with the 
patch I attached?


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 05.09.2011 12:50, vivid333 wrote:

opensips.cfg
modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890") 
  # I tried localhost, public IP, still not work .

modparam("nathelper", "force_socket", "udp:127.0.0.1:7890")

but I do :
 ping www.google.com
it works.


below is opensips.log:

Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: NOTICE:core:main: 
version: *opensips 1.6.4-2-notls* (i386/linux)
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: INFO:core:main: 
using 32 Mb shared memory
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: INFO:core:main: 
using 1 Mb private memory per process
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
NOTICE:signaling:mod_init: initializing module ...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: INFO:sl:mod_init: 
Initializing StateLess engine
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: INFO:tm:mod_init: 
TM - initializing...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: INFO:rr:mod_init: 
rr - initializing
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:maxfwd:mod_init: initializing...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:usrloc:ul_init_locks: locks array size 512
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:registrar:mod_init: initializing...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:textops:mod_init: initializing...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:dialplan:mod_init: initializing module...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
WARNING:dialplan:dp_load_db: no data in the db
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:siptrace:mod_init: initializing...
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:drouting:dr_init: Dynamic-Routing - initializing
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
INFO:load_balancer:mod_init: Load-Balancer module - initializing
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
WARNING:load_balancer:lb_db_load_data: table "load_balancer" empty
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
WARNING:dispatcher:ds_load_db: no dispatching data in the db -- empty 
destination set
*Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
ERROR:nathelper:new_rtpp_notify_node: cannot resolve hostname 
127.0.0.1:7890*
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
ERROR:nathelper:init_rtpp_notify_list: cannot add rtpproxy to list
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
ERROR:nathelper:mod_init: cannot find any valid rtpproxy to use
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
ERROR:core:init_mod: failed to initialize module nathelper
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: ERROR:core:main: 
error while initializing modules
Sep  5 17:22:10 user-desktop /sbin/opensips[16536]: 
NOTICE:presence:destroy: destroy module ...





Thanking  for your helps in advance, i am looking forward to have your 
reply



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Index: modules/nathelper/timeout_process.c
===
--- modules/nathelper/timeout_process.c	(revision 8343)
+++ modules/nathelper/timeout_process.c	(working copy)
@@ -376,7 +376,7 @@
 	rtpp_lst->mode = crt_rtpp->rn_umode;
 	rtpp_lst->index = 0;
 	rtpp_lst->next = NULL;
-	memcpy(buffer,crt_rtpp->rn_address,strlen(crt_rtpp->rn_address));
+	memcpy(buffer,crt_rtpp->rn_address,strlen(crt_rtpp->rn_address) + 1);
 	p = strrchr(buffer, ':');
 	if (!p) {
 		LM_ERR("invalid address %s\n", crt_rtpp->rn_address);
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Pre append area code to dialed phone number

[Razvan Crainea]

Hello Mike,

If you need to replace the To header, then you must use the 
"uac_replace_to" function [1].


[1] http://www.opensips.org/html/docs/modules/devel/uac.html#id250475

Regards,

--
Răzvan Crainea
OpenSIPS Developer


On 01.09.2011 12:51, Mike O'Connor wrote:

Hi Răzvan

The issue is that the rules are different for each state of Australia,
so I need to select the correct rule bases on the state the customer is
calling from.

I've been reading the dialplan doc page and I do not see a method of
selecting the rules bases on an external non number rules.

So I need another method of rewriting the phone number, the $tU does not
allow R/W so I need another function which will allow me to edit the $tU
field.

Mike




On 1/09/11 4:57 PM, Razvan Crainea wrote:

Hi Mike,

I think that the dialplan module [1] fits in your scenario.
You can use regular expressions to match each state code and append
the corresponding area code.
These rules can be added in your database using OpenSIPS CP.

[1] http://www.opensips.org/html/docs/modules/devel/dialplan.html

Regards,
--
Răzvan Crainea
OpenSIPS Developer

On 31.08.2011 05:39, Mike O'Connor wrote:

Hi All

I need to pre append an area code to phone numbers as configuring the
clients dial plans is driving me mad.

How do I update just the phone number in an invite. The match is
complicated as each state in Australia has a different set of
prefixes which would require the addition of a different area code.

Thanks
Mike


___
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] OpenSIPS start failed

[Razvan Crainea]

Hi,

If you receive this error only for the "alias_db" module, most likely 
this module is not installed.
You should check if this module is included in the "exclude_modules" 
list (in the OpenSIPS Makefile, line ~53).


Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 31.08.2011 15:30, Brett Nemeroff wrote:
On Wed, Aug 31, 2011 at 5:59 AM, Abhishek Jain > wrote:


Hi, I am getting following error in starting Opensips . Initially
it was working fine but when i installed OpenSips-cp and did some
changes in config file. But after making so many changes i am
confused what i did and how to revert back :(


If every single module load fails, you may want to check the mpath and 
be sure it's right.


You can look for typical modules like tm.so and sl.so if you arn't 
sure what your mpath should be. Depending on your distro, this method 
my vary.. For example:


root@opensips1:~# locate tm.so
/usr/local/lib64/opensips/modules/tm.so

So I know my mpath is /usr/local/lib64/opensips/modules

-Brett


___
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] Pre append area code to dialed phone number

[Razvan Crainea]

Hi Mike,

I think that the dialplan module [1] fits in your scenario.
You can use regular expressions to match each state code and append the 
corresponding area code.

These rules can be added in your database using OpenSIPS CP.

[1] http://www.opensips.org/html/docs/modules/devel/dialplan.html

Regards,

--
Ra(zvan Crainea
OpenSIPS Developer


On 31.08.2011 05:39, Mike O'Connor wrote:

Hi All

I need to pre append an area code to phone numbers as configuring the 
clients dial plans is driving me mad.


How do I update just the phone number in an invite. The match is 
complicated as each state in Australia has a different set of prefixes 
which would require the addition of a different area code.


Thanks
Mike


___
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] Syntax errors when running osipsconsole

[Razvan Crainea]

Hi Saul,

I've just committed a fix for those syntax errors. Please try again.

Regards,

Razvan Crainea
OpenSIPS Developer


On 24.08.2011 23:06, Saúl Ibarra Corretgé wrote:

Hi,

I never tried the OpenSIPS console before, but when I wanted to give it a try:

root@nwo:~# osipsconsole
syntax error at /usr/sbin/osipsconsole line 5632, near "if"
syntax error at /usr/sbin/osipsconsole line 5634, near "} else"
syntax error at /usr/sbin/osipsconsole line 5637, near "}"
syntax error at /usr/sbin/osipsconsole line 5649, near "}"
syntax error at /usr/sbin/osipsconsole line 5682, near "}"
Can't use global @_ in "my" at /usr/sbin/osipsconsole line 5692, near "( $#_"
syntax error at /usr/sbin/osipsconsole line 5806, near "}"
Can't use global @_ in "my" at /usr/sbin/osipsconsole line 5818, near "( $#_"
syntax error at /usr/sbin/osipsconsole line 5849, near "}"
Can't use global @_ in "my" at /usr/sbin/osipsconsole line 5857, near "( $#_"
/usr/sbin/osipsconsole has too many errors.

It's a Debian Squeeze system with Perl 5.10.1 (installed off standard 
repositories).

Any idea of what could be going wrong?


Thanks and regards,

--
Saúl Ibarra Corretgé
AG Projects




___
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] opensips problem

[Razvan Crainea]

What message is that error generated for? a Register or a 200 OK? Can 
you send a trace taken on the proxy machine?


Regards,

Razvan Crainea
OpenSIPS Developer


On 24.08.2011 14:13, isshed wrote:

Yes I took a trace. The message is reaching on the proxy.
Also the proxy is running and listening at port 5060 as follows.
netstat -pan | grep 5060
udp0  0 10.199.74.15:5060 
<http://10.199.74.15:5060>   
0.0.0.0:*   21698/opensips
unix  3  [ ] STREAM CONNECTED 15060  
2935/wnck-applet/tmp/orbit-root/linc-b77-0-238b25089197c


Thanks,
Harendra
On Wed, Aug 24, 2011 at 4:39 PM, Razvan Crainea 
mailto:razvancrai...@opensips.org>> wrote:


Hello Isshed,

Are you sure this is not a network problem ? I don't think the
REGISTER message can't event reach OpenSIPS proxy. Try to take a
trace on the proxy machine to see if everything is received.

    Regards,

Razvan Crainea
OpenSIPS Developer


On 24.08.2011 14:04, isshed wrote:

HI All,
I can not register the x-lite softphone to opensips :
I created the user like this:
[r...@openser ~]# opensipsctl add 1001 1001
new user '1001' added"
and i put the username and password in x-lite configuration menu
and put the proxy IP address , and when i trace what is going on
by Ethereal it gives me [destination unreachable (Host
administratively prohibited]
Can anyone please help me resolving this?
Thanks,
Isshed.


___
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 <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/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips problem

[Razvan Crainea]

Hello Isshed,

Are you sure this is not a network problem ? I don't think the REGISTER 
message can't event reach OpenSIPS proxy. Try to take a trace on the 
proxy machine to see if everything is received.


Regards,

Razvan Crainea
OpenSIPS Developer


On 24.08.2011 14:04, isshed wrote:

HI All,
I can not register the x-lite softphone to opensips :
I created the user like this:
[r...@openser ~]# opensipsctl add 1001 1001
new user '1001' added"
and i put the username and password in x-lite configuration menu and 
put the proxy IP address , and when i trace what is going on by 
Ethereal it gives me [destination unreachable (Host administratively 
prohibited]

Can anyone please help me resolving this?
Thanks,
Isshed.


___
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] Some love for the Debian packaging

[Razvan Crainea]

Hi Saul,

You are right, those packages should not need the -dev packages at 
runtime. I will remove them, and also update the Standard version to 3.9.1.


The main problem in compiling OpenSIPS with TLS support by default is 
that openssl is not compatible with the GPL licence, as the public 
repository requires. But considering we use our own repository, we can 
change the Makefile to compile OpenSIPS with TLS support by default.


Are you saying we should change the shebang for the Debian packages into 
/bin/dash or something like that? Because I'm not sure this will solve 
the problems we have with the scripts, as they are not fully compatible 
with dash yet.


Also, regarding the python module, it isn't documented yet. This is 
another reason we are not adding it to the packages. If there is anyone 
who can maintain this module and write the documentation, we would be 
happy to include it in our next releases.


Regards,

Razvan Crainea
OpenSIPS Developer


On 23.08.2011 11:49, Saúl Ibarra Corretgé wrote:

Hi Razvan,

On Aug 23, 2011, at 10:33 AM, Razvan Crainea wrote:


Hi Saul,

On 22.08.2011 20:03, Saúl Ibarra Corretgé wrote:

Hi,

I've been testing the 1.7 branch over the weekend and I found some issues with 
the Debian packaging:

- Some packages depend on -dev libraries when they shouldn't

Can you indicate the packages that are not required?

opensips-dialplan-module depends on libpcre3-dev, opensips-memcache-module 
depends on libmemcached-dev and opensips-json-module depends on libjson0-dev. 
Those are only needed at build time, the runtime dependencies are captured by 
the shlibs:Depends.

opensips-console has a shlibs:Depends, but it doesn't need it.


- Old Debian standards version

Debian stable has 3.9.1.


- No TLS by default? [1]

There are two packages built: with and without TLS[3] support.

If OpenSIPS is built with TLS support it can be disabled, but if it wasn't 
built with support for it it can't be enabled. Is there a reason for not having 
TLS by default on the Debian package rules file?


- Some scripts have /bin/sh in the shebang, but Debian Squeeze (stable) uses 
dash instead of sh, which doesn't provide the same features

As far as I know, on the systems that use dash, /bin/sh is a symlink to dash. 
Anyway, it's true that some scripts are not compliant with dash. Just yesterday 
I committed a fix for opensipsdbctl tool in order to solve this issue. I'll dig 
into more problems today.

Since this is a Debian-specific problem I'd change the shebang in the rules 
file with sed --inplace.


- Python module is not built [2]

The Python module is not built because it is still in Alpha state.

Understood.


Regards,

--
Saúl Ibarra Corretgé
AG Projects





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

Re: [OpenSIPS-Users] Some love for the Debian packaging

[Razvan Crainea]

Hi Saul,

On 22.08.2011 20:03, Saúl Ibarra Corretgé wrote:

Hi,

I've been testing the 1.7 branch over the weekend and I found some issues with 
the Debian packaging:

- Some packages depend on -dev libraries when they shouldn't

Can you indicate the packages that are not required?

- Old Debian standards version
- No TLS by default? [1]

There are two packages built: with and without TLS[3] support.

- Some scripts have /bin/sh in the shebang, but Debian Squeeze (stable) uses 
dash instead of sh, which doesn't provide the same features
As far as I know, on the systems that use dash, /bin/sh is a symlink to 
dash. Anyway, it's true that some scripts are not compliant with dash. 
Just yesterday I committed a fix for opensipsdbctl tool in order to 
solve this issue. I'll dig into more problems today.

- Python module is not built [2]

The Python module is not built because it is still in Alpha state.

Looking at http://www.opensips.org/Development/Development I couldn't find who 
is in charge of the Debian packaging, so if there are no objections I'd like to 
give some love to it :-)

[1]: Is there any reason why we don't build the Debian package with TLS by 
default? Feels very inconvenient if someone wants to test it but the binaries 
don't have support for it.

[2]: The Python module is not built and it lacks documentation. Should we build 
it?


Thanks and regards,

--
Saúl Ibarra Corretgé
AG Projects




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

[3] http://sourceforge.net/projects/opensips/files/OpenSIPS/1.7.0/

Regards,

Razvan Crainea
OpenSIPS Developer


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

Re: [OpenSIPS-Users] OpenSIPS db schema on PostgreSQL

[Razvan Crainea]

Hi Ryan,

I've just committed a fix for this issue on trunk. Please update your 
sources and try again. Let us know if your problem was solved.


Regards

Razvan Crainea
OpenSIPS Developer


On 11.08.2011 21:34, Ryan Revels wrote:

Bogdan,

This is a brand new install so no tables exist. Here is the complete 
output with verbose=1:


# opensipsdbctl create
-e database engine 'postgres' loaded
-e \E[37;33mINFO: creating database opensips ...
-e Creating core table: standard
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"version_t_name_idx" for table "version"

-e Creating core table: acc
NOTICE:  CREATE TABLE will create implicit sequence "acc_id_seq" for 
serial column "acc.id <http://acc.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"acc_pkey" for table "acc"
NOTICE:  CREATE TABLE will create implicit sequence 
"missed_calls_id_seq" for serial column "missed_calls.id 
<http://missed_calls.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"missed_calls_pkey" for table "missed_calls"

-e Creating core table: domain
NOTICE:  CREATE TABLE will create implicit sequence "domain_id_seq" 
for serial column "domain.id <http://domain.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"domain_pkey" for table "domain"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"domain_domain_idx" for table "domain"

-e Creating core table: group
NOTICE:  CREATE TABLE will create implicit sequence "grp_id_seq" for 
serial column "grp.id <http://grp.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"grp_pkey" for table "grp"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"grp_account_group_idx" for table "grp"
NOTICE:  CREATE TABLE will create implicit sequence "re_grp_id_seq" 
for serial column "re_grp.id <http://re_grp.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"re_grp_pkey" for table "re_grp"

-e Creating core table: permissions
NOTICE:  CREATE TABLE will create implicit sequence "address_id_seq" 
for serial column "address.id <http://address.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"address_pkey" for table "address"

-e Creating core table: registrar
NOTICE:  CREATE TABLE will create implicit sequence "aliases_id_seq" 
for serial column "aliases.id <http://aliases.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"aliases_pkey" for table "aliases"

-e Creating core table: usrloc
NOTICE:  CREATE TABLE will create implicit sequence "location_id_seq" 
for serial column "location.id <http://location.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"location_pkey" for table "location"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"location_account_contact_idx" for table "location"

-e Creating core table: msilo
NOTICE:  CREATE TABLE will create implicit sequence "silo_id_seq" for 
serial column "silo.id <http://silo.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"silo_pkey" for table "silo"

-e Creating core table: alias_db
NOTICE:  CREATE TABLE will create implicit sequence "dbaliases_id_seq" 
for serial column "dbaliases.id <http://dbaliases.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"dbaliases_pkey" for table "dbaliases"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"dbaliases_alias_idx" for table "dbaliases"

-e Creating core table: uri_db
NOTICE:  CREATE TABLE will create implicit sequence "uri_id_seq" for 
serial column "uri.id <http://uri.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"uri_pkey" for table "uri"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"uri_account_idx" for table "uri"

-e Creating core table: nathelper
NOTICE:  CREATE TABLE will create implicit sequence 
"nh_sockets_id_seq" for serial column "nh_sockets.id 
<http://nh_sockets.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"nh_sockets_pkey" for table "nh_sockets"

-e Creating core table: speeddial
NOTICE:  CREATE TABLE will create implicit sequence 
"speed_dial_id_seq" for serial column "speed_dial.id 
<http://speed_dial.id>"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"speed_dial_pkey" fo

Re: [OpenSIPS-Users] var/avp persistence, onreply_route, and script context

[Razvan Crainea]

Hi Bobby,

If you want to match the transaction (and dialog) you should explicitly 
arm an "onreply_route" for the initial INVITE:


route {

   ...
   # here gets the initial INVITE
   create_dialog();
   t_on_reply("2"); # arm the onreply_route[2]
   ...

}

# fires when a reply is received for the initial INVITE
onreply_route[2] {

   $dlg_val(cisco) = "true";
   set_dlg_flag("3");
   ...

}

Please let us know if you find any problems.

Regards,

Razvan Crainea
OpenSIPS Developer


On 08.08.2011 23:58, Bobby Smith wrote:

Hi Razvan,

So in trying to do this from the logs, I think that the dialog 
matching doesn't actually happen until the onreply_route processing is 
finished, so I cant access either the dlg_val or the DLG_flags.  Log 
is below.


I should mention this is from the 1.6.4 branch of opensips (not 
current 1.7).



My default route looks like this:

route {
 create_dialog();
 xlog("[REQUEST $ci] :: create dialog for $rm $ru placed in status 
$DLG_status with return code $rc");

 ...
  loose_route();
  xlog("[REQUEST $ci] :: $rm $ru :: PRINT INFORMATION ABOUT DIALOG 
::: dialog status $DLG_status, dialog flags $DLG_flags, dlg_val(cisco) 
$dlg_val(cisco)");

 ...
}

and my onreply looks like this:

onreply_route {
 xlog("[RESPONSE $ci] :: $rs :: PRINTING DIALOG INFO :: dialog 
status $DLG_status, dialog flags $DLG_flags, dlg_val(cisco) 
$dlg_val(cisco)");

  $dlg_val(cisco) = "true";
  set_dlg_flag("3");
 ...
}

And here's the log statements from this occurring:

%011-08-08T20:39:30.574404+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_msg: SIP 
Reply  (status):
2011-08-08T20:39:30.574478+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_msg: 
 version: 
2011-08-08T20:39:30.574498+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_msg:  status: 
<200>
2011-08-08T20:39:30.574513+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_msg:  reason: 

2011-08-08T20:39:30.574529+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_headers: flags=2
2011-08-08T20:39:30.574542+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_to_param: 
tag=25ac01ebd3e5cd73i3
2011-08-08T20:39:30.574558+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_to: end of 
header reached, state=29
2011-08-08T20:39:30.574573+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_to: 
display={}, ruri={sip:test107...@sip.foo.com 
<mailto:sip%3atest107...@sip.foo.com>}
2011-08-08T20:39:30.574587+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:get_hdr_field:  
[67]; uri=[sip:test107...@sip.foo.com 
<mailto:sip%3atest107...@sip.foo.com>]
2011-08-08T20:39:30.574600+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:get_hdr_field: to 
body [mailto:sip%3atest107...@sip.foo.com>>]
2011-08-08T20:39:30.574612+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:get_hdr_field: cseq 
: <1> 
2011-08-08T20:39:30.574629+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_via_param: 
found param type 232,  = ; state=16
2011-08-08T20:39:30.574646+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_via: end of 
header reached, state=5
2011-08-08T20:39:30.574661+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_headers: via 
found, flags=2
2011-08-08T20:39:30.574674+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_headers: this 
is the first via
2011-08-08T20:39:30.574688+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:receive_msg: After 
parse_msg...
2011-08-08T20:39:30.574705+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: [RESPONSE 
1710098c6f37dc00e42e5d0d210ed870@10.2.1.87 
<mailto:1710098c6f37dc00e42e5d0d210ed870@10.2.1.87>] :: 200 :: 
PRINTING DIALOG INFO :: dialog status , dialog flags , 
dlg_val(cisco)
2011-08-08T20:39:30.574720+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: ERROR:core:do_assign: 
setting PV failed
2011-08-08T20:39:30.574734+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: ERROR:core:do_assign: error 
at line: 678
2011-08-08T20:39:30.574751+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: [RESPONSE 
1710098c6f37dc00e42e5d0d210ed870@10.2.1.87 
<mailto:1710098c6f37dc00e42e5d0d210ed870@10.2.1.87>] :: setting 
dlg_val(cisco) to  with DLG_flags = 
2011-08-08T20:39:30.574769+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_headers: 
flags=
2011-08-08T20:39:30.574784+00:00 atlsvsreg02 
/usr/local/opensips/sbin/opensips[28194]: DBG:core:parse_via_param: 
found param type 235,  = <5

Re: [OpenSIPS-Users] var/avp persistence, onreply_route, and script context

[Razvan Crainea]

Hi Bobby,

If you want to match the transaction (and dialog) you should explicitly 
arm an "onreply_route" for the initial INVITE:


route {

   ...
   # here gets the initial INVITE
   create_dialog();
   t_on_reply("2"); # arm the onreply_route[2]
   ...

}

# fires when a reply is received for the initial INVITE
onreply_route[2] {

   $dlg_val(cisco) = "true";
   set_dlg_flag("3");
   ...

}

Please let us know if you find any problems.

Regards,

Razvan Crainea
OpenSIPS Developer

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

Re: [OpenSIPS-Users] var/avp persistence, onreply_route, and script context

[Razvan Crainea]

Hi Bobby,

The $DLG_flags or a $dlg_var(name) are the pseudo variables that should 
help you. In order to use them, you must use create_dialog() [1] for the 
Initial INVITE.
In the sequential requests, you should read the values only after 
loose_route() [2] is called, because there's where the dialog is matched.

Please try again and let us know your results.

[1] http://www.opensips.org/html/docs/modules/devel/dialog.html#id293854
[2] http://www.opensips.org/html/docs/modules/devel/rr.html#loose-route-id

Regards,

Razvan Crainea
OpenSIPS Developer


On 05.08.2011 07:14, Bobby Smith wrote:
Thanks for the suggestion -- unfortunately I saw this previously in a 
thread and thought that'd be the key, but the results from cranking 
debug up the same show it to be a different transaction on receiving 
the ACK and thus the value is null. :(


I've played around with this just a little bit more and by modifying 
the localcache key to be $fU_$ci (from user / callid pair, or some 
tag, or something related to the initial request that's available in 
the script context) I can get it to work how I want, but this really 
just doesn't seem like the right way to do it.



On Fri, Aug 5, 2011 at 12:08 AM, Brett Nemeroff <mailto:br...@nemeroff.com>> wrote:


See if setting this param on helps.

http://www.opensips.org/html/docs/modules/devel/tm.html#id293118
-Brett

On Aug 4, 2011, at 7:48 PM, Bobby Smith mailto:bobby.sm...@gmail.com>> wrote:


All,

Here's why I'm trying to accomplish:

route [subsequent_request] {
   if (has_totag && is_method("ACK") {
 if (MY_VAR = "cisco") {
lookup("location");
... relay and exit
 }
 else {
  ... relay and exit lr
 }
   }
}

onreply_route [foo] {
 
 if($ua =~ "Cisco-CP79") {
  MY_VAR = "cisco"
 }
}

The reasons are not really relevant (it's to get rid of a really
poor UA implementation on older Cisco 79XX firmwares), but my
intent is:

1) Set a transaction-visible-only value in onreply_route [foo]
2) Retrieve it on the ACK that completes the initial invite
transaction.

My problems:

1) if MY_VAR is an $avp, it returns null on retrieving it in the
route[subsequent_request], even with the onreply flag for tm set.
2) if MY_VAR is a $var, it's process global and so, the next
transaction that comes in could share the same state (race)
3) if MY_VAR is a flag, I can't retrieve it in the route
[subsequent request]
4) if MY_VAR is a dlg_flag or a dlg_var, I can't retrieve it in
the subsequent request even if invoking create_dialog as the
first action in the routing script (if it's an initial invite).
5) The only thing I've been able to do is create a unique key via
localcache (with $fU_useragent = myvalue) and fetch it, but this
does not allow multiple UA's to register with the same fU

My question is, is there any way to set a transaction state only
value in an onreply hook, and retrieve it on the ACK?

I know according to the RFC:

   The reason for this separation is rooted in theimportance  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-importance.html>  of
   delivering all 200 (OK) responses to anINVITE  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-invite.html>  to theUAC  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>.  To
   deliver them all to theUAC  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>, theUAS  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uas.html>  alone takes responsibility

   for retransmitting them (see Section 13.3.1.4), and theUAC  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>  alone
   takes responsibility for acknowledging them withACK  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-ack.html>  (see Section
   13.2.2.4).  Since thisACK  <http://rfc-ref.org/RFC-TEXTS/3261/kw-ack.html> 
 is retransmitted only by theUAC  <http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>, it 
is
   effectively considered its owntransaction  
<http://rfc-ref.org/RFC-TEXTS/3261/kw-transaction.html>.


Is there a way to get this associated with the right dialog or
something?  I've tried setting a dialog profile on initial
invite, storing a value in the 200 OK onreply, and retrieving it
as well in the ACK, but I get no dialog has been created (I guess
because the dialog is early or something).


Thanks for the ideas,

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


___
  

Re: [OpenSIPS-Users] all sip body headers regarding video removed

[Razvan Crainea]

Hi Dani,

You can try by deleting the most common video codecs (like H261, H263, 
H264).

You can do that using the codec_delete[1] functions from the textops module.
I think you should also replace the video port with 0.

[1] http://www.opensips.org/html/docs/modules/devel/textops.html#id293910

Regards,

Razvan Crainea
OpenSIPS Developer


On 04.08.2011 18:03, Dani Popa wrote:

Hi,

In fact, i have some problems with one of my pstn gw's that send "400 
Incorrect content length", i think, because of too long sip packet. 
So, because it is pstn, i want to remove video capability(many lines 
in first invite packet).


Dani

On 08/04/11 17:02, Razvan Crainea wrote:

Hi Dani,

Why would you do that? If you don't want to allow video, you can 
simply replace the video port in the "m=" line with 0.


Regards,

Razvan Crainea
OpenSIPS Developer


On 04.08.2011 16:58, Dani Popa wrote:

Hi all,

How can i remove all sip video body headers regardin video. Should i 
remove any line from body after "m=video", or how. Please give me a 
hint, if you have.


Thanks,
Dani

___
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


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

Re: [OpenSIPS-Users] Not enough free memory, will atempt defragmenation

[Razvan Crainea]

Hi Dani,

It seems you are out of memory. What version of OpenSIPS are you using?

Regards,

Razvan Crainea
OpenSIPS Developer


On 04.08.2011 16:07, Dani Popa wrote:

Hi,

How can i solve this kind of problems ? Opensips doesn't crash, but it 
not respond to any sip requests.



Aug  3 07:36:48 test /usr/local/sbin/opensips[29094]: 
WARNING:core:fm_malloc: Not enough free memory, will atempt 
defragmenation
Aug  3 07:36:48 test /usr/local/sbin/opensips[29094]: 
ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 496
Aug  3 07:36:48 test /usr/local/sbin/opensips[29094]: 
ERROR:sl:sl_send_reply_helper: response building failed
Aug  3 07:36:48 test /usr/local/sbin/opensips[29094]: 
ERROR:signaling:sig_send_reply_mod: failed to send reply with sl module
Aug  3 07:36:48 test /usr/local/sbin/opensips[29094]: 
ERROR:auth:challenge: failed to send the response
Aug  3 07:36:48 test /usr/local/sbin/opensips[29085]: 
WARNING:core:fm_malloc: Not enough free memory, will atempt 
defragmenation
Aug  3 07:36:48 test /usr/local/sbin/opensips[29085]: 
ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 529
Aug  3 07:36:48 test /usr/local/sbin/opensips[29085]: 
ERROR:sl:sl_send_reply_helper: response building failed
Aug  3 07:36:48 test /usr/local/sbin/opensips[29085]: 
ERROR:signaling:sig_send_reply_mod: failed to send reply with sl module
Aug  3 07:36:48 test /usr/local/sbin/opensips[29085]: 
ERROR:auth:challenge: failed to send the response
Aug  3 07:36:50 test /usr/local/sbin/opensips[29091]: 
WARNING:core:fm_malloc: Not enough free memory, will atempt 
defragmenation
Aug  3 07:36:50 test /usr/local/sbin/opensips[29091]: 
ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 480
Aug  3 07:36:50 test /usr/local/sbin/opensips[29091]: 
ERROR:sl:sl_send_reply_helper: response building failed
Aug  3 07:36:50 test /usr/local/sbin/opensips[29091]: 
ERROR:signaling:sig_send_reply_mod: failed to send reply with sl module
Aug  3 07:36:50 test /usr/local/sbin/opensips[29091]: 
ERROR:options:opt_reply: failed to send 200 via send_reply
Aug  3 07:36:50 test /usr/local/sbin/opensips[29087]: 
WARNING:core:fm_malloc: Not enough free memory, will atempt 
defragmenation
Aug  3 07:36:50 test /usr/local/sbin/opensips[29087]: 
ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 503
Aug  3 07:36:50 test /usr/local/sbin/opensips[29087]: 
ERROR:sl:sl_send_reply_helper: response building failed
Aug  3 07:36:50 test /usr/local/sbin/opensips[29087]: 
ERROR:signaling:sig_send_reply_mod: failed to send reply with sl module
Aug  3 07:36:50 test /usr/local/sbin/opensips[29087]: 
ERROR:auth:challenge: failed to send the response
Aug  3 07:36:51 test /usr/local/sbin/opensips[29086]: 
WARNING:core:fm_malloc: Not enough free memory, will atempt 
defragmenation
Aug  3 07:36:51 test /usr/local/sbin/opensips[29086]: 
ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 503
Aug  3 07:36:51 test /usr/local/sbin/opensips[29086]: 
ERROR:sl:sl_send_reply_helper: response building failed


Thanks,
Dani

___
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] all sip body headers regarding video removed

[Razvan Crainea]

Hi Dani,

Why would you do that? If you don't want to allow video, you can simply 
replace the video port in the "m=" line with 0.


Regards,

Razvan Crainea
OpenSIPS Developer


On 04.08.2011 16:58, Dani Popa wrote:

Hi all,

How can i remove all sip video body headers regardin video. Should i 
remove any line from body after "m=video", or how. Please give me a 
hint, if you have.


Thanks,
Dani

___
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] 1.7 hangs on disabling rtproxy instances

[Razvan Crainea]

Hi Chris,

I guess the "incorrect port 0" errors appear in the OpenSIPS logs. Do 
you also receive errors in the RTPProxy logs?


OpenSIPS doesn't delete the dialogs because, perhaps, the RTPProxy 
timeout notification is never received.


Regards,

Razvan Crainea
OpenSIPS Developer


On 01.08.2011 11:32, Chris Martineau wrote:


Hi Razvan,

Thanks for the quick response.

I am using 8189.

One other thing, I have been getting individual calls hanging as well 
resulting in calls never clearing down. When I track the times of 
these calls they always coincide to the second with errors on the 
opensips log associated with rtpproxy. Usually incorrect port 0 
errors. Not sure if this is related but get it a lot which is also 
causing a pain as when this happens the timeout on loss of rtp also 
fails so the calls never clear.


Regards

Chris

*From:*users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Razvan Crainea

*Sent:* 01 August 2011 09:24
*To:* users@lists.opensips.org
*Subject:* Re: [OpenSIPS-Users] 1.7 hangs on disabling rtproxy instances

Hi Chris,

What svn revision are you using? I remember you reported this issue, 
but I think this should be fixed in the latest svn.


Regards,

Razvan Crainea
OpenSIPS Developer


On 01.08.2011 10:51, Chris Martineau wrote:

Hi,

I have raised this issue before but now I have had it cause the system 
to go offline overnight.


I noticed the problem initially when you disable an rtpproxy instance 
from the cache screen on opensips-cp. Basically the system would block 
whilst doing a timeout/proxy does not respond process refusing to step 
onto the next proxy resulting in the system just hanging.


This morning the system was hung and on checking the cache noticed one 
of the proxies disabled. Re-enabled it and the system burst back into 
life.


I have 8 rtpproxy instances spread across 2 media servers.

Having multiple instances/servers works okay spreading the load but is 
pretty useless if the system hangs when one of them goes offline! This 
has only been since 1.7 as 1.6 worked fine.


Any help you could offer would be great as this is a major problem.

Regards

Chris

  
  
___

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/mailman/listinfo/users

Re: [OpenSIPS-Users] 1.7 hangs on disabling rtproxy instances

[Razvan Crainea]

Hi Chris,

What svn revision are you using? I remember you reported this issue, but 
I think this should be fixed in the latest svn.


Regards,

Razvan Crainea
OpenSIPS Developer


On 01.08.2011 10:51, Chris Martineau wrote:


Hi,

I have raised this issue before but now I have had it cause the system 
to go offline overnight.


I noticed the problem initially when you disable an rtpproxy instance 
from the cache screen on opensips-cp. Basically the system would block 
whilst doing a timeout/proxy does not respond process refusing to step 
onto the next proxy resulting in the system just hanging.


This morning the system was hung and on checking the cache noticed one 
of the proxies disabled. Re-enabled it and the system burst back into 
life.


I have 8 rtpproxy instances spread across 2 media servers.

Having multiple instances/servers works okay spreading the load but is 
pretty useless if the system hangs when one of them goes offline! This 
has only been since 1.7 as 1.6 worked fine.


Any help you could offer would be great as this is a major problem.

Regards

Chris


___
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] Problem Opensips send two BYE

[Razvan Crainea]

Hi Mickael,

Try to start a ngrep on the proxy. You will see exactly who sends the 
second BYE.

Does this scenario happen for every call?

Regards,

Razvan Crainea
OpenSIPS Developer


On 29.07.2011 16:33, mick...@winlux.fr wrote:

Hi Razvan,

I crated:
/#The local route is executed automatically when a new SIP request is generated 
by TM, internally (no UAC side)
local_route {
 xlog("L_INFO","Local Route Method $rm - fu : $fu , ru : $ru , si : $si 
\n");
 if (is_method("BYE") ) {
 xlog("L_INFO","internally generated BYE");
 }
}
/
But  I see no  BYE  sent by my  proxy!
Function  is working correctly  because I see  the  local OPTIONS  drouting  
generated.
And yet, with  wireskark, I see that  the second  BYE,comes from my  OpenSIPS.
I don't understand  ...


  On Fri, 29 Jul 2011 15:38:47 +0300, Razvan Crainea wrote:
>  Hi Mickael,
>
>  The function was also added in OpenSIPS 1.6.4 in svn revision 8195.
>  If you script is dialog aware, then using this function will work.
>  You can catch the locally generated BYE in a local_route. There you
>  can use this function to test if the BYE has already been relayed.
>
>  Regards,
>
>  Razvan Crainea
>  OpenSIPS Developer
>
>
>  On 29.07.2011 15:20, mick...@winlux.fr wrote:
>>  Thanks Razvan,
>>  my version is 1.6.4-2-tls (svn revision: 2:8151)
>>  but this function will work in ? knowing that my OpenSIPS generate this 
second BYE.
>>
>>  Ex:
>>  - UAC -->  BYE -->  Opensips -->  BYE -->  provider
>>  after 0,01s
>>  - Opensips -->  BYE -->  provider
>>  after
>>  - provider -->  500 error ->  opensips
>>
>>  Regards,
>>
>>  On Fri, 29 Jul 2011 15:11:29 +0300, Razvan Crainea wrote:
>>>  Hi Mickael,
>>>
>>>   What version of OpenSIPS are you using? You can find a useful
>>>  function on trunk: test_and_set_dlg_flag [1]
>>>   This function is executed atomically, so you can set a flag for the
>>>  first BYE. When the second BYE comes, if the flag is set you can
>>>  ignore it.
>>>
>>>   Regards,
>>>
>>>   [1]
>>>  http://www.opensips.org/html/docs/modules/devel/dialog.html#id294480
>>>  [3]
>>>
>>>  Razvan Crainea
>>>  OpenSIPS Developer
>>>
>>>   On 29.07.2011 14:54, mick...@winlux.fr [4] wrote:
>>>
>>>>  I'm sorry if you receive this message twice, I had a problem sending
>>>>  mail to users mailing list
>>>>
>>>>  So 
>>>>
>>>>  I list,
>>>>
>>>>  I have a little problem with my proxy
>>>>  (OpenSIPS/1.6.4-2-tls/i386/freebsd) and my voip provider
>>>>  (CISCO-SBC/2.x and CS2000_NGSS/9.0).
>>>>
>>>>  In fact, my opensips send 2 BYE (Screenshot below)
>>>>
>>>>  2.2.2.2, 1.1.1.1, 3.3.3.3 are public IP
>>>>
>>>>  - My UAC (2.2.2.2) send BYE to my proxy Opensips (1.1.1.1), Opensips
>>>>  resend this BYE to my provider (3.3.3.3).
>>>>  - But after 0.01s my proxy send second BYE to my provider.
>>>>  - Therefore my provider answer with 500 error.
>>>>  - I think my proxy hangup dial and transfer this error to my UAC.
>>>>  - But my provider send a 200OK after this error.
>>>>
>>>>  Why my proxy send 2 BYE ? Timer is to short ? how to change this
>>>>  timer? Is T1 default value 500ms ?
>>>>
>>>>  -- BYE configuration (simple configuration):
>>>>
>>>>  _if (is_method("BYE"))_
>>>>  _ {_
>>>>  _ t_on_reply("4");_
>>>>  _
>>>>
>>>
>>>  
xlog("L_INFO","
>>>
>>>>  n");_
>>>>  _ xlog("L_INFO","END OF CALL : call-id $ci n");_
>>>>  _ if($avp(s:debugcall)=~"yes"){ xlog("L_INFO","In HAS_TOTAG - Method
>>>>  BYE - fu : $fu , ru : $ru , si : $si n"); }_
>>>>  _
>>>>
>>>
>>>  
xlog("L_INFO","
>>>
>>>>  n");_
>>>>
>>>>  _ setflag(1); # do accounting ..._
>>>>  _ setflag(2); #missed call ..._
>>>>  _ setflag(3); # ... even if the transaction fails_
>>>>  _ setflag(4); #flag dialog___
>>>>
>>>>  _ 

Re: [OpenSIPS-Users] Problem Opensips send two BYE

[Razvan Crainea]

Hi Mickael,

The function was also added in OpenSIPS 1.6.4 in svn revision 8195.
If you script is dialog aware, then using this function will work.
You can catch the locally generated BYE in a local_route. There you can 
use this function to test if the BYE has already been relayed.


Regards,

Razvan Crainea
OpenSIPS Developer


On 29.07.2011 15:20, mick...@winlux.fr wrote:

Thanks Razvan,
my version is 1.6.4-2-tls (svn revision: 2:8151)
but this function will work in ? knowing that my OpenSIPS generate 
this second BYE.


Ex:
- UAC --> BYE --> Opensips --> BYE --> provider
after 0,01s
- Opensips --> BYE --> provider
after
- provider --> 500 error -> opensips

Regards,

On Fri, 29 Jul 2011 15:11:29 +0300, Razvan Crainea wrote:

Hi Mickael,

 What version of OpenSIPS are you using? You can find a useful
function on trunk: test_and_set_dlg_flag [1]
 This function is executed atomically, so you can set a flag for the
first BYE. When the second BYE comes, if the flag is set you can
ignore it.

 Regards,

 [1]
http://www.opensips.org/html/docs/modules/devel/dialog.html#id294480
[3]

Razvan Crainea
OpenSIPS Developer

 On 29.07.2011 14:54, mick...@winlux.fr [4] wrote:


I'm sorry if you receive this message twice, I had a problem sending
mail to users mailing list

So 

I list,

I have a little problem with my proxy
(OpenSIPS/1.6.4-2-tls/i386/freebsd) and my voip provider
(CISCO-SBC/2.x and CS2000_NGSS/9.0).

In fact, my opensips send 2 BYE (Screenshot below)

2.2.2.2, 1.1.1.1, 3.3.3.3 are public IP

- My UAC (2.2.2.2) send BYE to my proxy Opensips (1.1.1.1), Opensips
resend this BYE to my provider (3.3.3.3).
- But after 0.01s my proxy send second BYE to my provider.
- Therefore my provider answer with 500 error.
- I think my proxy hangup dial and transfer this error to my UAC.
- But my provider send a 200OK after this error.

Why my proxy send 2 BYE ? Timer is to short ? how to change this
timer? Is T1 default value 500ms ?

-- BYE configuration (simple configuration):

_if (is_method("BYE"))_
_ {_
_ t_on_reply("4");_
_



xlog("L_INFO"," 


n");_
_ xlog("L_INFO","END OF CALL : call-id $ci n");_
_ if($avp(s:debugcall)=~"yes"){ xlog("L_INFO","In HAS_TOTAG - Method
BYE - fu : $fu , ru : $ru , si : $si n"); }_
_



xlog("L_INFO"," 


n");_

_ setflag(1); # do accounting ..._
_ setflag(2); #missed call ..._
_ setflag(3); # ... even if the transaction fails_
_ setflag(4); #flag dialog___

_ if(is_present_hf("Proxy-Authorization"))_
_ {_
_ remove_hf("Proxy-Authorization");_
_ }_

_ t_relay();_
_ }_

-- On reply configuration (for a test I wanted to delete the 500
message, but impossible to remove) :

_onreply_route[4]_
_{_
_ xlog("L_INFO","$ci In ONREPLY ROUTE 4 - fu : $fu , ru : $ru , si :
$si , status : $rs n");_
_ if( t_check_status("500") ){_
_ xlog("L_INFO","DROP 500n");_
_ drop();___
_ }_
_}_

After several days of searching, Im stranded. So Id like your
opinion about it.

PS: complete sip capture.

thank in advance

Mickael

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



Links:
--
[1] mailto:Users@lists.opensips.org
[2] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[3] http://www.opensips.org/html/docs/modules/devel/dialog.html#id294480
[4] mailto:mick...@winlux.fr




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