Re: [OpenSIPS-Users] Opensips-cp 8.3.0 HTTP/1.1 400 Bad Request..

[Mario San Vicente]

  Thanks for the answer Johan,

But i see that; the *mi_json* module has been renamed to *mi_http* module.
and so:  failed to load module mi_json.so
 https://www.opensips.org/Documentation/Migration-2-4-0-to-3-0-0

I am using opensips 3.1

I have this modules:

loadmodule "httpd.so"
modparam("httpd", "port", )
 MI_HTTP module
loadmodule "json.so"
#loadmodule "mi_json.so"
loadmodule "mi_http.so"

Any other clue?

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

Re: [OpenSIPS-Users] Opensips-cp 8.3.0 HTTP/1.1 400 Bad Request..

[Johan De Clercq]

You need to use mi_json

Outlook voor iOS downloaden

Van: Users  namens Mario San Vicente 

Verzonden: Wednesday, October 28, 2020 8:06:09 PM
Aan: OpenSIPS users mailling list 
Onderwerp: [OpenSIPS-Users] Opensips-cp 8.3.0 HTTP/1.1 400 Bad Request..

Hello Everyone,

Here i have a quick question.

I installed opensips-cp 8.3.0 in a Centos installation from sources version: 
opensips 3.1.

I seems to me that  the configuration is fine, mysql DB, and users.

But Opensips-cp can't speak MI to opensips.

I get the following at trace level:

T 127.0.0.1:34550 -> 
127.0.0.1: [AP] #144
  POST /json HTTP/1.1..Host: 127.0.0.1:..Accept: */*..Content-Type: 
application/json..Content-Length: 
78{"jsonrpc":"2.0","id":1,"method":"dlg_lis
  t","params":{"index":0,"counter":20}}w.._
#
T 127.0.0.1: -> 
127.0.0.1:34550 [A] #145
  8...w.._XZ..
#
T 127.0.0.1: -> 
127.0.0.1:34550 [AP] #146
  HTTP/1.1 400 Bad Request..Content-Length: 46..Content-Type: text/html..Date: 
Wed, 28 Oct 2020 18:59:03 GMTUnable to parse URL!w.._C...
#

And at php level iget:

 [:error] [pid 17689] [client x.x.x.x:55303] PHP Warning:  Creating default 
object from empty value in 
/var/www/html/opensips-cp/config/tools/system/dialog/local.inc.php on line 27, 
referer: http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh
 [:error] [pid 17689] [client x.x.x.x:55303] PHP Notice:  Use of undefined 
constant CURLINFO_RESPONSE_CODE - assumed 'CURLINFO_RESPONSE_CODE' in 
/var/www/html/opensips-cp/web/common/mi_comm.php on line 50, referer: 
http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh
[:error] [pid 17689] [client x.x.x.x:55303] PHP Warning:  curl_getinfo() 
expects parameter 2 to be long, string given in 
/var/www/html/opensips-cp/web/common/mi_comm.php on line 50, referer: 
http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh
[:error] [pid 17689] [client x.x.x.x:55303] PHP Warning:  array_key_exists() 
expects parameter 2 to be array, null given in 
/var/www/html/opensips-cp/web/common/mi_comm.php on line 61, referer: 
http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh

 php -v
PHP 7.3.24 (cli)


Anyone have any idea why it fails??

Thank you very much
--
Mario SV
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips-cp 8.3.0 HTTP/1.1 400 Bad Request..

[Mario San Vicente]

Hello Everyone,

Here i have a quick question.

I installed opensips-cp 8.3.0 in a Centos installation from
sources version: opensips 3.1.

I seems to me that  the configuration is fine, mysql DB, and users.

But Opensips-cp can't speak MI to opensips.

I get the following at trace level:

T 127.0.0.1:34550 -> 127.0.0.1: [AP] #144
  POST /json HTTP/1.1..Host: 127.0.0.1:..Accept: */*..Content-Type:
application/json..Content-Length:
78{"jsonrpc":"2.0","id":1,"method":"dlg_lis
  t","params":{"index":0,"counter":20}}w.._
#
T 127.0.0.1: -> 127.0.0.1:34550 [A] #145
  8...w.._XZ..
#
T 127.0.0.1: -> 127.0.0.1:34550 [AP] #146
  HTTP/1.1 400 Bad Request..Content-Length: 46..Content-Type:
text/html..Date: Wed, 28 Oct 2020 18:59:03 GMTUnable to
parse URL!w.._C...
#

And at php level iget:

 [:error] [pid 17689] [client x.x.x.x:55303] PHP Warning:  Creating default
object from empty value in
/var/www/html/opensips-cp/config/tools/system/dialog/local.inc.php on line
27, referer: http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh
 [:error] [pid 17689] [client x.x.x.x:55303] PHP Notice:  Use of undefined
constant CURLINFO_RESPONSE_CODE - assumed 'CURLINFO_RESPONSE_CODE' in
/var/www/html/opensips-cp/web/common/mi_comm.php on line 50, referer:
http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh
[:error] [pid 17689] [client x.x.x.x:55303] PHP Warning:  curl_getinfo()
expects parameter 2 to be long, string given in
/var/www/html/opensips-cp/web/common/mi_comm.php on line 50, referer:
http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh
[:error] [pid 17689] [client x.x.x.x:55303] PHP Warning:
 array_key_exists() expects parameter 2 to be array, null given in
/var/www/html/opensips-cp/web/common/mi_comm.php on line 61, referer:
http://x.x.x.x/cp/tools/system/dialog/dialog.php?action=refresh

 php -v
PHP 7.3.24 (cli)


Anyone have any idea why it fails??

Thank you very much
-- 
Mario SV
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Liviu,

It looks like the fixed/update contact is lost only when topology_hiding()
is involved.  Would you prefer a separate issue, or shall I append the
issue you referenced before?


- Jeff


On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle  wrote:

> Hey Liviu,
>
> fix_nated_contact() before topology_hiding().  Got it.  As far as losing
> the fixed contact during a serial fork, I'll do more testing to localize
> exactly which combination of circumstances causes this to surface and open
> a bug report.
>
>
> - Jeff
>
>
> On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  wrote:
>
>> Hi!
>>
>> On 28.10.2020 18:49, Jeff Pyle wrote:
>>
>> First, I lose the updated Contact from fix_nated_contact() after a
>> serial fork.  Is this expected?
>>
>> I would assume the `fix_nated_contact()` lump changes get backed up into
>> shared memory, then made available during the failure_route.  Anything else
>> and IMHO it looks like a bug.  Opinions welcome.
>>
>>
>> Second, I've determined that if the Contact URI is not wrapped in <>,
>> that's when I get the "second attempt to change URI Contact" error when
>> running fix_nated_contact() in the branch_route[].  This feels like a
>> bug.
>>
>> This one is a known, documented issue.  Long story short: you should
>> always call fix_nated_contact() _before_ topology_hiding().  See this truth
>> table for more info [1].
>>
>> [1]: https://github.com/OpenSIPS/opensips/issues/2172
>>
>> --
>> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Hey Liviu,

fix_nated_contact() before topology_hiding().  Got it.  As far as losing
the fixed contact during a serial fork, I'll do more testing to localize
exactly which combination of circumstances causes this to surface and open
a bug report.


- Jeff


On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  wrote:

> Hi!
>
> On 28.10.2020 18:49, Jeff Pyle wrote:
>
> First, I lose the updated Contact from fix_nated_contact() after a serial
> fork.  Is this expected?
>
> I would assume the `fix_nated_contact()` lump changes get backed up into
> shared memory, then made available during the failure_route.  Anything else
> and IMHO it looks like a bug.  Opinions welcome.
>
>
> Second, I've determined that if the Contact URI is not wrapped in <>,
> that's when I get the "second attempt to change URI Contact" error when
> running fix_nated_contact() in the branch_route[].  This feels like a bug.
>
> This one is a known, documented issue.  Long story short: you should
> always call fix_nated_contact() _before_ topology_hiding().  See this truth
> table for more info [1].
>
> [1]: https://github.com/OpenSIPS/opensips/issues/2172
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Liviu Chircu]

Hi!

On 28.10.2020 18:49, Jeff Pyle wrote:
First, I lose the updated Contact from fix_nated_contact() after a 
serial fork.  Is this expected?
I would assume the `fix_nated_contact()` lump changes get backed up into 
shared memory, then made available during the failure_route. Anything 
else and IMHO it looks like a bug.  Opinions welcome.


Second, I've determined that if the Contact URI is not wrapped in <>, 
that's when I get the "second attempt to change URI Contact" error 
when running fix_nated_contact() in the branch_route[]. This feels 
like a bug.


