[OpenSIPS-Users] Federated User Location Cluster

2019-06-26 Thread Social Boh

Hello list,

I really don't understood how this configuration work.

I would like to configure two OpenSIPs instances to share data about 
registered users but I can't because when from extension 1000 registered 
on first Opensips call extension 1001 Registered on the second OpenSIPs, 
OpenSIPs search in the MongoDB a AOR with the same IP of the first 
OpenSIPs; this because use_domain parameter of usrloc module have to be = 1


So, How have I to use this configuration? balancing DNS records for the 
same domain?


Thank you

Regards

--
---
I'm SoCIaL, MayBe


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


Re: [OpenSIPS-Users] Opensips 3.0 segfault on opensips-cli -x mi reload_routes

2019-06-26 Thread Bogdan-Andrei Iancu

Hey Kirill,

Not yet, sorry, busy day :(, but I will !!

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/26/2019 06:23 PM, Kirill Galinurov wrote:

Do you need any additional information or may be tests?

вт, 25 июн. 2019 г., 19:32 Bogdan-Andrei Iancu >:


Still, whatever syntax (with errors) you have in the cfg, the
reload should not crash :(... my offer of trying to reproduce it
with your script is still available.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 2019
   https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/25/2019 07:30 PM, Kirill Galinurov wrote:

 Bogdan I am very stupped... I am sorry... But I am found problem...
I useuac_replace_from("$avp(fU)","sip:$avp(fU)@{{anycast_ip}}");
To template my config.
And when I comment this line all became good.
I guess ... I should not use templating in routes...

вт, 25 июн. 2019 г. в 19:11, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>>:

Kirill,

Could you share (off-list, privately) your script with me to
see if I can reproduce the crash ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 2019
   https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/25/2019 07:10 PM, Kirill Galinurov wrote:

I am very sorry Bogdan. But I have no any useful information
for you. I can try to rewrite my config step by step...









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


Re: [OpenSIPS-Users] Opensips 3.0 segfault on opensips-cli -x mi reload_routes

2019-06-26 Thread Kirill Galinurov
Do you need any additional information or may be tests?

вт, 25 июн. 2019 г., 19:32 Bogdan-Andrei Iancu :

> Still, whatever syntax (with errors) you have in the cfg, the reload
> should not crash :(... my offer of trying to reproduce it with your script
> is still available.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>   https://www.opensips.org/events/Summit-2019Amsterdam/
>
> On 06/25/2019 07:30 PM, Kirill Galinurov wrote:
>
>  Bogdan I am very stupped... I am sorry... But I am found problem...
> I useuac_replace_from("$avp(fU)","sip:$avp(fU)@{{anycast_ip}}");
> To template my config.
> And when I comment this line all became good.
> I guess ... I should not use templating in routes...
>
> вт, 25 июн. 2019 г. в 19:11, Bogdan-Andrei Iancu :
>
>> Kirill,
>>
>> Could you share (off-list, privately) your script with me to see if I can
>> reproduce the crash ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>> OpenSIPS Summit 2019
>>   https://www.opensips.org/events/Summit-2019Amsterdam/
>>
>> On 06/25/2019 07:10 PM, Kirill Galinurov wrote:
>>
>> I am very sorry Bogdan. But I have no any useful information for you. I
>> can try to rewrite my config step by step...
>>
>>
>>>
>>>
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Call_control and JSON-RPC

2019-06-26 Thread Dan Pascu

On 26 Jun 2019, at 15:11, Efelin Novak wrote:

> Hi,
> 
> I'm using a Kamailio version that does not support MI interface anymore. 
> Call_control module works nice in all situations expect when it wants to kill 
> the call (credit is gone). Is the Call_control module capable of using 
> JSON-RPC instead of MI command?
> 
> When I change class ManagementInterface() so that the RPC command is not sent 
> and I only call  os.system(command to kill a call using JSON-RPC), I get a 
> Error messages like this:
> 
> kamailio[19687]: ERROR: call_control [call_control.c:839]: send_command(): 
> did timeout waiting for an answer
> 
> The call is killed but I'm afraid that such error might cause errors in 
> future (e.g.: memory leaking).
> 
> Is there any workaround?
> Is it possible the call_control ends the call in a different way than MI 
> interface?

It is possible if you modify the code yourself to do it in whatever way you 
want. The stock call-control only uses the opensips MI interface and there are 
no plans to support anything else at the moment.

> Can I use os.system hack? Can I ignore these errors or I can get rid of them 
> somehow?
> 
> Kind regards
> 
> Kamailio and Call-control are at newest version.
> 
> Efelin
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan





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


Re: [OpenSIPS-Users] Rest Client Async operation

2019-06-26 Thread Ben Newlin
Liviu,

Thanks again for the info. I think what you are saying is that the async 
operation is not launching a new process to handle the called function, but is 
performing the function in the original worker thread and only taking advantage 
of any suspend/resume or polling functionality already exposed by the 
underlying function itself.

This is very different from the way I had hoped async would work. The 
documentation does not speak to the specific implementation of async, so it was 
all assumptions on my part. But to me when you say async it means a separate 
process or thread is being created to perform the function. This would allow 
that process to block on the connect or any other aspect of the called function 
as necessary without blocking call processing, which is the desired outcome of 
any async operation.

I understand that the practicalities of the implementation in OpenSIPS may have 
required this design, but I must re-iterate that these limitations need to be 
documented very carefully as they are very important to understand when 
designing OpenSIPS scripts with async functionality and are not described 
anywhere. I could not find anywhere in the documentation that indicates that 
async operations can potentially still block the original worker thread and 
block call processing. The closest is:

“The current OpenSIPS worker will launch the asynchronous operation, after 
which it will continue to process other pending tasks”

But this provides no elaboration on what it means for the worker to “launch” 
the operation, and more importantly it does not indicate that the launching 
itself can block, which is the key issue here.

As I said, this unfortunately makes async processing mostly useless for us. For 
both DB and REST queries if only the data transfer is async then it is only 
useful when the data being transferred is extremely large or prone to 
delays/jitter. Such transfers should be avoided during realtime processing 
whether async or not, as they will still delay the individual call even if not 
others. For small payloads, like the single JSON object common in REST 
responses, it is the connection itself that is the concern. Once connected, 
running the data transfer in async mode represents no real gain.

As far as investigating why the server is not responding, of course we will 
always do this. But we cannot anticipate or fix every cause of remote system 
failure. In order to design a resilient system we cannot assume the remote 
server will always be there. We had believed async would allow call processing 
to proceed in failure cases like this without blocking.

Ben Newlin

From: Users  on behalf of Liviu Chircu 

Reply-To: OpenSIPS users mailling list 
Date: Wednesday, June 26, 2019 at 9:23 AM
To: "users@lists.opensips.org" 
Subject: Re: [OpenSIPS-Users] Rest Client Async operation


It's the same process doing both the connect and the transfer.  The problem is 
that libcurl, as it stands now,
is not able to give me a file descriptor to poll on, until it connects [1].  
See this section:

"When libcurl returns -1 in max_fd, it is because libcurl currently does 
something that isn't possible
for your application to monitor with a socket and unfortunately you can then 
not know exactly when the
current action is completed using select(). You then need to wait a while 
before you proceed and call
curl_multi_perform anyway. How long to wait? Unless curl_multi_timeout gives 
you a lower number, we
suggest 100 milliseconds or so, but you may want to test it out in your own 
particular conditions to
find a suitable value."

Regarding your issue: I would investigate further the reason why the connect is 
hanging, and not getting
rejected immediately when your server is down.  That would solve all your 
blocking issues.

The same with MySQL connections which go down: only after the connection is up 
are we able to obtain
its file descriptor to asynchronously poll on.  So if connect to DB_HOST:3306 
hangs, so will OpenSIPS.

Regards,

[1]: 
https://curl.haxx.se/libcurl/c/curl_multi_fdset.html

Liviu Chircu

OpenSIPS Developer

http://www.opensips-solutions.com
On 25.06.2019 18:41, Ben Newlin wrote:
but I guess my question would be why isn’t the entire operation run in async? 
Why must the connect be performed in the current process and only the transfer 
be in another process?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] I need some help in websocket connection error .

2019-06-26 Thread Răzvan Crainea
TBH, all I can see in the logs you sent is that a connection was 
terminated (without even being started), and a connection that was 
started, but closed by the client. So in order to understand what's 
happening, you need to understand why the client is closing the 
connection. Check logs, documentation, anything, but this doesn't seem 
to be related to OpenSIPS, it looks like some SSL misconfiguration.


Best regards,
Răzvan

On 6/26/19 4:24 PM, Sasmita Panda wrote:
Is there any update on this issue . How I can solve this error message 
from my opensips logs .



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


On Tue, Jun 25, 2019 at 3:48 PM Sasmita Panda > wrote:


I have tried to take ssldump in the webrtc server in run time .

New TCP connection #19: 192.168.1.y(48530) <-> 192.168.0.x(443)
19    0.0011 (0.0011)  C>S  TCP FIN
19    0.0013 (0.0001)  S>C  TCP FIN

New TCP connection #20: 192.168.0.y(52975) <-> 192.168.0.x(443)
20 1  0.0006 (0.0006)  C>S  Handshake      ClientHello
20 2  0.0008 (0.0002)  S>C  Handshake      ServerHello
20 3  0.0008 (0.)  S>C  Handshake      Certificate
20 4  0.0008 (0.)  S>C  Handshake      ServerHelloDone
20 5  0.0020 (0.0011)  C>S  Handshake      ClientKeyExchange
20 6  0.0020 (0.)  C>S  ChangeCipherSpec
20 7  0.0020 (0.)  C>S  Handshake
20 8  0.0036 (0.0015)  S>C  Handshake20 9  0.0036 (0.)  S>C
  ChangeCipherSpec
20 10 0.0036 (0.)  S>C  Handshake
20 11 0.0042 (0.0006)  C>S  Alert
20    0.0042 (0.)  C>S  TCP FIN
20    0.0043 (0.)  S>C  TCP FIN

The portion I marked in red whenever appear there is error in
opensips logs  . For below portion the connection was accepted  .

I am not even getting any error  in my browser side .  How I will
debug this ? please help .

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


On Fri, Jun 14, 2019 at 2:51 PM Callum Guy mailto:callum@x-on.co.uk>> wrote:

You might find that a tcpdump is the only way to get to grips
with the underlying issue.

Having said that I wonder if there is any chance that the
connection isn't accepting simply due to a cipher
incompatibility. Are you setting a cipher list that you know
your clients accept? Maybe try:

modparam("tls_mgm", "ciphers_list",

"AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,CAMELLIA128-SHA,RC4-SHA")


On Fri, 14 Jun 2019 at 09:17, Sasmita Panda mailto:spa...@3clogic.com>> wrote:

I had a dedicated server for 1 Client . When that client
faces the issue I started looking into the logs . And this
is what the error I got .

but latter on when I saw other servers which is getting used
by different client in that logs also same error coming
everyday .

As a conclusion its happening with everybody .

Below is the configuration .

modparam("tls_mgm", "tls_method", "tlsv1_2")
modparam("tls_mgm", "verify_cert", "0")
modparam("tls_mgm", "require_cert", "0")
modparam("tls_mgm", "certificate",
"/usr/etc/opensips/tls/3ccloudwebrtc2019.crt")
modparam("tls_mgm", "private_key",
"/usr/etc/opensips/tls/3ccloud.key")
modparam("tls_mgm", "ca_list",
"/usr/etc/opensips/tls/rootCA/cacert.pem")



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


On Thu, Jun 13, 2019 at 6:50 PM Răzvan Crainea
mailto:raz...@opensips.org>> wrote:

Can you trace the SSL traffic between the two endpoints?
Perhaps the SSL
header give you a reason for not accepting the connection.
Is this happening only for certain clients, or for everyone?
Are you requiring any certificates validation?

Best regards,
Răzvan

On 6/12/19 3:34 PM, Sasmita Panda wrote:
 > I am using opensips 2.2
 >   version: opensips 2.2.4 (x86_64/linux)
 >
 > I am using the proto_wss and tls_mgm module for
establishing websocket
 > connection .
 >
 > I am getting bellow error again and again . Whats the
reson behind this
 > and how can I solve this problem ?
 >
 >
 > Jun 10 00:00:15 localhost /usr/sbin/opensips[1548]:
 > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
 > Jun 

Re: [OpenSIPS-Users] Call_control and JSON-RPC

2019-06-26 Thread Bogdan-Andrei Iancu

Hey Efelin,

I cannot make statements in regards to the Call-Control project as I'm 
not involved. I CC'ed here Dan, he may be able to bring some light.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/26/2019 04:34 PM, Efelin Novak wrote:

Hi,

@Johan: Call-control webpage says to post questions/bugs here. 
http://callcontrol.ag-projects.com/contact/
@Bogdan: That is not an answer I was looking for but I understand :) 
So the call-control project only works with OpenSIPS now?


Thanks.

Efelin

st 26. 6. 2019 o 15:07 Bogdan-Andrei Iancu > napísal(a):


Just use OpenSIPS and you will be fine :)

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 2019
   https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/26/2019 03:11 PM, Efelin Novak wrote:

Hi,

I'm using a Kamailio version that does not support MI interface
anymore. Call_control module works nice in all situations expect
when it wants to kill the call (credit is gone). Is the
Call_control module capable of using JSON-RPC instead of MI command?

When I change class ManagementInterface() so that the RPC command
is not sent and I only call os.system(command to kill a call
using JSON-RPC), I get a Error messages like this:

kamailio[19687]: ERROR: call_control [call_control.c:839]:
send_command(): did timeout waiting for an answer

The call is killed but I'm afraid that such error might cause
errors in future (e.g.: memory leaking).

Is there any workaround?
Is it possible the call_control ends the call in a different way
than MI interface?
Can I use os.system hack? Can I ignore these errors or I can get
rid of them somehow?

Kind regards

Kamailio and Call-control are at newest version.

Efelin


___
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] Rest Client Async operation

2019-06-26 Thread Liviu Chircu

That is exactly why we need to extract the connection/transfer fd in the
first place: so we can throw it into epoll_wait() and have it act as
an event generator :)

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

On 26.06.2019 16:38, SamyGo wrote:

once we somehow get the event from libcurl


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


Re: [OpenSIPS-Users] Rest Client Async operation

2019-06-26 Thread SamyGo
Hi Liviu,

Is it possible to suspend the transaction and resume it once we somehow get
the event from libcurl as soon as the connect is done?
Im imagining the way usually APNS is done these days. The only thing
missing here is the event from the rest_client !

