Re: [OpenSIPS-Users] Opensips as proxy, config problem on INVITES

2016-06-08 Thread Benjamin Cropley 
There's quite a lot of trace to go through there, but this screams that
you're looping to me.. I suggest you look at the routing on the OTHER
boxes, see if you can spot something that might be doing that.

On Tue, May 31, 2016 at 11:07 AM, Saioa Perurena <
saioa.perur...@enigmedia.es> wrote:

> Hi,
>
> We have only one proxy Opensips (version 1.11) that does all the work
> (register's, invite's, tls conection...) on a DMZ behind a firewall.
>
> We want to move that to a new schema, with one Opensips (version 2.1)
> as a frontend that handles the tls connections (with a public ip) on
> the DMZ, and another Opensips (version 1.11) at the backend (with
> private ip), but we are not able to complete the invite signaling
> correctly. Register, message, options worked ok, but we have problems
> with the invite.
> The invite request arrives to the callee, and the OK answers arrives
> to the caller, but the caller does not send and ACK to this OK, so the
> callee keeps sending OK until it send a BYE because of timeout.
>
> Any idea of where is the problem or what am i doing wrong?? Any advice
> will be appreciated!!
>
> I attach the sip_trace log and the Opensips script of the frontend server:
>
> Caller: sip:u1iupzg...@jipubnx2ef.bell.enigmedia.eu
> Callee: d27p6ui...@jipubnx2ef.bell.enigmedia.eu
> Opensips frontend ip: internal -> 192.168.3.35, external -> 192.168.1.18
> Opensips backend ip: internal -> 192.168.2.6
>
>
>
>
>
>
> ___
> 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] Problems migrating from v2.1 to v2.2

2016-06-08 Thread John Quick 
I just wanted to report some snags I hit when migrating. Note: I had the
install prefix set to /

After running make+Install for v2.2, executable files in /usr/local/sbin
were not updated to the v2.2 versions. The new versions were *only* in /sbin
That would be okay, except that when I ran opensipsdbctl, it tried to run
the old version in /usr/local/sbin
When I deleted the old executable files in /usr/local/sbin, I got this
error:
"-bash: /usr/local/sbin/opensipsdbctl: No such file or directory"
...so I copied everything for opensips that was in /sbin to /usr/local/sbin
and that seemed to fix it.

Then I finally was able to run opensipsdbctl migrate   and I
got the following errors which I was able to skip:
ERROR: failed to migrate opensips_v21.cc_flows to opensips_v22.cc_agents
(ERROR 1054 (42S22) at line 1: Unknown column
'opensips_v21.cc_flows.agentid' in 'field list')!!!
Skip it and continue (y/n)? y
ERROR: failed to migrate opensips_v21.cc_flows to opensips_v22.cc_cdrs
(ERROR 1054 (42S22) at line 1: Unknown column 'opensips_v21.cc_flows.caller'
in 'field list')!!!

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



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

Re: [OpenSIPS-Users] Continuous "WARNING:core:timer_ticker: timer task already scheduled" messages in log

2016-06-08 Thread Rodrigo Pimenta Carvalho 

Hi Steve.


The values that you have commented is used by the "make menuconfig". That is, 
as long as these are the values chosen by the standard configuration, I believe 
that such values wouldn't be causing problems.


Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: Steve Woolley 
Enviado: quarta-feira, 8 de junho de 2016 09:12
Para: OpenSIPS users mailling list
Cc: Bogdan-Andrei Iancu; Rodrigo Pimenta Carvalho
Assunto: Re: [OpenSIPS-Users] Continuous "WARNING:core:timer_ticker: timer task 
 already scheduled" messages in log

So i made two changes to my config:

  1.  per Bogdan, changed my timer_partitions to: modparam("tm", 
"timer_partitions", 4)
  2.  I had previously used some settings found in a number of configuration 
examples in my transaction module. After a little research, I commented them 
out. Still doing some research into whether these new (default) values may 
trigger other problems.  My new config is as so (snippet):

 Transaction Module
loadmodule "tm.so"
# modparam("tm", "fr_timeout", 5)
# modparam("tm", "fr_inv_timeout", 30)
# modparam("tm", "restart_fr_on_each_reply", 0)
# modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "timer_partitions", 4)