This one is a known, documented issue.  Long story short: you should 
always call fix_nated_contact() _before_ topology_hiding().  See this 
truth table for more info [1].


[1]: https://github.com/OpenSIPS/opensips/issues/2172

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

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

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

It looks like I'm fighting two separate issues.  Here's what I know so far.

First, I lose the updated Contact from fix_nated_contact() after a serial
fork.  Is this expected?

Second, I've determined that if the Contact URI is not wrapped in <>,
that's when I get the "second attempt to change URI Contact" error when
running fix_nated_contact() in the branch_route[].  This feels like a bug.


- Jeff




- Jeff


On Tue, Oct 27, 2020 at 8:31 PM Jeff Pyle  wrote:

> Hello,
>
> This is on OpenSIPS 2.4.8.  Early in the script:
>
> if (nat_uac_test("34")) {   # 2, 32
> setflag(NAT_FLAG);
> fix_nated_contact();
> force_rport();
> }
>
> Later in the script I run topology_hiding("CD"), and then t_relay() an
> inbound initial INVITE upstream to another system that returns a 302 with
> Contacts.  I handle that in a failure_route[] by serializing the branches
> and relaying to them one at a time.  I don't have to go around this
> t_relay() -> failure_route[] loop much because the first Contact usually
> handles the request.
>
> The problem I notice is that the updated Contact from fix_nated_contact()
> early in the script is lost after I do the initial t_relay() to the
> redirector to get the 302.  To work around that, I've modified the script
> above to not fix_nated_contact() there, but do it in the branch_route[]
> relaying to the first Contact from the 302 and then only if NAT_FLAG is
> set.  That seems to be fine in most cases.
>
> I one case from one phone system where OpenSIPS complains:
>   ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to
> change URI Contact
>
> This happens when I run fix_nated_contact() in the branch_route[] for the
> first and only time.  I can't duplicate it with my own traffic in the lab
> and it's maddening; it only happens with this one system that's not mine to
> play with.  I've captured the messaging and don't see anything different in
> the INVITEs coming into OpenSIPS, just some cosmetic stuff like one system
> includes :5060 on the From domain and one doesn't.  Nothing that should
> affect OpenSIPS' behavior in any of this.  It'll be very difficult to get a
> full OpenSIPS debug in this case because it's on a production system but
> there's got to be *something*.  Anyway...
>
> So, it appears I have some strange interaction between fix_nated_contact(),
> topology_hiding() and serial forking.  I mention topology_hiding()
> because it's the only thing I can think of in my scenario that would update
> the Contact outside of fix_nated_contact().
>
> I'm stumped.  Any thoughts?
>
>
> - Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] rtpengine_delete not returning immediately

[John Quick]

Alain,
Thanks. This confirms that it is a local issue in my test lab setup and not a 
generic issue for all users of rtpengine.
I thought it was unlikely this problem would be widespread and yet not be 
reported before.
Probably it concerns using an under-powered VPS to host rtpengine, or maybe it 
is latency in transmission of large packets over the internet.
I will do some more testing to find out. Thank you everyone who answered.

John Quick
Smartvox Limited



> -Original Message-
> From: Alain Bieuzent  
> Sent: 28 October 2020 14:21
> To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list 
> ; 'Johan De Clercq' 
> Subject: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately
>
> Hey John,
>
> I just take a trace with timestamp to see what is the delay in our side 
> (rtpengine with around 2000 calls engaged)
>
> U 2020/10/28 15:13:51.034476 10.207.201.39:58640 -> 10.207.201.164:2223
>   25135_9 
> d7:call-id53:284c8c0174d1778d0f09b16e7596a...@xxx.xxx.xxx.xxx:506013:received-froml3:IP415:XXX.XXX.XXX.XXXe8:from-tag10:as0bf5d73f7:command6:delete
>
>
> U 2020/10/28 15:13:51.034870 10.207.201.164:2223 -> 10.207.201.39:58640
>
> Sor for me the "ACK" of the delete come less than 1 ms after so no issue I'm 
> using Version: 7.5.5.1+0~mr7.5.5.1 on Debian 9
>
> Regards 
>
> Le 28/10/2020 15:05, « Users au nom de John Quick » 
 a écrit :


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

Re: [OpenSIPS-Users] rtpengine_delete not returning immediately

[Alain Bieuzent]

Hey John,