Can this mechanism help with the problem of backlog on the opensips thread
?

Best Regards,
Sammy


On Wed., Jun. 26, 2019, 9:23 a.m. Liviu Chircu,  wrote:

> It's the same process doing both the connect and the transfer.  The
> problem is that libcurl, as it stands now,
> is not able to give me a file descriptor to poll on, until it connects
> [1].  See this section:
>
> "When libcurl returns -1 in max_fd, it is because libcurl currently does
> something that isn't possible
> for your application to monitor with a socket and unfortunately you can
> then not know exactly when the
> current action is completed using select(). You then need to wait a while
> before you proceed and call
> curl_multi_perform anyway. How long to wait? Unless curl_multi_timeout
> gives you a lower number, we
> suggest 100 milliseconds or so, but you may want to test it out in your
> own particular conditions to
> find a suitable value."
>
> Regarding your issue: I would investigate further the reason why the
> connect is hanging, and not getting
> rejected immediately when your server is down.  That would solve all your
> blocking issues.
>
> The same with MySQL connections which go down: only after the connection
> is up are we able to obtain
> its file descriptor to asynchronously poll on.  So if connect to
> DB_HOST:3306 hangs, so will OpenSIPS.
>
> Regards,
>
> [1]: https://curl.haxx.se/libcurl/c/curl_multi_fdset.html
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 25.06.2019 18:41, Ben Newlin wrote:
>
> but I guess my question would be why isn’t the entire operation run in
> async? Why must the connect be performed in the current process and only
> the transfer be in another process?
>
> ___
> 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] Call_control and JSON-RPC