Since making these changes and restarting, the messages have gone away.




On Jun 7, 2016, at 6:47 AM, Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:

Hello Steve,

What OpenSIPS tells you is that you the TM timer routine (which gets executed 
once per second) takes longer than 1 second (as execution). Probably you have 
retransmissions or many failure routes to be executed.
You can increase the level of parallelism in TM timer via the timer_partition 
parameter:
http://www.opensips.org/html/docs/modules/2.2.x/tm.html#id294483
Try to set it to 4.

Best regards,

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

On 07.06.2016 04:21, Steve Woolley wrote:
Running opensips on a Raspberry Pi.  At some point after starting opensips 
(sometimes immediately, sometimes after quite a bit of time), the following 
message fills the log — once a second — continuously.

...
Jun  7 01:10:41 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8258580 ms), it may 
overlap..
Jun  7 01:10:42 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8259570 ms), it may 
overlap..
Jun  7 01:10:43 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8260560 ms), it may 
overlap..
Jun  7 01:10:44 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8261560 ms), it may 
overlap..
Jun  7 01:10:45 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8262550 ms), it may 
overlap..
Jun  7 01:10:46 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8263550 ms), it may 
overlap..
Jun  7 01:10:47 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8264540 ms), it may 
overlap..
Jun  7 01:10:48 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8265530 ms), it may 
overlap..
Jun  7 01:10:49 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8266530 ms), it may 
overlap..
Jun  7 01:10:50 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8267520 ms), it may 
overlap..

root@pi1:~# opensips -V
version: opensips 2.2.0 (arm6/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, QM_MALLOC, 
DBG_MALLOC, USE_PTHREAD_MUTEX
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.
git revision: 0e1cea7
main.c compiled on 21:56:59 Jun  3 2016 with gcc 4.9.2

Anyone experiencing the same?


--
Steve Woolley
steve.wool...@me.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] Continuous "WARNING:core:timer_ticker: timer task already scheduled" messages in log

2016-06-08 Thread Rodrigo Pimenta Carvalho 
Thank you!

I will compare your configuration with mine.

Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: Steve Woolley 
Enviado: quarta-feira, 8 de junho de 2016 09:12
Para: OpenSIPS users mailling list
Cc: Bogdan-Andrei Iancu; Rodrigo Pimenta Carvalho
Assunto: Re: [OpenSIPS-Users] Continuous "WARNING:core:timer_ticker: timer task 
 already scheduled" messages in log

So i made two changes to my config:

  1.  per Bogdan, changed my timer_partitions to: modparam("tm", 
"timer_partitions", 4)
  2.  I had previously used some settings found in a number of configuration 
examples in my transaction module. After a little research, I commented them 
out. Still doing some research into whether these new (default) values may 
trigger other problems.  My new config is as so (snippet):

 Transaction Module
loadmodule "tm.so"
# modparam("tm", "fr_timeout", 5)
# modparam("tm", "fr_inv_timeout", 30)
# modparam("tm", "restart_fr_on_each_reply", 0)
# modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "timer_partitions", 4)


Since making these changes and restarting, the messages have gone away.




On Jun 7, 2016, at 6:47 AM, Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:

Hello Steve,

What OpenSIPS tells you is that you the TM timer routine (which gets executed 
once per second) takes longer than 1 second (as execution). Probably you have 
retransmissions or many failure routes to be executed.
You can increase the level of parallelism in TM timer via the timer_partition 
parameter:
http://www.opensips.org/html/docs/modules/2.2.x/tm.html#id294483
Try to set it to 4.

Best regards,

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

On 07.06.2016 04:21, Steve Woolley wrote:
Running opensips on a Raspberry Pi.  At some point after starting opensips 
(sometimes immediately, sometimes after quite a bit of time), the following 
message fills the log — once a second — continuously.

