date:20120103

Re: [OpenSIPS-Users] (no subject)

2012-01-03 Thread goup2010

Now all is OK!
Thanks!

2012/1/3 Razvan Crainea 

>  Hi, Plamen!
>
> I have just committed a fix for this. Please update your sources and try
> again.
>
> Regards,
> Ră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 
> listUsers@lists.opensips.orghttp://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] (no subject)

2012-01-03 Thread 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] Users Digest, Vol 42, Issue 8

2012-01-03 Thread auto-reply from antonio.spirande...@longwave.eu

Sarò assente fino all'8 Gennaio compreso. Per urgenze 
rivolgersi direttamente ad assiste...@longwave.eu o 
chiamare lo 0522375500. Saluti

I will be out of office untill  Gen 8th 2012.

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

[OpenSIPS-Users] (no subject)

2012-01-03 Thread goup2010

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

Re: [OpenSIPS-Users] load_balance not using group id in failure route

2012-01-03 Thread Steven Lam, KeenSystems B.V.

Hi Răzvan,

Okay, thank you!
I'll investigate what I can do with the dispatcher.

Steven

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: dinsdag 3 januari 2012 15:41
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] load_balance not using group id in failure route

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,


--

Răzvan Crainea

OpenSIPS Developer

On 01/03/2012 04:31 PM, Steven Lam, KeenSystems B.V. wrote:
Hi Ră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,



--

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

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 7

2012-01-03 Thread auto-reply from antonio.spirande...@longwave.eu

Sarò assente fino all'8 Gennaio compreso. Per urgenze 
rivolgersi direttamente ad assiste...@longwave.eu o 
chiamare lo 0522375500. Saluti

I will be out of office untill  Gen 8th 2012.

___
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

2012-01-03 Thread 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] *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
___
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

2012-01-03 Thread Steven Lam, KeenSystems B.V.

Hi Ră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,


--

Ră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] Users Digest, Vol 42, Issue 6

2012-01-03 Thread auto-reply from antonio.spirande...@longwave.eu

Sarò assente fino all'8 Gennaio compreso. Per urgenze 
rivolgersi direttamente ad assiste...@longwave.eu o 
chiamare lo 0522375500. Saluti

I will be out of office untill  Gen 8th 2012.

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

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

2012-01-03 Thread 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] Getting error while Starting Opensips

2012-01-03 Thread Faisal Rehman

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

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

2012-01-03 Thread Sammy Govind

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

[OpenSIPS-Users] Getting error while Starting Opensips

2012-01-03 Thread Faisal Rehman

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

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 5

2012-01-03 Thread auto-reply from antonio.spirande...@longwave.eu

Sarò assente fino all'8 Gennaio compreso. Per urgenze 
rivolgersi direttamente ad assiste...@longwave.eu o 
chiamare lo 0522375500. Saluti

I will be out of office untill  Gen 8th 2012.

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

Re: [OpenSIPS-Users] ACK not relaying - no NAT problem - SOLVED

2012-01-03 Thread samuel

I've located the problem:

I had a
sl_send_reply("100","Trying");

just at the start of the config file and when the ACK reached this point,
it was absorvedI'm not sure it it should be the right behaviour but at
least I can now make an if-else or similar for these cases.

Apologies for the noise,
Samuel.

On 3 January 2012 14:01, samuel  wrote:

> Hi folks,
>
> I've seeing a weird issue with an opensips 1.7.1 installation and the
> standard configuration. I can provide more information if required but it
> looks like the ACK is absorved without being relayed. This ACK is the 3-rd
> handshake of the session initiation, not an acknowledge. The INVITE-180
> Ringing-200 OK is sent between endpoints (blink 0.2.8 and sylkerver 1.3.0)
> but when the sylkservers send the ACK to Blink, the SIP proxy, it does not
> forward it:
>
>
> T IP.adress.of.Blink:47793 -> IP.adress.of.Opensips:5060 [AP]
>   ACK sip:666159...@ip.adress.of.Sylkserver:5060
>   SIP/2.0..Via: SIP/2.0/tcp
> IP.adress.of.Blink:47793;rport;branch=z9hG4bKPj7YGMzdPHc9T.PIoWqBj6f21w50CkGByH
>   Max-Forwards: 70
>   From: "Samuel"  >;tag=CRRPKM1rHO8cSe8vkBJNL93KupfjkiwC
>   To: ;tag=tnoBz19pYIcw9QmTB90CP3hC6g7Mdayk
>   Call-ID: -SAKz4FlDSJ0rjEks.EUC5LTOlsttkFa
>   CSeq: 19923 ACK
>   Route:
> 
>   Route: 
>   User-Agent: Blink 0.2.8 (Linux)
>   Content-Length:  0
>
> Opensips' logs contain the following lines:
>
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_msg:  method:  
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_msg:  uri: 
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_msg:  version: 
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_headers: flags=2
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_via_param: found param type 235,  = ; state=6
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_via_param: found param type 232,  =
> ; state=16
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_via:
> end of header reached, state=5
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_headers: via found, flags=2
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_headers: this is the first via
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:receive_msg: After parse_msg...
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:receive_msg: preparing to run routing scripts...
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:sl:sl_filter_ACK: to late to be a local ACK!
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:parse_headers: flags=100
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:maxfwd:is_maxfwd_present: value = 70
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:destroy_avp_list: destroying list (nil)
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
> DBG:core:receive_msg: cleaning up
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
> DBG:tm:cleanup_uac_timers: RETR/FR timers reset
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]: DBG:tm:t_unref:
> UNREF_UNSAFE: [0x7f173201f8d8] after is 0
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
> DBG:core:destroy_avp_list: destroying list (nil)
> Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
> DBG:core:receive_msg: cleaning up
>
> It looks like the ACK is not even passed to route(0) because I do not see
> anything from the config line appeared and no matter which log I setup in
> the start, its not rendered in the logs.
>
> I'm using dialog module with db_mode 1 to trace dialogs in database, so
> the ACK might trigger a hook in this module.
> I'm also using mediaproxy with dialog built-in hooks, engage_mediaproxy()
> # account only INVITEs
> if (is_method("INVITE")) {
> setflag(1); # do accounting
>
> #modifications
> create_dialog("PpB");
> $dlg_val(caller) = $fu;
> $dlg_val(callee) = $ru;
>
> engage_media_proxy();
>
> }
>
> Does anyone see any issue with the ACK or any hint to look into the
> configuration file so I can trace why the ACK is not sent?
>
> Thank you very much in advance and apologies for the longitude,
>
> Samuel.
>
>
___
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

2012-01-03 Thread 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] Users Digest, Vol 42, Issue 4

2012-01-03 Thread auto-reply from antonio.spirande...@longwave.eu

Sarò assente fino all'8 Gennaio compreso. Per urgenze 
rivolgersi direttamente ad assiste...@longwave.eu o 
chiamare lo 0522375500. Saluti

I will be out of office untill  Gen 8th 2012.

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

[OpenSIPS-Users] ACK not relaying - no NAT problem

2012-01-03 Thread samuel

Hi folks,

I've seeing a weird issue with an opensips 1.7.1 installation and the
standard configuration. I can provide more information if required but it
looks like the ACK is absorved without being relayed. This ACK is the 3-rd
handshake of the session initiation, not an acknowledge. The INVITE-180
Ringing-200 OK is sent between endpoints (blink 0.2.8 and sylkerver 1.3.0)
but when the sylkservers send the ACK to Blink, the SIP proxy, it does not
forward it:


T IP.adress.of.Blink:47793 -> IP.adress.of.Opensips:5060 [AP]
  ACK sip:666159...@ip.adress.of.Sylkserver:5060
  SIP/2.0..Via: SIP/2.0/tcp
IP.adress.of.Blink:47793;rport;branch=z9hG4bKPj7YGMzdPHc9T.PIoWqBj6f21w50CkGByH
  Max-Forwards: 70
  From: "Samuel" ;tag=CRRPKM1rHO8cSe8vkBJNL93KupfjkiwC
  To: ;tag=tnoBz19pYIcw9QmTB90CP3hC6g7Mdayk
  Call-ID: -SAKz4FlDSJ0rjEks.EUC5LTOlsttkFa
  CSeq: 19923 ACK
  Route: 
  Route: 
  User-Agent: Blink 0.2.8 (Linux)
  Content-Length:  0

Opensips' logs contain the following lines:

Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_msg:
method:  
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_msg:
uri: 
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_msg:
version: 
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: flags=2
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_via_param: found param type 235,  = ; state=6
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_via_param: found param type 232,  =
; state=16
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_via:
end of header reached, state=5
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: via found, flags=2
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: this is the first via
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:receive_msg: After parse_msg...
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:receive_msg: preparing to run routing scripts...
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:sl:sl_filter_ACK: to late to be a local ACK!
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: flags=100
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:maxfwd:is_maxfwd_present: value = 70
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:destroy_avp_list: destroying list (nil)
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:receive_msg: cleaning up
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
DBG:tm:cleanup_uac_timers: RETR/FR timers reset
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]: DBG:tm:t_unref:
UNREF_UNSAFE: [0x7f173201f8d8] after is 0
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
DBG:core:destroy_avp_list: destroying list (nil)
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
DBG:core:receive_msg: cleaning up