2019-06-26 Thread Efelin Novak
Hi,

@Johan: Call-control webpage says to post questions/bugs here.
http://callcontrol.ag-projects.com/contact/
@Bogdan: That is not an answer I was looking for but I understand :) So the
call-control project only works with OpenSIPS now?

Thanks.

Efelin

st 26. 6. 2019 o 15:07 Bogdan-Andrei Iancu  napísal(a):

> Just use OpenSIPS and you will be fine :)
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>   https://www.opensips.org/events/Summit-2019Amsterdam/
>
> On 06/26/2019 03:11 PM, Efelin Novak wrote:
>
> Hi,
>
> I'm using a Kamailio version that does not support MI interface anymore.
> Call_control module works nice in all situations expect when it wants to
> kill the call (credit is gone). Is the Call_control module capable of using
> JSON-RPC instead of MI command?
>
> When I change class ManagementInterface() so that the RPC command is not
> sent and I only call  os.system(command to kill a call using JSON-RPC), I
> get a Error messages like this:
>
> kamailio[19687]: ERROR: call_control [call_control.c:839]: send_command():
> did timeout waiting for an answer
>
> The call is killed but I'm afraid that such error might cause errors in
> future (e.g.: memory leaking).
>
> Is there any workaround?
> Is it possible the call_control ends the call in a different way than MI
> interface?
> Can I use os.system hack? Can I ignore these errors or I can get rid of
> them somehow?
>
> Kind regards
>
> Kamailio and Call-control are at newest version.
>
> Efelin
>
>
> ___
> 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