...
Jun  7 01:10:41 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8258580 ms), it may 
overlap..
Jun  7 01:10:42 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8259570 ms), it may 
overlap..
Jun  7 01:10:43 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8260560 ms), it may 
overlap..
Jun  7 01:10:44 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8261560 ms), it may 
overlap..
Jun  7 01:10:45 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8262550 ms), it may 
overlap..
Jun  7 01:10:46 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8263550 ms), it may 
overlap..
Jun  7 01:10:47 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8264540 ms), it may 
overlap..
Jun  7 01:10:48 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8265530 ms), it may 
overlap..
Jun  7 01:10:49 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8266530 ms), it may 
overlap..
Jun  7 01:10:50 pi1 /usr/local/sbin/opensips[22396]: WARNING:core:timer_ticker: 
timer task  already scheduled for 7182080 ms (now 8267520 ms), it may 
overlap..

root@pi1:~# opensips -V
version: opensips 2.2.0 (arm6/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, QM_MALLOC, 
DBG_MALLOC, USE_PTHREAD_MUTEX
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.
git revision: 0e1cea7
main.c compiled on 21:56:59 Jun  3 2016 with gcc 4.9.2

Anyone experiencing the same?


--
Steve Woolley
steve.wool...@me.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] Continuous "WARNING:core:timer_ticker: timer task already scheduled" messages in log

2016-06-08 Thread Steve Woolley 
So i made two changes to my config:
per Bogdan, changed my timer_partitions to: modparam("tm", "timer_partitions", 
4)
I had previously used some settings found in a number of configuration examples 
in my transaction module. After a little research, I commented them out. Still 
doing some research into whether these new (default) values may trigger other 
problems.  My new config is as so (snippet):
 Transaction Module
loadmodule "tm.so"
# modparam("tm", "fr_timeout", 5)
# modparam("tm", "fr_inv_timeout", 30)
# modparam("tm", "restart_fr_on_each_reply", 0)
# modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "timer_partitions", 4)


Since making these changes and restarting, the messages have gone away.




> On Jun 7, 2016, at 6:47 AM, Bogdan-Andrei Iancu  wrote:
> 
> Hello Steve,
> 
> What OpenSIPS tells you is that you the TM timer routine (which gets executed 
> once per second) takes longer than 1 second (as execution). Probably you have 
> retransmissions or many failure routes to be executed.
> You can increase the level of parallelism in TM timer via the timer_partition 
> parameter:
> http://www.opensips.org/html/docs/modules/2.2.x/tm.html#id294483 
> 
> Try to set it to 4.
> 
> Best regards,
>  Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com 
> On 07.06.2016 04:21, Steve Woolley wrote:
>> Running opensips on a Raspberry Pi.  At some point after starting opensips 
>> (sometimes immediately, sometimes after quite a bit of time), the following 
>> message fills the log — once a second — continuously.
>> 
>> ...
>> Jun  7 01:10:41 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8258580 ms), it may overlap..
>> Jun  7 01:10:42 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8259570 ms), it may overlap..
>> Jun  7 01:10:43 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8260560 ms), it may overlap..
>> Jun  7 01:10:44 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8261560 ms), it may overlap..
>> Jun  7 01:10:45 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8262550 ms), it may overlap..
>> Jun  7 01:10:46 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8263550 ms), it may overlap..
>> Jun  7 01:10:47 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8264540 ms), it may overlap..
>> Jun  7 01:10:48 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8265530 ms), it may overlap..
>> Jun  7 01:10:49 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8266530 ms), it may overlap..
>> Jun  7 01:10:50 pi1 /usr/local/sbin/opensips[22396]: 
>> WARNING:core:timer_ticker: timer task  already scheduled for 
>> 7182080 ms (now 8267520 ms), it may overlap..
>> 
>> root@pi1:~# opensips -V
>> version: opensips 2.2.0 (arm6/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, QM_MALLOC, 
>> DBG_MALLOC, USE_PTHREAD_MUTEX
>> 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.
>> git revision: 0e1cea7
>> main.c compiled on 21:56:59 Jun  3 2016 with gcc 4.9.2
>> 
>> Anyone experiencing the same?
>> 
>> 
>> --
>> Steve Woolley
>> steve.wool...@me.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] Opensips -1.11 crash with mongodb replica set .

2016-06-08 Thread Liviu Chircu 