It looks like the ACK is not even passed to route(0) because I do not see
anything from the config line appeared and no matter which log I setup in
the start, its not rendered in the logs.

I'm using dialog module with db_mode 1 to trace dialogs in database, so the
ACK might trigger a hook in this module.
I'm also using mediaproxy with dialog built-in hooks, engage_mediaproxy()
# account only INVITEs
if (is_method("INVITE")) {
setflag(1); # do accounting

#modifications
create_dialog("PpB");
$dlg_val(caller) = $fu;
$dlg_val(callee) = $ru;

engage_media_proxy();

}

Does anyone see any issue with the ACK or any hint to look into the
configuration file so I can trace why the ACK is not sent?

Thank you very much in advance and apologies for the longitude,

Samuel.
___
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

2012-01-03 Thread Steven Lam, KeenSystems B.V.

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

Re: [OpenSIPS-Users] Memory allocation failure

2012-01-03 Thread Wesley Volcov

Hello Vlad,

I updated my OpenSIPS 1.6.2 version. At the moment, the problem did not
occur again.
I hope that the problem has been resolved.
Thanks for the suggestion!

Happy new year!

Cheers!

On 30 December 2011 14:55, Vlad Paiu  wrote:

>  Hello,
>
> Seems you have encountered a memory leak. Might have been fixed in more
> recent OpenSIPS releases, but if upgrading is not an option for you, please
> follow the tutorial at http://www.opensips.org/Resources/DocsTsMem and
> attach on pastebin the output of the memory dump that OpenSIPS will
> generate at shutdown or when you send the SIGUSR1 signal. Preferably kill
> OpenSIPS or send a signal immediately after you first encounter the pkg out
> of memory messages.
>
> Regards,
> Vlad
>
> Pe 12/28/2011 9:31 PM, Wesley Volcov a scris:
>
> Hello Guys,
>
> Someone know this error ?
>
> I'm using opensips 1.6.1 with rtpproxy 1.2.1 and Centos 6.0.
>
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:sl:sl_send_reply_helper: response building failed
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27116]:
> ERROR:core:do_action: memory allocation failure
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27116]:
> ERROR:core:pv_set_ruri_user: do action failed
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27116]:
> ERROR:dialplan:dp_update: falied to set the output value!
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27116]:
> ERROR:dialplan:dp_translate_f: cannot set the output
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 350
> Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:sl:sl_send_reply_helper: response building failed
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27118]:
> ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 382
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27118]:
> ERROR:sl:sl_send_reply_helper: response building failed
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:core:received_builder: out of pkg memory
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:core:build_res_buf_from_sip_req: received_builder failed
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:sl:sl_send_reply_helper: response building failed
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27118]:
> ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 363
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27118]:
> ERROR:sl:sl_send_reply_helper: response building failed
> Dec 28 14:01:10 veoscol /usr/local/sbin/opensips[27117]:
> ERROR:core:parse_headers: pkg memory allocation failed
>
> Best regards!
>
> --
> Wesley Volcov
> Email: wesleyvol...@gmail.com
> Messenger: vol...@live.com
> Mobile: +55 11 7999-7444
> Website: http://volcov.blogspot.com
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>


-- 
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 7999-7444
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 3

2012-01-03 Thread auto-reply from antonio.spirande...@longwave.eu

Sarò assente fino all'8 Gennaio compreso. Per urgenze 
rivolgersi direttamente ad assiste...@longwave.eu o 
chiamare lo 0522375500. Saluti

I will be out of office untill  Gen 8th 2012.

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

Re: [OpenSIPS-Users] exec_avp in timer route

2012-01-03 Thread 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] (no subject)

Re: [OpenSIPS-Users] (no subject)

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 8

[OpenSIPS-Users] (no subject)

Re: [OpenSIPS-Users] load_balance not using group id in failure route

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 7

Re: [OpenSIPS-Users] load_balance not using group id in failure route

Re: [OpenSIPS-Users] load_balance not using group id in failure route

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 6

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

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

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

[OpenSIPS-Users] Getting error while Starting Opensips

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 5

Re: [OpenSIPS-Users] ACK not relaying - no NAT problem - SOLVED

Re: [OpenSIPS-Users] load_balance not using group id in failure route

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 4

[OpenSIPS-Users] ACK not relaying - no NAT problem

Re: [OpenSIPS-Users] load_balance not using group id in failure route

Re: [OpenSIPS-Users] Memory allocation failure

Re: [OpenSIPS-Users] Users Digest, Vol 42, Issue 3

Re: [OpenSIPS-Users] exec_avp in timer route

22 matches

Site Navigation

Mail list logo

Footer information