I just take a trace with timestamp to see what is the delay in our side 
(rtpengine with around 2000 calls engaged)

U 2020/10/28 15:13:51.034476 10.207.201.39:58640 -> 10.207.201.164:2223
  25135_9 
d7:call-id53:284c8c0174d1778d0f09b16e7596a...@xxx.xxx.xxx.xxx:506013:received-froml3:IP415:XXX.XXX.XXX.XXXe8:from-tag10:as0bf5d73f7:command6:delete
   
#
U 2020/10/28 15:13:51.034870 10.207.201.164:2223 -> 10.207.201.39:58640
  25135_9 d7:createdi1603894422e10:created_usi477622e11:last 
signali1603894425e4:SSRCd10:1694676128d11:average MOSd3:MOSi44e15:round-trip 
timei987e6:jitteri0e11:packet loss
  i0e7:samplesi1ee10:lowest MOSd3:MOSi44e15:round-trip 
timei987e6:jitteri0e11:packet lossi0e11:reported ati1603894430ee11:highest 
MOSd3:MOSi44e15:round-trip timei987e6:jitt
  eri0e11:packet lossi0e11:reported ati1603894430ee15:MOS 
progressiond8:intervali0e7:entriesld3:MOSi44e15:round-trip 
timei987e6:jitteri0e11:packet lossi0e11:reported ati160
  
3894430e10:1786750306de6:848656de9:379484757dee4:tagsd10:as0bf5d73fd3:tag10:as0bf5d73f7:createdi1603894422e16:in
 dialogue with8:99f0967f6:mediasld5:indexi1e4:type5:au
  dio8:protocol7:RTP/AVP7:streamsld10:local 
porti11200e8:endpointd6:family4:IPv47:address15:XXX.XXX.XXX.XXX4:porti10518ee19:advertised
 endpointd6:family4:IPv47:address15:18
  5.101.180.2494:porti10518ee11:last 
packeti1603894430e5:flagsl3:RTP6:filled9:confirmed10:kernelizede4:SSRCi1786750306e5:statsd7:packetsi194e5:bytesi33368e6:errorsi0eeed10:
  local 
porti11201e8:endpointd6:family4:IPv47:address15:XXX.XXX.XXX.XXX4:porti10519ee19:advertised
 endpointd6:family4:IPv47:address15:XXX.XXX.XXX.XXX4:porti10519ee11:last p
  
acketi1603894430e5:flagsl4:RTCP6:filled9:confirmede4:SSRCi1694676128e5:statsd7:packetsi1e5:bytesi44e6:errorsi05:flagsl11:initialized4:send4:recv8:99f0967fd3:tag8:
  99f0967f7:createdi1603894422e16:in dialogue 
with10:as0bf5d73f6:mediasld5:indexi1e4:type5:audio8:protocol7:RTP/AV 

Sor for me the "ACK" of the delete come less than 1 ms after so no issue
I'm using Version: 7.5.5.1+0~mr7.5.5.1 on Debian 9

Regards 

Le 28/10/2020 15:05, « Users au nom de John Quick » 
 a écrit :

Johan,

I did not want to raise an issue on github before I was sure that I wasn't
doing something stupid.
I have the impression that there are many people using rtpengine, some of
them for high capacity applications.
If there really is a blocking delay of about 3 seconds on every call to
delete, then you would expect to see some really bad things happening under
heavy load.

John Quick
Smartvox Limited


> From: Johan De Clercq  
> Sent: 28 October 2020 13:51
> To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list

> Subject: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately
>
> Did you open an issue on github on rtpengine? Rfuchs comments are always
enlightening 



___
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] rtpengine_delete not returning immediately

[John Quick]

Johan,

I did not want to raise an issue on github before I was sure that I wasn't
doing something stupid.
I have the impression that there are many people using rtpengine, some of
them for high capacity applications.
If there really is a blocking delay of about 3 seconds on every call to
delete, then you would expect to see some really bad things happening under
heavy load.

John Quick
Smartvox Limited


> From: Johan De Clercq  
> Sent: 28 October 2020 13:51
> To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list

> Subject: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately
>
> Did you open an issue on github on rtpengine? Rfuchs comments are always
enlightening 



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

Re: [OpenSIPS-Users] rtpengine_delete not returning immediately

[Jon Abrams]

IIRC, there was a presentation at the recent Summit about adding
support for asynchronous RTP Engine calls. I don't remember if it was
to combat latency internal to RTPEngine or general round-trip time.