Re: [OpenSIPS-Users] I need some help in websocket connection error .

2019-06-26 Thread Sasmita Panda
Is there any update on this issue . How I can solve this error message from
my opensips logs .


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


On Tue, Jun 25, 2019 at 3:48 PM Sasmita Panda  wrote:

> I have tried to take ssldump in the webrtc server in run time .
>
> New TCP connection #19: 192.168.1.y(48530) <-> 192.168.0.x(443)
> 190.0011 (0.0011)  C>S  TCP FIN
> 190.0013 (0.0001)  S>C  TCP FIN
>
> New TCP connection #20: 192.168.0.y(52975) <-> 192.168.0.x(443)
> 20 1  0.0006 (0.0006)  C>S  Handshake  ClientHello
> 20 2  0.0008 (0.0002)  S>C  Handshake  ServerHello
> 20 3  0.0008 (0.)  S>C  Handshake  Certificate
> 20 4  0.0008 (0.)  S>C  Handshake  ServerHelloDone
> 20 5  0.0020 (0.0011)  C>S  Handshake  ClientKeyExchange
> 20 6  0.0020 (0.)  C>S  ChangeCipherSpec
> 20 7  0.0020 (0.)  C>S  Handshake
> 20 8  0.0036 (0.0015)  S>C  Handshake20 9  0.0036 (0.)  S>C
>  ChangeCipherSpec
> 20 10 0.0036 (0.)  S>C  Handshake
> 20 11 0.0042 (0.0006)  C>S  Alert
> 200.0042 (0.)  C>S  TCP FIN
> 200.0043 (0.)  S>C  TCP FIN
>
> The portion I marked in red whenever appear there is error in opensips
> logs  . For below portion the connection was accepted  .
>
> I am not even getting any error  in my browser side .  How I will debug
> this ? please help .
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Fri, Jun 14, 2019 at 2:51 PM Callum Guy  wrote:
>
>> You might find that a tcpdump is the only way to get to grips with the
>> underlying issue.
>>
>> Having said that I wonder if there is any chance that the connection
>> isn't accepting simply due to a cipher incompatibility. Are you setting a
>> cipher list that you know your clients accept? Maybe try:
>>
>> modparam("tls_mgm", "ciphers_list",
>> "AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,CAMELLIA128-SHA,RC4-SHA")
>>
>>
>> On Fri, 14 Jun 2019 at 09:17, Sasmita Panda  wrote:
>>
>>> I had a dedicated server for 1 Client . When that client faces the issue
>>> I started looking into the logs . And this is what the error I got .
>>>
>>> but latter on when I saw other servers which is getting used by
>>> different client in that logs also same error coming everyday .
>>>
>>> As a conclusion its happening with everybody .
>>>
>>> Below is the configuration .
>>>
>>> modparam("tls_mgm", "tls_method", "tlsv1_2")
>>> modparam("tls_mgm", "verify_cert", "0")
>>> modparam("tls_mgm", "require_cert", "0")
>>> modparam("tls_mgm", "certificate",
>>> "/usr/etc/opensips/tls/3ccloudwebrtc2019.crt")
>>> modparam("tls_mgm", "private_key", "/usr/etc/opensips/tls/3ccloud.key")
>>> modparam("tls_mgm", "ca_list", "/usr/etc/opensips/tls/rootCA/cacert.pem")
>>>
>>>
>>>
>>> *Thanks & Regards*
>>> *Sasmita Panda*
>>> *Senior Network Testing and Software Engineer*
>>> *3CLogic , ph:07827611765*
>>>
>>>
>>> On Thu, Jun 13, 2019 at 6:50 PM Răzvan Crainea 
>>> wrote:
>>>
 Can you trace the SSL traffic between the two endpoints? Perhaps the
 SSL
 header give you a reason for not accepting the connection.
 Is this happening only for certain clients, or for everyone?
 Are you requiring any certificates validation?

 Best regards,
 Răzvan

 On 6/12/19 3:34 PM, Sasmita Panda wrote:
 > I am using opensips 2.2
 >   version: opensips 2.2.4 (x86_64/linux)
 >
 > I am using the proto_wss and tls_mgm module for establishing
 websocket
 > connection .
 >
 > I am getting bellow error again and again . Whats the reson behind
 this
 > and how can I solve this problem ?
 >
 >
 > Jun 10 00:00:15 localhost /usr/sbin/opensips[1548]:
 > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
 > Jun 10 00:00:15 localhost /usr/sbin/opensips[1548]:
 > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 96
 > Jun 10 00:00:15 localhost /usr/sbin/opensips[1546]:
 > ERROR:proto_wss:tls_accept: New TLS connection from
 192.168.160.6:58616
 >  failed to accept
 > Jun 10 00:00:15 localhost /usr/sbin/opensips[1546]:
 > ERROR:proto_wss:wss_read_req: cannot fix read connection
 > Jun 10 00:00:17 localhost /usr/sbin/opensips[1548]:
 > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
 > Jun 10 00:00:17 localhost /usr/sbin/opensips[1548]:
 > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 96
 > Jun 10 00:00:17 localhost /usr/sbin/opensips[1546]:
 > ERROR:proto_wss:tls_accept: New TLS connection from
 192.168.175.59:12918
 >  failed to accept
 > Jun 10 00:00:17 localhost /usr/sbin/opensips[1546]:
 > ERROR:proto_wss:wss_read_req: cannot fix read connection
 >
 >
 > Please do help .
 >
 >
 >
 > */Thanks & Regards/*
 

Re: [OpenSIPS-Users] Rest Client Async operation

2019-06-26 Thread Liviu Chircu
It's the same process doing both the connect and the transfer.  The 
problem is that libcurl, as it stands now,
is not able to give me a file descriptor to poll on, until it connects 
[1].  See this section:


"When libcurl returns -1 in max_fd, it is because libcurl currently does 
something that isn't possible
for your application to monitor with a socket and unfortunately you can 
then not know exactly when the
current action is completed using select(). You then need to wait a 
while before you proceed and call
curl_multi_perform anyway. How long to wait? Unless curl_multi_timeout 
gives you a lower number, we
suggest 100 milliseconds or so, but you may want to test it out in your 
own particular conditions to

find a suitable value."

Regarding your issue: I would investigate further the reason why the 
connect is hanging, and not getting
rejected immediately when your server is down.  That would solve all 
your blocking issues.


The same with MySQL connections which go down: only after the connection 
is up are we able to obtain
its file descriptor to asynchronously poll on.  So if connect to 
DB_HOST:3306 hangs, so will OpenSIPS.


Regards,

[1]: https://curl.haxx.se/libcurl/c/curl_multi_fdset.html

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

On 25.06.2019 18:41, Ben Newlin wrote:
but I guess my question would be why isn’t the entire operation run in 
async? Why must the connect be performed in the current process and 
only the transfer be in another process?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Number of Children's vs number of cores

2019-06-26 Thread Bogdan-Andrei Iancu

Hi Alain,

Monitor the internal load of OpenSIPS (via load: class statistics) and 
see if you really need to add more processes. If you your processing is 
mostly CPU intensive (no DB, no DNS or other I/Os) and you want to take 
full advantage of all your CPU resources (if you need them) maybe a x1.5 
or x2 factor (between cores and procs) will do it.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/26/2019 10:18 AM, Alain Bieuzent wrote:


Hi all,

I’m using an opensips 2.4 with only dispatcher module.

This server handle around 800 CPAS for 16 000 simultaneous calls.

We run it under VMWARE/Debian with 4 cores and 8 children’s and we 
have a pic of CPU load to 0,8.


I will upgrade this VM to six cores, but what about number of 
children’s, do you have a rules to determine the number of children or 
there is  no link with number of core ?


Thanks

Alain



___
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] Call_control and JSON-RPC

2019-06-26 Thread Bogdan-Andrei Iancu

Just use OpenSIPS and you will be fine :)

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 06/26/2019 03:11 PM, Efelin Novak wrote:

Hi,

I'm using a Kamailio version that does not support MI interface 
anymore. Call_control module works nice in all situations expect when 
it wants to kill the call (credit is gone). Is the Call_control module 
capable of using JSON-RPC instead of MI command?


When I change class ManagementInterface() so that the RPC command is 
not sent and I only call  os.system(command to kill a call using 
JSON-RPC), I get a Error messages like this:


kamailio[19687]: ERROR: call_control [call_control.c:839]: 
send_command(): did timeout waiting for an answer


The call is killed but I'm afraid that such error might cause errors 
in future (e.g.: memory leaking).


Is there any workaround?
Is it possible the call_control ends the call in a different way than 
MI interface?
Can I use os.system hack? Can I ignore these errors or I can get rid 
of them somehow?


Kind regards

Kamailio and Call-control are at newest version.

Efelin


___
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] Call_control and JSON-RPC

2019-06-26 Thread Johan De Clercq
I think that you posted on the wrong list

On Wed, 26 Jun 2019, 14:14 Efelin Novak,  wrote:

> Hi,
>
> I'm using a Kamailio version that does not support MI interface anymore.
> Call_control module works nice in all situations expect when it wants to
> kill the call (credit is gone). Is the Call_control module capable of using
> JSON-RPC instead of MI command?
>
> When I change class ManagementInterface() so that the RPC command is not
> sent and I only call  os.system(command to kill a call using JSON-RPC), I
> get a Error messages like this:
>
> kamailio[19687]: ERROR: call_control [call_control.c:839]: send_command():
> did timeout waiting for an answer
>
> The call is killed but I'm afraid that such error might cause errors in
> future (e.g.: memory leaking).
>
> Is there any workaround?
> Is it possible the call_control ends the call in a different way than MI
> interface?
> Can I use os.system hack? Can I ignore these errors or I can get rid of
> them somehow?
>
> Kind regards
>
> Kamailio and Call-control are at newest version.
>
> Efelin
> ___
> 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] Call_control and JSON-RPC

2019-06-26 Thread Efelin Novak
Hi,

I'm using a Kamailio version that does not support MI interface anymore.
Call_control module works nice in all situations expect when it wants to
kill the call (credit is gone). Is the Call_control module capable of using
JSON-RPC instead of MI command?

When I change class ManagementInterface() so that the RPC command is not
sent and I only call  os.system(command to kill a call using JSON-RPC), I
get a Error messages like this:

kamailio[19687]: ERROR: call_control [call_control.c:839]: send_command():
did timeout waiting for an answer

The call is killed but I'm afraid that such error might cause errors in
future (e.g.: memory leaking).

Is there any workaround?
Is it possible the call_control ends the call in a different way than MI
interface?
Can I use os.system hack? Can I ignore these errors or I can get rid of
them somehow?

Kind regards

Kamailio and Call-control are at newest version.

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


[OpenSIPS-Users] Number of Children's vs number of cores

2019-06-26 Thread Alain Bieuzent
Hi all,

 

I’m using an opensips 2.4 with only dispatcher module.

This server handle around 800 CPAS for 16 000 simultaneous calls.

 

We run it under VMWARE/Debian with 4 cores and 8 children’s and we have a pic 
of CPU load to 0,8.

 

I will upgrade this VM to six cores, but what about number of children’s, do 
you have a rules to determine the number of children or there is  no link with 
number of core ?

 

Thanks

 

Alain

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