Yes, that's how I know it works

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 08.06.2016 13:33, Sasmita Panda wrote:
Yes , I have seen this . Its running fine with 1 config 
server . But if the config server is in other machine rather than the 
opensips box , If that machine goes down mongos server wont able to do 
some query . That's why I have 3 config servers running in diff 
machines and one in the same opensips box . I think , in this case if 
any one of the config server wont become reachable then at least 
another one will be reachable at the same time .


Am I right or wrong ?

*/Thanks & Regards/*
/Sasmita Panda/
/Network Testing and Software Engineer/
/3CLogic , ph:07827611765/

On Wed, Jun 8, 2016 at 3:15 PM, Liviu Chircu > wrote:


Any way is good, since all mongos servers will connect to the same
set of config servers (just to manage shard configuration and
range distributions, they do not do any real-time per-query
traffic with the config servers).

Also keep in mind that although MongoDB recommends 3 config
servers (for 100% write consistency), the cluster may run just
fine even on 2, or even 1 single config server.

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 08.06.2016 10:25, Sasmita Panda wrote:

Hi Liviu ,

  What are you suggesting for the mongodb config server ?
Because confg server is the one who contains the metadata of the
shard cluster .

 Where should I put it ? Will I put this separately or in the
opensips box with mongos ? If I will put the config servers
separately and each mongos instance will get connected to the
same set of config server then will it be fruitful or not ?

*/Thanks & Regards/*
/Sasmita Panda/
/Network Testing and Software Engineer/
/3CLogic , ph:07827611765/



___
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 -1.11 crash with mongodb replica set .

2016-06-08 Thread Sasmita Panda 
Yes , I have seen this . Its running fine with 1 config server
. But if the config server is in other machine rather than the opensips box
, If that machine goes down mongos server wont able to do some query .
That's why I have 3 config servers running in diff machines and one in the
same opensips box . I think , in this case if any one of the config server
wont become reachable then at least another one will be reachable at the
same time .

Am I right or wrong ?

*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*

On Wed, Jun 8, 2016 at 3:15 PM, Liviu Chircu  wrote:

> Any way is good, since all mongos servers will connect to the same set of
> config servers (just to manage shard configuration and range distributions,
> they do not do any real-time per-query traffic with the config servers).
>
> Also keep in mind that although MongoDB recommends 3 config servers (for
> 100% write consistency), the cluster may run just fine even on 2, or even 1
> single config server.
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 08.06.2016 10:25, Sasmita Panda wrote:
>
> Hi Liviu ,
>
>   What are you suggesting for the mongodb config server ? Because
> confg server is the one who contains the metadata of the shard cluster .
>
>  Where should I put it ? Will I put this separately or in the opensips
> box with mongos ? If I will put the config servers separately and each
> mongos instance will get connected to the same set of config server then
> will it be fruitful or not ?
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
>
> ___
> 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 -1.11 crash with mongodb replica set .

2016-06-08 Thread Liviu Chircu 
Any way is good, since all mongos servers will connect to the same set 
of config servers (just to manage shard configuration and range 
distributions, they do not do any real-time per-query traffic with the 
config servers).


Also keep in mind that although MongoDB recommends 3 config servers (for 
100% write consistency), the cluster may run just fine even on 2, or 
even 1 single config server.


Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 08.06.2016 10:25, Sasmita Panda wrote:

Hi Liviu ,

  What are you suggesting for the mongodb config server ? Because 
confg server is the one who contains the metadata of the shard cluster .


 Where should I put it ? Will I put this separately or in the 
opensips box with mongos ? If I will put the config servers separately 
and each mongos instance will get connected to the same set of config 
server then will it be fruitful or not ?


*/Thanks & Regards/*
/Sasmita Panda/
/Network Testing and Software Engineer/
/3CLogic , ph:07827611765/


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

Re: [OpenSIPS-Users] Opensips -1.11 crash with mongodb replica set .

2016-06-08 Thread Sasmita Panda 
Hi Liviu ,

  What are you suggesting for the mongodb config server ? Because confg
server is the one who contains the metadata of the shard cluster .

 Where should I put it ? Will I put this separately or in the opensips
box with mongos ? If I will put the config servers separately and each
mongos instance will get connected to the same set of config server then
will it be fruitful or not ?

*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*

On Tue, Jun 7, 2016 at 5:05 PM, Sasmita Panda  wrote:

> Thank you so much . It will be helpful for me .
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
> On Tue, Jun 7, 2016 at 4:41 PM, Liviu Chircu  wrote:
>
>> To avoid those kind of problems, I would recommend putting one "mongos"
>> instance for each OpenSIPS machine, on the same box. This way, not only do
>> you avoid problems with the mongos machine going down, but you'll speed up
>> query times as well, making your OpenSIPS workers more responsive!
>>
>> Liviu Chircu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 07.06.2016 13:20, Sasmita Panda wrote:
>>
>> Hi Liviu ,
>>
>>  I just have one question .  I have implemented opensips with mongodb
>> shard cluster . I have one replica set with three member . I have three
>> config server for each and mongos service running .
>>
>>  What I wanted to know is , the server in which my mongos service is
>> running , If that machine is get down what will happen ?
>> I need to monitor that machine so that it wont go down ? Is this show ?
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
>> On Mon, Jun 6, 2016 at 4:41 PM, Liviu Chircu  wrote:
>>
>>> Thank you, Sasmita! Will reply here as soon as there is progress on the
>>> matter.
>>>
>>> Liviu Chircu
>>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>>
>>> On 06.06.2016 13:55, Sasmita Panda wrote:
>>>
>>> Hi ,
>>>
>>>  I have created an issue with detailed steps . Bellow is the issue ID .
>>> Let me know if the issue will get fixed .
>>>
>>>   https://github.com/OpenSIPS/opensips/issues/895
>>>
>>> Thanks
>>>
>>> *Thanks & Regards*
>>> *Sasmita Panda*
>>> *Network Testing and Software Engineer*
>>> *3CLogic , ph:07827611765*
>>>
>>> On Mon, Jun 6, 2016 at 3:32 PM, Sasmita Panda < 
>>> spa...@3clogic.com> wrote:
>>>
 Thank you so much for the information . Let me try to deploy with
 mongos server .

 I will post the detailed steps for opensips crash as soon as I will be
 free .

 *Thanks & Regards*
 *Sasmita Panda*
 *Network Testing and Software Engineer*
 *3CLogic , ph:07827611765*

 On Mon, Jun 6, 2016 at 2:14 PM, Liviu Chircu < 
 li...@opensips.org> wrote:

> Hi Sasmita!
>
> We have some plans to do some more testing on the module, including
> your "connect directly to replica set" usage case, and  also bringing it 
> up
> to date with the latest mongo driver. However, it is hard to give you an
> estimation for when this work will start.
>
> Currently, the fastest way to fix your problems is for you to set up a
> "mongos" instance, along with 3 config server instances (these are needed
> by mongos, and ensure proper write consistency), and configure
> "cachedb_mongodb" to use this new "mongos" node.
>
> A mongos instance is aware of all the replica sets (aka "shards"). In
> your case, it will initially shard the keys to your single replica set -
> thus, it will hold 100% of the data. As your data set grows, you may
> partition it over to additional replica sets, which you can configure into
> mongos without modifying anything on the OpenSIPS side. This way, failover
> within a replica set will also happen transparently, again, without
> impacting OpenSIPS at all.
>
> PS: if you have a way to 100% reproduce a crash, please open a GH
> ticket describing the steps, and we'll go from there! [1]
>
> [1]: https://github.com/OpenSIPS/opensips/issues
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 06.06.2016 11:23, Sasmita Panda wrote:
>
> Hi All ,
>
>I am using opesips-1.11 with mongodb replica set . I have 3
> members in the replica set , promary , secondary and arbitrary .
>
>   Problem 1 :  Sometime , If primay is not rechable , the
> secondary becomes primary , But opensips loss connection from mongodb . 
> Its
> wont put any data in the data base . My call goes on but their is not data
> in the mongodb database .
>
> Problme 2: If the primay machine is down then secondary
> becomes primary within some millisecond time  , but  opensips crashes
> giving bellow error
>
>   ERROR:cachedb_mongodb:mongo_con_get