You may want to take a look at that.

- Jon Abrams

On Wed, Oct 28, 2020 at 8:36 AM John Quick  wrote:
>
> A packet capture revealed some interesting facts about this problem.
> There is a genuine delay in the response from rtpengine when the delete 
> command is sent. In the packets I captured, the delay was 2 seconds.
> It is possible this delay arises because I am using a low spec virtual server 
> with very little memory to host rtpengine.
> Alternatively, it could be that rtpengine is doing additional processing of 
> the audio streams so it can send a report back to OpenSIPS.
> Using wireshark to inspect the packets, I can see that the response contains 
> round-trip times, packet loss, average/low/high MOS scores, etc.
>
> Does anyone know if there is a way to:
>  a) Reduce the delay within rtpengine so it responds quicker to the delete 
> command
>  b) To make calls to rtpengine_delete() act asynchronously so they don't 
> block the main SIP processing child threads?
>
> John Quick
> Smartvox Limited
>
>
>
> ___
> 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] rtpengine_delete not returning immediately

[Johan De Clercq]

Would it be an option to disable rtcp?

Outlook voor iOS downloaden

Van: Users  namens John Quick 

Verzonden: Wednesday, October 28, 2020 2:34:25 PM
Aan: users@lists.opensips.org 
Onderwerp: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately

A packet capture revealed some interesting facts about this problem.
There is a genuine delay in the response from rtpengine when the delete command 
is sent. In the packets I captured, the delay was 2 seconds.
It is possible this delay arises because I am using a low spec virtual server 
with very little memory to host rtpengine.
Alternatively, it could be that rtpengine is doing additional processing of the 
audio streams so it can send a report back to OpenSIPS.
Using wireshark to inspect the packets, I can see that the response contains 
round-trip times, packet loss, average/low/high MOS scores, etc.

Does anyone know if there is a way to:
 a) Reduce the delay within rtpengine so it responds quicker to the delete 
command
 b) To make calls to rtpengine_delete() act asynchronously so they don't block 
the main SIP processing child threads?

John Quick
Smartvox Limited



___
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] rtpengine_delete not returning immediately

[Johan De Clercq]

Did you open an issue on github on rtpengine? Rfuchs comments are always 
enlightening

Outlook voor iOS downloaden

Van: Users  namens John Quick 

Verzonden: Wednesday, October 28, 2020 12:51:33 PM
Aan: users@lists.opensips.org 
Onderwerp: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately

Callum,

Thanks for the suggestion. I added a rule to iptables on the OpenSIPS server to 
allow all UDP from the rtpengine server.
Unfortunately, it made no difference. I also checked the route using mtr and it 
looks fine - less than 5 ms latency, 1 drop in >4000.
Network connectivity seems unlikely to be a contributory factor because the 
offer and answer commands work exactly as I would expect.
Only the delete command exhibits a delay returning.

John Quick
Smartvox Limited


> From: Callum Guy 
> Sent: 27 October 2020 21:12
> To: John Q ; OpenSIPS users mailling list 
> 
> Subject: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately
>
> Have you double checked it's not a firewall issue on the SIP proxy?
>
> The transport is typically UDP so there is a fair chance it's blocked.


___
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] rtpengine_delete not returning immediately

[John Quick]

A packet capture revealed some interesting facts about this problem.
There is a genuine delay in the response from rtpengine when the delete command 
is sent. In the packets I captured, the delay was 2 seconds.
It is possible this delay arises because I am using a low spec virtual server 
with very little memory to host rtpengine.
Alternatively, it could be that rtpengine is doing additional processing of the 
audio streams so it can send a report back to OpenSIPS.
Using wireshark to inspect the packets, I can see that the response contains 
round-trip times, packet loss, average/low/high MOS scores, etc.

Does anyone know if there is a way to:
 a) Reduce the delay within rtpengine so it responds quicker to the delete 
command
 b) To make calls to rtpengine_delete() act asynchronously so they don't block 
the main SIP processing child threads?

John Quick
Smartvox Limited



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

Re: [OpenSIPS-Users] rtpengine_delete not returning immediately

[John Quick]

Callum,

Thanks for the suggestion. I added a rule to iptables on the OpenSIPS server to 
allow all UDP from the rtpengine server.
Unfortunately, it made no difference. I also checked the route using mtr and it 
looks fine - less than 5 ms latency, 1 drop in >4000.
Network connectivity seems unlikely to be a contributory factor because the 
offer and answer commands work exactly as I would expect.
Only the delete command exhibits a delay returning.

John Quick
Smartvox Limited


> From: Callum Guy  
> Sent: 27 October 2020 21:12
> To: John Q ; OpenSIPS users mailling list 
> 
> Subject: Re: [OpenSIPS-Users] rtpengine_delete not returning immediately
>
> Have you double checked it's not a firewall issue on the SIP proxy?
>
> The transport is typically UDP so there is a fair chance it's blocked.


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

Re: [OpenSIPS-Users] Segfault using TLS

[Mark Farmer]

Hi Ovidiu, thanks for your response.

I actually fixed it this morning, looking here:
https://github.com/OpenSIPS/opensips/issues/2204

Led me to an incorrect tls_method setting.

Thanks and sorry for the false alarm :)

Mark.


On Tue, 27 Oct 2020 at 16:41, Ovidiu Sas  wrote:

> Hello Mark,
>
> Please follow the instructions from the opensips website:
> https://www.opensips.org/Documentation/TroubleShooting-Crash
>
> Regards,
> Ovidiu Sas
>
> On Tue, Oct 27, 2020 at 12:33 Mark Farmer  wrote:
>
>> Hi everyone
>>
>> I am trying to setup TLS to talk to MS Teams but I am getting a segfault
>> when I try to start OpenSIPS.
>>
>> CRITICAL:core:sig_usr: segfault in attendant (starter) process!
>>
>> The server is Ubuntu 20.04.1
>> OpenSIPS 3.1.0
>>
>> From the log:
>>
>> INFO:tls_mgm:mod_init: initializing TLS management
>> DBG:core:__search_avp_map: looking for [tls_sip_dom] avp  - found -1
>> DBG:core:new_avp_alias: added alias tls_sip_dom with id 24
>> INFO:tls_mgm:mod_init: disabling compression due ZLIB problems
>> INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom1'
>> DBG:tls_mgm:init_tls_dom: no DH params file for tls domain 'dom1'
>> defined, using default '(null)'
>> NOTICE:tls_mgm:init_tls_dom: No EC curve defined
>> DBG:tls_mgm:init_tls_dom: cipher list null ... setting default
>> INFO:tls_mgm:get_ssl_ctx_verify_mode: client verification activated.
>> Client certificates are mandatory.
>> NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none
>> DBG:core:count_module_procs: modules require 3 extra processes
>> CRITICAL:core:sig_usr: segfault in attendant (starter) process!
>> DBG:core:restore_segv_handler: restoring SIGSEGV handler...
>> DBG:core:restore_segv_handler: successfully restored system SIGSEGV
>> handler
>> DBG:core:wait_status_code: read code 0 (0 byte)
>> INFO:core:daemonize: pre-daemon process exiting with -1
>>
>> My TLS config:
>>
>>  TLS_MGM Module
>> loadmodule "tls_mgm.so"
>> modparam("tls_mgm", "server_domain", "dom1")
>> modparam("tls_mgm", "match_ip_address", "[dom1]xxx.xxx.xxx.xxx:5061")
>> modparam("tls_mgm", "match_sip_domain","[dom1]my.domain.com")
>> modparam("tls_mgm", "client_sip_domain_avp", "tls_sip_dom")
>> modparam("tls_mgm", "certificate",
>> "[dom1]/usr/local/etc/opensips/tls/mycert.pem")
>> modparam("tls_mgm", "private_key",
>> "[dom1]/usr/local/etc/opensips/tls/mykey.key")
>> modparam("tls_mgm", "ca_list",
>> "[dom1]/usr/local/etc/opensips/tls/calist.pem")
>> modparam("tls_mgm", "ca_dir", "[dom1]/usr/local/etc/opensips/certs/CA")
>> modparam("tls_mgm", "tls_method", "[dom1]TLSv23")
>>
>>  PROTO_TLS Module
>> loadmodule "proto_tls.so"
>> modparam("proto_tls", "tls_max_msg_chunks", 8)
>> modparam("proto_tls", "trace_on", 1)
>> modparam("proto_tls", "trace_destination", "sngdst")
>> modparam("proto_tls", "tls_handshake_timeout", 300)
>>
>> Is anyone able to help with this please?
>>
>> Best regards
>> Mark.
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farm...@gmail.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users