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

[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] problem with git branch for opensips 3.0

[Dan Pascu]

On 12 Jun 2019, at 11:26, Bogdan-Andrei Iancu wrote:

> Hi Johan,
> 
> The git contains good docs for the cli tool - if there is something you find 
> as uncovered, please let us know.

The database module doesn't allow one to specify a username/password to grant 
all access to that username to the created database. One has to manually 
perform this task that was previously done automatically by opensipsctldb

--
Dan





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

Re: [OpenSIPS-Users] Autoscaling

[Dan Pascu]

On 25 Apr 2019, at 17:29, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> The load is considered as the time a processes is busy in doing something 
> (instead of waiting for a new task to handle). It is completely unrelated to 
> the CPU load. Also the load will count any busy waiting or I/O waiting done 
> by the process.

In this case is it correct to define load per process as 
time_spent_processing_per_cycle/measurement_cycle?

Also regarding this measurement cycle, I see a loose reference in the docs 
mentioning that a cycle is "like 2 seconds". Can the cycle length be defined, 
and if so how? If it cannot be defined, what is its actual value? (the "like 2 
seconds" reference sounds vague).

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>  https://www.opensips.org/events/Summit-2019Amsterdam/
> 
> On 04/25/2019 04:47 PM, Dan Pascu wrote:
>> I'm trying to understand how autoscaling works and I'd like some 
>> clarifications.
>> 
>> When a process group load is calculated is that based on actual CPU load, or 
>> is it just computed as busy_processes/total_processes in that group?
>> 
>> What I'm trying to figure out is the behavior in the case of the TCP process 
>> group, which is let's say configured to spawn a new worker when it reaches 
>> 70% load for the TCP worker group. Now consider that this group starts with 
>> 5 workers and at some point in time, all 5 workers are busy processing a 
>> message. In addition let's consider that the DNS lookup is misconfigured and 
>> it takes 3 seconds to get an answer. This means that if the proxy receives 5 
>> messages at a time, all 5 workers will be blocked in a synchronous DNS 
>> lookup for 3 seconds, but each using 0% CPU.
>> 
>> My question is, in this 3 second time window (when all 5 workers are blocked 
>> in waiting for the DNS lookup), if a new request arrives over TCP, will 
>> opensips spawn a new TCP worker because all 5 workers are busy and it 
>> considers the load to be 100%, or it will do nothing because it uses CPU 
>> load which is 0% since all 5 processes are sleeping waiting for the DNS 
>> answer?
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

[OpenSIPS-Users] Autoscaling

[Dan Pascu]

I'm trying to understand how autoscaling works and I'd like some clarifications.

When a process group load is calculated is that based on actual CPU load, or is 
it just computed as busy_processes/total_processes in that group?

What I'm trying to figure out is the behavior in the case of the TCP process 
group, which is let's say configured to spawn a new worker when it reaches 70% 
load for the TCP worker group. Now consider that this group starts with 5 
workers and at some point in time, all 5 workers are busy processing a message. 
In addition let's consider that the DNS lookup is misconfigured and it takes 3 
seconds to get an answer. This means that if the proxy receives 5 messages at a 
time, all 5 workers will be blocked in a synchronous DNS lookup for 3 seconds, 
but each using 0% CPU.

My question is, in this 3 second time window (when all 5 workers are blocked in 
waiting for the DNS lookup), if a new request arrives over TCP, will opensips 
spawn a new TCP worker because all 5 workers are busy and it considers the load 
to be 100%, or it will do nothing because it uses CPU load which is 0% since 
all 5 processes are sleeping waiting for the DNS answer?

--
Dan





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

Re: [OpenSIPS-Users] xcap.DependencyError: need python-application version 1.2.8 or higher but it is not installed

[Dan Pascu]

On 16 Apr 2019, at 23:54, Tony Du wrote:

> Hello:
> 
> I installed openxcap on my Debian 9.x 64 and Ubuntu 18.04 64, I met the same 
> problem:
> 
> When run openxcap
> %sudo openxcap start
> 
> In fact I installed everything required online.  Anyone can give a hint why 
> it cannot find python_application?  When I type import application from 
> python command line, it has no error.

The error tells you that you have an incorrect version (older than 1.2.8). 
Besides this, that check was removed from openxcap 3 years ago so you have some 
severely outdated sources (and some serious stuttering in the backtrace).

> 
> Thanks.
> Tony
> 
> ..
> File "/usr/local/bin/openxcap" line 16, in 
>   import xcap
> File "/usr/local/lib/python2.7/dist-package/xcap/__iinit__.py" line 33, in 
>   
>   package_depencencies = [PackageDependency('pythonn-mysqldb', '1.2.2', 
> 'MySQLdb.__version__')]
> File "/usr/local/lib/python2.7/dist-package/xcap/__iinit__.py" line 31, in 
>   
>   raise DepencencyError("need python- application version %s or higher but it 
> is not installed" & required_version)
> 
> ..
> xcap.DependencyError: need python-application  version   1.2.8 or higher but 
> it is not installed
> 
> ___
> 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] accounting flags

[Dan Pascu]

On 23 Oct 2018, at 16:26, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> A wild guess - were you using the same flag for both missed and failed calls ?

Yes. I used the same flag for everything normal/missed/failed accounting.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/16/2018 05:20 PM, Dan Pascu wrote:
>> On 16 Oct 2018, at 16:55, Bogdan-Andrei Iancu wrote:
>> 
>>> BTW, the missed and failed concepts were also in 1.11, with the same 
>>> behavior as in 2.4
>> It seems I missed the failed flag when I skimmed the 1.11 docs to see the 
>> difference.
>> 
>> However I checked my old configurations and the behavior is not the same 
>> between 1.11 and 2.4. In 1.11 I used to set the accounting flag, the failed 
>> flag and the missed flag at the same time, but I would only get 1 negative 
>> reply being logged if the call failed. In 2.4 I get it twice (once from 
>> missed and once from failed) unless is a call with an intermediary failure 
>> (like 1 branch says 486 busy and the other says 200 ok) in which case I get 
>> it once (from missed) and  also get the 200 ok.
>> 
>> BTW, some failure codes are skipped even when missed is defined, like for 
>> example 482 loop detected. are they handled differently?
>> 
>>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104
>>> 
>>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880
>>> 
>>> Regards,
>>> 
>>> Bogdan-Andrei Iancu
>>> 
>>> OpenSIPS Founder and Developer
>>>  http://www.opensips-solutions.com
>>> OpenSIPS Bootcamp 2018
>>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>> 
>>> On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
>>>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>>>> 
>>>> Regards,
>>>> 
>>>> Bogdan-Andrei Iancu
>>>> 
>>>> OpenSIPS Founder and Developer
>>>>  http://www.opensips-solutions.com
>>>> OpenSIPS Bootcamp 2018
>>>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>>> 
>>>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>>>> What is the difference between the missed and failed flags for 
>>>>> do_accounting? They seem to overlap entirely for me (if I use both missed 
>>>>> and failed flags I get any code >= 300 reported twice).
>>>>> 
>>>>> In version 1.11 there was only the missed flag that reported all response 
>>>>> codes >= 300, but now we have 2 and the documentation is not clear on 
>>>>> their difference.
>>>>> 
>>>>> -- 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> 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
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
> 


--
Dan





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

Re: [OpenSIPS-Users] Presence issue

[Dan Pascu]

On 17 Oct 2018, at 23:33, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> What I failed so far was to reproduced it in a controlled environment. Do you 
> have a setup, special cfg + SIP UAC , instructions to reproduce this issue ?

I use Blink as the client. I see this every time the proxy receives a PUBLISH 
request:

Oct 19 19:29:55 node15 ./opensips[23510]: [CONFIG] PUBLISH for presence 
sip:d...@test.sip2sip.info origin 86.120.12.1
64:41062 from sip:d...@test.sip2sip.info to sip:d...@test.sip2sip.info 
(243988a9-511e-4108-8950-5ab6edf82c3c)
Oct 19 19:29:55 node15 ./opensips[23510]: 
CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Du
plicate entry 'dan-test.sip2sip.info-presence-a.1539700118.23510.517.1' for key 
'presentity_idx'
Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:core:db_do_update: error while 
submitting query
Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:presence:update_presentity: 
updating published info in database
Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:presence:handle_publish: when 
updating presentity

or this:

Oct 19 19:29:55 node15 ./opensips[23508]: [CONFIG] PUBLISH for presence 
sip:d...@test.sip2sip.info origin 86.120.12.1
64:39673 from sip:d...@test.sip2sip.info to sip:d...@test.sip2sip.info 
(cc4704d0-a5e7-4c78-89ae-4c31b6cb6246)
Oct 19 19:29:55 node15 ./opensips[23508]: INFO:presence:update_presentity: *** 
found in db but not in htable [a.1539
700118.23508.2291.0]

Below is the relevant part of my configuration (I included all the presence 
related modules I load and their configuration as they may be relevant):

# The address on which OpenSIPS will listen
define(`SERVER_IP', esyscmd(`echo -n $(hostname -i)'))
define(`SERVER_UDP_PORT', `5060')
define(`SERVER_TCP_PORT', `5060')
define(`SERVER_TLS_PORT', `5061')

# The server contact address
define(`SERVER_ADDRESS', `ifelse(SERVER_UDP_PORT, `5060', `SERVER_IP', 
`SERVER_IP:SERVER_UDP_PORT')')
# Contact used by the presence server
define(`PRESENCE_SERVER_ADDRESS', `sip:presence@SERVER_ADDRESS')
# Contact used by the resource list server
define(`RLS_SERVER_ADDRESS', `sip:rls@SERVER_ADDRESS')


loadmodule "presence.so"
loadmodule "xcap.so"
loadmodule "presence_xml.so"
loadmodule "presence_mwi.so"
loadmodule "pua.so"
loadmodule "pua_mi.so"
loadmodule "rls.so"
loadmodule "presence_xcapdiff.so"


modparam("presence", "db_url", "MySQL_URI")
modparam("presence", "server_address", "PRESENCE_SERVER_ADDRESS")
modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)
modparam("presence", "notify_offline_body", 0)

modparam("presence_xml", "pres_rules_auid", "org.openmobilealliance.pres-rules")
modparam("presence_xml", "force_active", 0)
modparam("presence_xml", "pidf_manipulation", 1)
modparam("presence_xml", "generate_offline_body", 0)

modparam("pua", "db_url", "MySQL_URI")

modparam("xcap", "db_url", "MySQL_URI")
modparam("xcap", "integrated_xcap_server", 1)

modparam("rls", "server_address", "RLS_SERVER_ADDRESS")
modparam("rls", "to_presence_code", 5)
modparam("rls", "waitn_time", 10)

route {
if ($rm == "PUBLISH") {
if (is_from_local()) {
if (!proxy_authorize("", "SUBSCRIBER_TABLE")) {
proxy_challenge("", "0");
return;
} else if ($au != $fU) {
sl_send_reply("403", "Username!=From not allowed ($au!=$fU)");
return;
}

if ($rd == "") {
$rd = $fd;
}

if (avp_check("$hdr(Event)", "fm/presence*/i") && ($au != $rU || 
$ar != $rd)) {
sl_send_reply("403", "Publishing $hdr(Event) events for others 
is forbidden");
return;
}

# Hide auth credentials to downstream routers
consume_credentials();
} else {
sl_send_reply("403", "PUBLISH forbidden for outside domains");
return;
}

if (t_newtran()) {
handle_publish();
} else {
sl_reply_error();
}
exit;
}
}


--
Dan





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

Re: [OpenSIPS-Users] accounting flags

[Dan Pascu]

On 16 Oct 2018, at 16:55, Bogdan-Andrei Iancu wrote:

> BTW, the missed and failed concepts were also in 1.11, with the same behavior 
> as in 2.4

It seems I missed the failed flag when I skimmed the 1.11 docs to see the 
difference.

However I checked my old configurations and the behavior is not the same 
between 1.11 and 2.4. In 1.11 I used to set the accounting flag, the failed 
flag and the missed flag at the same time, but I would only get 1 negative 
reply being logged if the call failed. In 2.4 I get it twice (once from missed 
and once from failed) unless is a call with an intermediary failure (like 1 
branch says 486 busy and the other says 200 ok) in which case I get it once 
(from missed) and  also get the 200 ok.

BTW, some failure codes are skipped even when missed is defined, like for 
example 482 loop detected. are they handled differently?

> 
> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104
> 
> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>> 
>> Regards,
>> 
>> Bogdan-Andrei Iancu
>> 
>> OpenSIPS Founder and Developer
>>  http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>> 
>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>> What is the difference between the missed and failed flags for 
>>> do_accounting? They seem to overlap entirely for me (if I use both missed 
>>> and failed flags I get any code >= 300 reported twice).
>>> 
>>> In version 1.11 there was only the missed flag that reported all response 
>>> codes >= 300, but now we have 2 and the documentation is not clear on their 
>>> difference.
>>> 
>>> -- 
>>> Dan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
> 


--
Dan





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

Re: [OpenSIPS-Users] accounting flags

[Dan Pascu]

On 16 Oct 2018, at 16:30, Bogdan-Andrei Iancu wrote:

> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting

Thanks, that clarifies things. It would help to have a mention of this in the 
module readme. I was reading that, because that is the first thing I go for 
when it comes to documentation.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>> What is the difference between the missed and failed flags for 
>> do_accounting? They seem to overlap entirely for me (if I use both missed 
>> and failed flags I get any code >= 300 reported twice).
>> 
>> In version 1.11 there was only the missed flag that reported all response 
>> codes >= 300, but now we have 2 and the documentation is not clear on their 
>> difference.
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

[OpenSIPS-Users] accounting flags

[Dan Pascu]

What is the difference between the missed and failed flags for do_accounting? 
They seem to overlap entirely for me (if I use both missed and failed flags I 
get any code >= 300 reported twice).

In version 1.11 there was only the missed flag that reported all response codes 
>= 300, but now we have 2 and the documentation is not clear on their 
difference.

--
Dan





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

Re: [OpenSIPS-Users] Presence issue

[Dan Pascu]

On 28 Sep 2018, at 14:36, Dan Pascu wrote:

> 
> On 24 Sep 2018, at 23:14, Bogdan-Andrei Iancu wrote:
> 
>> Hi Dan,
>> 
>> I'm trying to hunt this issue for a while , see:
>> 
>> https://github.com/OpenSIPS/opensips/issues/1422
>> https://github.com/OpenSIPS/opensips/issues/1378
>> 
>> But I never was able to reproduce it local, in order to debug it. Can you 
>> reproduce it ?
> 
> It happens to me for every PUBLISH received.

So what information would you need in order to fix this?

> 
>> 
>> 
>> Best regards,
>> 
>> Bogdan-Andrei Iancu
>> 
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>> http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>> 
>> On 09/21/2018 02:16 PM, Dan Pascu wrote:
>>> After I started to test the lastest git code from master I noticed errors 
>>> like this in my logs:
>>> 
>>> 
>>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
>>> CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): 
>>> Duplicate entry 'dan-test.sip2sip.info-presence-a.1537527127.22838.2.1' for 
>>> key 'presentity_idx'
>>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:core:db_do_update: 
>>> error while submitting query
>>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
>>> ERROR:presence:update_presentity: updating published info in database
>>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
>>> ERROR:presence:handle_publish: when updating presentity
>>> 
>>> 
>>> I checked the presentity table and there is NO record with etag = 
>>> a.1537527127.22838.2.1 in the database. I found however multiple records in 
>>> the database for that particular account some of which are long expired yet 
>>> not deleted from the database. The records seem to increase every time I 
>>> publish presence:
>>> 
>>> MariaDB [opensips]> select username, domain, event, etag from presentity 
>>> where username = 'dan';
>>> +--+---+--++
>>> | username | domain| event| etag   |
>>> +--+---+--++
>>> | dan  | test.sip2sip.info | presence | a.1537455410.31931.2.2 |
>>> | dan  | test.sip2sip.info | presence | a.1537456928.2432.2.0  |
>>> | dan  | test.sip2sip.info | presence | a.1537526062.20412.1.0 |
>>> | dan  | test.sip2sip.info | presence | a.1537526092.20529.2.0 |
>>> | dan  | test.sip2sip.info | presence | a.1537526122.20854.1.0 |
>>> | dan  | test.sip2sip.info | presence | a.1537526997.22186.2.0 |
>>> | dan  | test.sip2sip.info | presence | a.1537527037.22557.1.0 |
>>> | dan  | test.sip2sip.info | presence | a.1537527072.22698.1.0 |
>>> | dan  | test.sip2sip.info | presence | a.1537527127.22835.2.0 |
>>> +--+---+--++
>>> 9 rows in set (0.00 sec)
>>> 
>>> 
>>> I also checked an older opensips-1.11 server and there I only have 1 record 
>>> per AOR and I never see such errors in syslog:
>>> 
>>> mysql> select username, domain, event, etag from presentity where username 
>>> = 'dan';
>>> +--+-+--++
>>> | username | domain  | event| etag   |
>>> +--+-+--++
>>> | dan  | ag-projects.com | presence | a.1530701145.32175.100449.152  |
>>> | dan  | sip2sip.info| presence | a.1530701145.32185.100643.3251 |
>>> +--+-+--++
>>> 2 rows in set (0.00 sec)
>>> 
>>> 
>>> I use the same SIP client in both cases, but I only see the errors on the 
>>> latest opensips from master. These errors happen every time I publish 
>>> presence for that account.
>>> 
>>> In addition I noticed other presence related errors in syslog, which might 
>>> or might not be related to this:
>>> 
>>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>>> ERROR:presence:delete_phtable_query: Record not found 
>>> [a.1537526997.22186.2.0]
>>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>>> ERROR:presence:msg_presentity_clean: deleting from pres hash table
>>

Re: [OpenSIPS-Users] Presence issue

[Dan Pascu]

On 24 Sep 2018, at 23:14, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> I'm trying to hunt this issue for a while , see:
> 
> https://github.com/OpenSIPS/opensips/issues/1422
> https://github.com/OpenSIPS/opensips/issues/1378
> 
> But I never was able to reproduce it local, in order to debug it. Can you 
> reproduce it ?

It happens to me for every PUBLISH received.

> 
> 
> Best regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/21/2018 02:16 PM, Dan Pascu wrote:
>> After I started to test the lastest git code from master I noticed errors 
>> like this in my logs:
>> 
>> 
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
>> CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): 
>> Duplicate entry 'dan-test.sip2sip.info-presence-a.1537527127.22838.2.1' for 
>> key 'presentity_idx'
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:core:db_do_update: 
>> error while submitting query
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
>> ERROR:presence:update_presentity: updating published info in database
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
>> ERROR:presence:handle_publish: when updating presentity
>> 
>> 
>> I checked the presentity table and there is NO record with etag = 
>> a.1537527127.22838.2.1 in the database. I found however multiple records in 
>> the database for that particular account some of which are long expired yet 
>> not deleted from the database. The records seem to increase every time I 
>> publish presence:
>> 
>> MariaDB [opensips]> select username, domain, event, etag from presentity 
>> where username = 'dan';
>> +--+---+--++
>> | username | domain| event| etag   |
>> +--+---+--++
>> | dan  | test.sip2sip.info | presence | a.1537455410.31931.2.2 |
>> | dan  | test.sip2sip.info | presence | a.1537456928.2432.2.0  |
>> | dan  | test.sip2sip.info | presence | a.1537526062.20412.1.0 |
>> | dan  | test.sip2sip.info | presence | a.1537526092.20529.2.0 |
>> | dan  | test.sip2sip.info | presence | a.1537526122.20854.1.0 |
>> | dan  | test.sip2sip.info | presence | a.1537526997.22186.2.0 |
>> | dan  | test.sip2sip.info | presence | a.1537527037.22557.1.0 |
>> | dan  | test.sip2sip.info | presence | a.1537527072.22698.1.0 |
>> | dan  | test.sip2sip.info | presence | a.1537527127.22835.2.0 |
>> +--+---+--++
>> 9 rows in set (0.00 sec)
>> 
>> 
>> I also checked an older opensips-1.11 server and there I only have 1 record 
>> per AOR and I never see such errors in syslog:
>> 
>> mysql> select username, domain, event, etag from presentity where username = 
>> 'dan';
>> +--+-+--++
>> | username | domain  | event| etag   |
>> +--+-+--++
>> | dan  | ag-projects.com | presence | a.1530701145.32175.100449.152  |
>> | dan  | sip2sip.info| presence | a.1530701145.32185.100643.3251 |
>> +--+-+--++
>> 2 rows in set (0.00 sec)
>> 
>> 
>> I use the same SIP client in both cases, but I only see the errors on the 
>> latest opensips from master. These errors happen every time I publish 
>> presence for that account.
>> 
>> In addition I noticed other presence related errors in syslog, which might 
>> or might not be related to this:
>> 
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>> ERROR:presence:delete_phtable_query: Record not found 
>> [a.1537526997.22186.2.0]
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>> ERROR:presence:msg_presentity_clean: deleting from pres hash table
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>> ERROR:presence:delete_phtable_query: Record not found 
>> [a.1537527037.22557.1.0]
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>> ERROR:presence:msg_presentity_clean: deleting from pres hash table
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>> ERROR:presence:delete_phtable_query: Record not found 
>> [a.1537527072.22698.1.0]
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
>> ERROR:presence:msg_presentity_clean: deleting from pres hash table
>> 
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Crash in logging

[Dan Pascu]

On 20 Sep 2018, at 20:19, Dan Pascu wrote:

> 
> On 20 Sep 2018, at 19:08, Bogdan-Andrei Iancu wrote:
> 
>> Hi Dan,
>> 
>> Please report this on the GitHub tracker ; in addition - is the crash 
>> reproducible , have you identified the faulty xlog() in your script ? is all 
>> the time the same ?
> 
> It happened multiple times, but I cannot reproduce it at will. The crashes 
> are random. What seems to be common in all cases is that the frm variable in 
> frame 12 looks like corrupted memory. The value there seems to always be 
> different, but always garbage.

My mistake. I wrongly interpreted frm as the format and thought it was 
corrupted. After checking the code it turns out frm points to some pv stuff, so 
it seems fine. Nothing seems corrupted, yet I get crashes very often on that 
xlog from the script that is just static text, with no pvs/avps.

--
Dan





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

[OpenSIPS-Users] Presence issue

[Dan Pascu]

After I started to test the lastest git code from master I noticed errors like 
this in my logs:


Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): 
Duplicate entry 'dan-test.sip2sip.info-presence-a.1537527127.22838.2.1' for key 
'presentity_idx'
Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:core:db_do_update: 
error while submitting query
Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
ERROR:presence:update_presentity: updating published info in database
Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: 
ERROR:presence:handle_publish: when updating presentity


I checked the presentity table and there is NO record with etag = 
a.1537527127.22838.2.1 in the database. I found however multiple records in the 
database for that particular account some of which are long expired yet not 
deleted from the database. The records seem to increase every time I publish 
presence:

MariaDB [opensips]> select username, domain, event, etag from presentity where 
username = 'dan';
+--+---+--++
| username | domain| event| etag   |
+--+---+--++
| dan  | test.sip2sip.info | presence | a.1537455410.31931.2.2 |
| dan  | test.sip2sip.info | presence | a.1537456928.2432.2.0  |
| dan  | test.sip2sip.info | presence | a.1537526062.20412.1.0 |
| dan  | test.sip2sip.info | presence | a.1537526092.20529.2.0 |
| dan  | test.sip2sip.info | presence | a.1537526122.20854.1.0 |
| dan  | test.sip2sip.info | presence | a.1537526997.22186.2.0 |
| dan  | test.sip2sip.info | presence | a.1537527037.22557.1.0 |
| dan  | test.sip2sip.info | presence | a.1537527072.22698.1.0 |
| dan  | test.sip2sip.info | presence | a.1537527127.22835.2.0 |
+--+---+--++
9 rows in set (0.00 sec)


I also checked an older opensips-1.11 server and there I only have 1 record per 
AOR and I never see such errors in syslog:

mysql> select username, domain, event, etag from presentity where username = 
'dan';
+--+-+--++
| username | domain  | event| etag   |
+--+-+--++
| dan  | ag-projects.com | presence | a.1530701145.32175.100449.152  |
| dan  | sip2sip.info| presence | a.1530701145.32185.100643.3251 |
+--+-+--++
2 rows in set (0.00 sec)


I use the same SIP client in both cases, but I only see the errors on the 
latest opensips from master. These errors happen every time I publish presence 
for that account.

In addition I noticed other presence related errors in syslog, which might or 
might not be related to this:

Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
ERROR:presence:delete_phtable_query: Record not found [a.1537526997.22186.2.0]
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
ERROR:presence:msg_presentity_clean: deleting from pres hash table
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
ERROR:presence:delete_phtable_query: Record not found [a.1537527037.22557.1.0]
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
ERROR:presence:msg_presentity_clean: deleting from pres hash table
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
ERROR:presence:delete_phtable_query: Record not found [a.1537527072.22698.1.0]
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: 
ERROR:presence:msg_presentity_clean: deleting from pres hash table


--
Dan





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

Re: [OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

On 21 Sep 2018, at 12:48, Bogdan-Andrei Iancu wrote:

> Dan,
> 
> For the delay warnings, that's what the code does - it checks time difference 
> (internal ticker) between writing and reading from a pipe. If you there is no 
> load (to prevent the workers to read from the pipe), the only delay may come 
> from the actual pipe communication. Why the delay, not sure for me too.
> 
> On the second issue (already scheduled), the warning reports an almost that 
> the timer job was triggered almost 30 seconds ago without completing (note 
> that the timestamp between the brackets is the absolute time from start, not 
> a diff -> the 21 minutes are the uptime, not the delay).
> 
> When you get such warnings, try to run an "opensipsctl trap" , maybe we can 
> see what the timer job is doing - I guess it is very slow (in whatever doing).

It might be triggered by something else. Yesterday when I had the issue I had 
another issue where radius was not able to insert records in the database and 
consequently opensips did timeout on those radius accounting requests. It also 
seems that the radius timeout was the same 30 seconds. After I fixed the radius 
issue I've never seen the timer warnings again. So it's possible that they only 
trigger under such circumstances and are somehow related to the radius 
accounting timing out.

--
Dan





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

Re: [OpenSIPS-Users] Crash in logging

[Dan Pascu]

On 20 Sep 2018, at 19:08, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Please report this on the GitHub tracker ; in addition - is the crash 
> reproducible , have you identified the faulty xlog() in your script ? is all 
> the time the same ?

It happened multiple times, but I cannot reproduce it at will. The crashes are 
random. What seems to be common in all cases is that the frm variable in frame 
12 looks like corrupted memory. The value there seems to always be different, 
but always garbage.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 06:59 PM, Dan Pascu wrote:
>> Here is another crash that happened multiple times:
>> 
>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid 
>> -m 512'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  0xb770ccf9 in __kernel_vsyscall ()
>> (gdb) bt
>> #0  0xb770ccf9 in __kernel_vsyscall ()
>> #1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at 
>> ../sysdeps/unix/sysv/linux/nptl-signals.h:79
>> #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>> #3  0xb7548297 in __GI_abort () at abort.c:89
>> #4  0xb758238f in __libc_message (do_abort=, fmt=> out>) at ../sysdeps/posix/libc_fatal.c:175
>> #5  0xb7588fc7 in malloc_printerr (action=, str=0xb7678cc6 
>> "corrupted size vs. prev_size", ptr=, ar_ptr=0xb76ce780 
>> ) at malloc.c:5049
>> #6  0xb758b4d5 in _int_malloc (av=av@entry=0xb76ce780 , 
>> bytes=bytes@entry=360) at malloc.c:3765
>> #7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
>> #8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, 
>> sizeloc=0xbfb823b0) at memstream.c:76
>> #9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", 
>> ap=0xbfb8245c "\035") at ../misc/syslog.c:167
>> #10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at 
>> ../misc/syslog.c:129
>> #11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=) at 
>> /usr/include/i386-linux-gnu/bits/syslog.h:31
>> #12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " 
>> \372\177\001\035") at xlog.c:230
>> #13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
>> #14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at 
>> action.c:172
>> #15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
>> #16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at 
>> action.c:172
>> #17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
>> #18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
>> #19 0x004f9a33 in receive_msg (buf=, len=, 
>> rcv_info=, existing_context=, flags=> out>) at receive.c:209
>> #20 0x00642878 in tcp_handle_req (_max_msg_chunks=, 
>> con=0x97d793ec, req=0x77bea0 ) at 
>> net/proto_tcp/tcp_common.h:411
>> #21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at 
>> net/proto_tcp/proto_tcp.c:1179
>> #22 0x00622a8e in handle_io (fm=, idx=idx@entry=0, 
>> event_type=event_type@entry=1) at net/net_tcp_proc.c:241
>> #23 0x006250d5 in io_wait_loop_epoll (h=, t=, 
>> repeat=) at net/../io_wait_loop.h:280
>> #24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
>> #25 0x00630993 in tcp_start_processes (chd_rank=0x758980 , 
>> startup_done=0x0) at net/net_tcp.c:1887
>> #26 0x004d642c in main_loop () at main.c:761
>> #27 main (argc=, argv=) at main.c:1407
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Delayed timer executions

[Dan Pascu]

On 20 Sep 2018, at 19:06, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Copying from my previous reply to Pasan:
> 
> 
> "If there is no load (worker processes are idle, no busy with anything else), 
> the reported delay may be generated only by the interprocess communication 
> (passing the job from the triggering process to the executing process via 
> internal pipes).
> 
> What are the values you typically observe ? maybe the warning is jst about a 
> slow context switching on your server (btw, how many cores ?)."

While I would agree with you for these messages:

./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 5 us delay in execution

that indicate a 40-50ms delay, I do not think that you can blame context 
switching for these messages:

Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 29850 ms ago (now 1238480 ms), delaying 
execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29850 ms ago (now 1238580 ms), 
delaying execution

If I read them correctly they say that the timer was already scheduled 30 
seconds ago and the timer already has a lifetime of 1238 seconds - almost 
21minutes!!! - and still hasn't fired yet.

Plus the system I use is a 4 core real machine, so how bad can the context 
switching be that I see my log flooded with these messages (the later type of 
messages were logged every 100ms for 30 seconds - which makes them like 300 log 
messages whenever this happens)?

Re-read my second message on the matter, because those do not look like context 
switching.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 06:55 PM, Dan Pascu wrote:
>> On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:
>> 
>>> Hi Dan,
>>> 
>>> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find 
>>> out the exact reason. btw are you using a virtualise environment ?
>> No
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Segmentation fault in master

[Dan Pascu]

On 20 Sep 2018, at 19:04, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Please report this on the GitHub tracker ; in addition - is the crash 
> reproducible ?

It happened multiple times, but I do not have a way to reproduce it at will.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 05:15 PM, Dan Pascu wrote:
>> I got this crash (memory seems to be corrupted in src->h_addr_list[0]):
>> 
>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid 
>> -m 512'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  __memcpy_sse2_unaligned () at 
>> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
>> 667  ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or 
>> directory.
>> (gdb) bt
>> #0  __memcpy_sse2_unaligned () at 
>> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
>> #1  0x004faf84 in memcpy (__len=, __src=, 
>> __dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
>> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
>> #3  0x96bd108e in shm_clone_proxy (move_dn=, sp=> out>) at ../../resolve.h:391
>> #4  add_uac (t=t@entry=0x97dfc584, request=request@entry=0x96c07240 
>> , uri=uri@entry=0xbfae0790, next_hop=, 
>> bflags=, path=, proxy=) at 
>> t_fwd.c:437
>> #5  0x96bd442a in t_forward_nonack (t=, p_msg=> out>, proxy=, reset_bcounter=, 
>> locked=) at t_fwd.c:757
>> #6  0x96b7d5d4 in do_dns_failover (t=t@entry=0x97dfc584) at t_reply.c:702
>> #7  0x96b7fa44 in t_should_relay_response (Trans=Trans@entry=0x97dfc584, 
>> new_code=new_code@entry=408, branch=branch@entry=0, should_store=0xbfae0a00, 
>> should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0x) at 
>> t_reply.c:962
>> #8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0x, branch=0, 
>> msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
>> #9  0x96bcdc0c in fake_reply (code=408, branch=, 
>> t=0x97dfc584) at timer.c:260
>> #10 final_response_handler (fr_tl=) at timer.c:399
>> #11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
>> #12 0x005422e4 in handle_timer_job () at timer.c:738
>> #13 0x0061e835 in handle_io (idx=, event_type=> out>, fm=) at net/net_udp.c:265
>> #14 io_wait_loop_epoll (h=, t=, 
>> repeat=) at net/../io_wait_loop.h:284
>> #15 udp_start_processes (chd_rank=0x759980 , startup_done=0x0) at 
>> net/net_udp.c:389
>> #16 0x004d7418 in main_loop () at main.c:755
>> #17 main (argc=, argv=) at main.c:1407
>> (gdb) frame 2
>> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
>> 75   proxy.c: No such file or directory.
>> (gdb) print *src
>> $1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, 
>> h_addr_list = 0x97df1dd8}
>> (gdb) print *dst
>> $2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, 
>> h_addr_list = 0x97e04abc}
>> (gdb) print src->h_addr_list[0]
>> $4 = 0x22e1f08 
>> (gdb) print src->h_addr_list[1]
>> $5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
>> (gdb) print src->h_addr_list[2]
>> $6 = 0x97df1de8 
>> "Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
>> (gdb) print src->h_addr_list[3]
>> $7 = 0x0
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

[OpenSIPS-Users] Crash in logging

[Dan Pascu]

Here is another crash that happened multiple times:

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 
512'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb770ccf9 in __kernel_vsyscall ()
(gdb) bt
#0  0xb770ccf9 in __kernel_vsyscall ()
#1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7548297 in __GI_abort () at abort.c:89
#4  0xb758238f in __libc_message (do_abort=, fmt=) at ../sysdeps/posix/libc_fatal.c:175
#5  0xb7588fc7 in malloc_printerr (action=, str=0xb7678cc6 
"corrupted size vs. prev_size", ptr=, ar_ptr=0xb76ce780 
) at malloc.c:5049
#6  0xb758b4d5 in _int_malloc (av=av@entry=0xb76ce780 , 
bytes=bytes@entry=360) at malloc.c:3765
#7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
#8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) 
at memstream.c:76
#9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", 
ap=0xbfb8245c "\035") at ../misc/syslog.c:167
#10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at 
../misc/syslog.c:129
#11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=) at 
/usr/include/i386-linux-gnu/bits/syslog.h:31
#12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") 
at xlog.c:230
#13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
#14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
#15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
#16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
#17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
#18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
#19 0x004f9a33 in receive_msg (buf=, len=, 
rcv_info=, existing_context=, flags=) at receive.c:209
#20 0x00642878 in tcp_handle_req (_max_msg_chunks=, 
con=0x97d793ec, req=0x77bea0 ) at 
net/proto_tcp/tcp_common.h:411
#21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at 
net/proto_tcp/proto_tcp.c:1179
#22 0x00622a8e in handle_io (fm=, idx=idx@entry=0, 
event_type=event_type@entry=1) at net/net_tcp_proc.c:241
#23 0x006250d5 in io_wait_loop_epoll (h=, t=, 
repeat=) at net/../io_wait_loop.h:280
#24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
#25 0x00630993 in tcp_start_processes (chd_rank=0x758980 , 
startup_done=0x0) at net/net_tcp.c:1887
#26 0x004d642c in main_loop () at main.c:761
#27 main (argc=, argv=) at main.c:1407

--
Dan





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

Re: [OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:

> Hi Dan,
> 
> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find 
> out the exact reason. btw are you using a virtualise environment ?

No

--
Dan





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

[OpenSIPS-Users] Segmentation fault in master

[Dan Pascu]

I got this crash (memory seems to be corrupted in src->h_addr_list[0]):

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 
512'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned () at 
../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
667 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or 
directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at 
../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
#1  0x004faf84 in memcpy (__len=, __src=, 
__dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
#3  0x96bd108e in shm_clone_proxy (move_dn=, sp=) 
at ../../resolve.h:391
#4  add_uac (t=t@entry=0x97dfc584, request=request@entry=0x96c07240 
, uri=uri@entry=0xbfae0790, next_hop=, 
bflags=, path=, proxy=) at 
t_fwd.c:437
#5  0x96bd442a in t_forward_nonack (t=, p_msg=, 
proxy=, reset_bcounter=, locked=) 
at t_fwd.c:757
#6  0x96b7d5d4 in do_dns_failover (t=t@entry=0x97dfc584) at t_reply.c:702
#7  0x96b7fa44 in t_should_relay_response (Trans=Trans@entry=0x97dfc584, 
new_code=new_code@entry=408, branch=branch@entry=0, should_store=0xbfae0a00, 
should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0x) at 
t_reply.c:962
#8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0x, branch=0, 
msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
#9  0x96bcdc0c in fake_reply (code=408, branch=, t=0x97dfc584) 
at timer.c:260
#10 final_response_handler (fr_tl=) at timer.c:399
#11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
#12 0x005422e4 in handle_timer_job () at timer.c:738
#13 0x0061e835 in handle_io (idx=, event_type=, 
fm=) at net/net_udp.c:265
#14 io_wait_loop_epoll (h=, t=, repeat=) at net/../io_wait_loop.h:284
#15 udp_start_processes (chd_rank=0x759980 , startup_done=0x0) at 
net/net_udp.c:389
#16 0x004d7418 in main_loop () at main.c:755
#17 main (argc=, argv=) at main.c:1407
(gdb) frame 2
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
75  proxy.c: No such file or directory.
(gdb) print *src
$1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, h_addr_list 
= 0x97df1dd8}
(gdb) print *dst
$2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, h_addr_list 
= 0x97e04abc}
(gdb) print src->h_addr_list[0]
$4 = 0x22e1f08 
(gdb) print src->h_addr_list[1]
$5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[2]
$6 = 0x97df1de8 
"Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[3]
$7 = 0x0

--
Dan





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

Re: [OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

Here is a follow up on this problem. I started to use the system to do some 
testing. I only have 1 device registered that makes some calls. I started to 
notice similar type of messages, but with a slightly different pattern while 
testing it. They seem to happen more often when I end the call, but I cannot 
unequivocally tie the behavior to that because it doesn't happen always when I 
end a call, it just seems to be triggered more often during that time.

I see a string of warnings about timers that continue for about 30 seconds 
after which they stop, like below (I trimmed the output because it's just 
repeating every 90-100ms and the log would be too long, so I only pasted the 
start and the end of it):

Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 100 ms ago (now 1208830 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 200 ms ago (now 1208930 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 300 ms ago (now 1209030 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 400 ms ago (now 1209130 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 500 ms ago (now 1209230 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 600 ms ago (now 1209330 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 700 ms ago (now 1209430 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 800 ms ago (now 1209530 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 900 ms ago (now 1209630 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 1000 ms ago (now 1209630 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 1000 ms ago (now 1209730 ms), 
delaying execution
Sep 20 10:28:35 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 1100 ms ago (now 1209830 ms), 
delaying execution

[...]

Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28760 ms ago (now 1237490 ms), 
delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 28860 ms ago (now 1237490 ms), delaying 
execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28860 ms ago (now 1237590 ms), 
delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28960 ms ago (now 1237690 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29060 ms ago (now 1237790 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29160 ms ago (now 1237890 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29260 ms ago (now 1237990 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29360 ms ago (now 1238090 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29460 ms ago (now 1238190 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29560 ms ago (now 1238290 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29660 ms ago (now 1238390 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29750 ms ago (now 1238480 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 29850 ms ago (now 1238480 ms), delaying 
execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29850 ms ago (now 1238580 ms), 
delaying execution

On 17 Sep 2018, at 12:30, Dan Pascu wrote:

> 
> I quite often find these warnings in syslog. They 

[OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

I quite often find these warnings in syslog. They happen on an opensips 2.4 
installation that is completely idle (it does not process any messages at all, 
no registrations, no calls, no presence, nothing). Sometimes I see these 
warnings right after I start opensips, during the startup log, while the others 
happen randomly during the day.

The excerpt below is what I got from opensips running for a few days and being 
completely idle the whole time:

./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 5 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21847]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job  has a 
2 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has 
a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has 
a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job  has a 
3 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job  has a 
4 us delay in execution
./opensips[21846]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job  has a 
3 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21841]: WARNING:core:handle_timer_job: timer job  has 
a 5 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 5 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has 
a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: utimer job  has a 
3 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has 
a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has a 
4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job  has 
a 4 us delay in execution
./opensips[21850]: 

[OpenSIPS-Users] tls_mgm modparam

[Dan Pascu]

Tried to use the following setting:

modparam("tls_mgm", "match_ip_address", "[default]*”)

This resulted in the following error:

Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_domain_address: TLS domain address 
has to be in [IP:port] format
Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_domain_address: invalid TLS domain 
address [*]
Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_match_addresses: Failed to parse 
address filter: *
Sep 10 20:19:07 [5987] ERROR:tls_mgm:tlsp_set_match_addr: Failed to parse 
domain matching filters for domain [default]
Sep 10 20:19:07 [5987] CRITICAL:core:yyerror: parse error in config file o.cfg, 
line 132, column 20-21: Parameter  not found in module 
 - can't set
Sep 10 20:19:07 [5987] ERROR:core:main: bad config file (1 errors)
Sep 10 20:19:07 [5987] NOTICE:core:main: Exiting


According to the documentation * should be accepted. Is this a bug in parsing 
or is the documentation wrong?


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

[OpenSIPS-Users] sip tracing of locally generated methods

[Dan Pascu]

If one initiates a sip trace for a dialog, are the locally generated requests 
(like for example locally generated BYEs), automatically included in the trace?

--
Dan





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

Re: [OpenSIPS-Users] AG Project - Media Proxy

[Dan Pascu]

The log suggests that the mediaproxy dispatcher is not replying in time, yet it 
is not dead/frozen.
The timeout is 500ms and can be set through the mediaproxy_timeout module 
parameter (see the mediaproxy module README for more info).

I suggest you increase the timeout until you don't see the problem again, but 
keep in mind that whatever value you use, that is how long the opensips worker 
process can be blocked waiting for a reply, during which time it cannot do 
anything else (communication with the dispatcher is not asynchronous).

Better would be to identify what causes the dispatcher to lag like that (maybe 
over time you got an increasing number of call setups which resulted in a 
higher load that makes the dispatcher take more than 500ms to reply sometimes). 
In that case it would be better to consider some horizontal scaling and use 
some clustering solution to distribute the load.

P.S. subsequent calls work, because opensips reconnects automatically to the 
dispatcher as needed.

On 24 Jul 2018, at 14:56, Alex Tatham wrote:

> Hello everyone,
>  
> We have been using AG Projects Media Proxy for several years.  Recently we’ve 
> been experiencing intermittent problems with calls not being initiated and 
> we’ve traced this to the media proxy component.
>  
> The frequency of the issue is around 1 in 2000 calls.
>  
> The following error is logged by the SIP proxy “ERROR: mediaproxy 
> [mediaproxy.c:1528]: send_command(): did timeout waiting for an answer”.
>  
> The following error corresponds in the dispatcher component of the Media 
> Proxy software “Connection to OpenSIPS lost: Connection was closed cleanly.”.
>  
> The problem is temporary and subsequent calls are successful without any 
> intervention.
>  
> I can’t find any information on the WWW about either of these messages.
>  
> The mediaproxy components are running the latest debian packages as is the 
> corresponding module.  I do have some older servers running a much older 
> version of mediaproxy that don’t have this fault but I’ve got to update 
> because of a bug with the relay component on that build.
>  
> Does anyone have any suggestions.
>  
> Thanks, Alex
> Alex Tatham​
> Technical Director
> ​
> T:01233 220 943
> E:alex.tat...@dmcplc.co.uk
> W:www.dmctechnologies.co.uk
>  
> DMC Technologies   formerly HP Technology
> Unit 5, Invicta Business Centre
>  | 
> Orbital Park
>  | 
> Ashford
>  | 
> Kent   | 
> TN24 0HB
> 
> DMC Technologies is a trading name of Hobbs Parker 2000 Limited 
> Registered Office: Romney House, Orbital Park, Monument Way, Ashford TN24 0HB
> Registered in England No.04027755
> 
> 
> ___
> 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] Mediaproxy and Debian 8.11

[Dan Pascu]

Your problem is that you mix debian 8.11 (jessie) with ag-projects' debian 
unstable repositories.

Change your ag-projects repositories to read 'jessie main' instead of 'unstable 
main', rerun apt-get update and it should work.

You might also consider adding the jessie-backports repository:

deb http://ftp.it.debian.org/debian/ jessie-bakcports main
deb-src http://ftp.it.debian.org/debian/ jessie-bakcports main

Some of our software needs newer versions of some packages that are only 
available in the jessie-backports repository (not sure if mediaproxy is one of 
them, but others like blink or sipsimple are).

On 24 Jul 2018, at 13:48, Simone Sestini wrote:

> Hi,
> 
> only the standard and official repository here..
> 
> ---
> deb http://ftp.it.debian.org/debian/ jessie main
> deb-src http://ftp.it.debian.org/debian/ jessie main
> 
> deb http://security.debian.org/ jessie/updates main
> deb-src http://security.debian.org/ jessie/updates main
> 
> # jessie-updates, previously known as 'volatile'
> deb http://ftp.it.debian.org/debian/ jessie-updates main
> deb-src http://ftp.it.debian.org/debian/ jessie-updates main
> 
> # AG Projects software
> deb http://ag-projects.com/debian unstable main
> deb-src http://ag-projects.com/debian unstable main
> 
> ---
> 
> and here the output for the  policy you requested.
> 
> test-rtp:~# apt-cache policy iptables mediaproxy-common
> iptables:
>   Installato: 1.4.21-2+b1
>   Candidato:  1.4.21-2+b1
>   Tabella versione:
>  *** 1.4.21-2+b1 0
> 500 http://ftp.it.debian.org/debian/ jessie/main amd64 Packages
> 100 /var/lib/dpkg/status
> mediaproxy-common:
>   Installato: (nessuno)
>   Candidato:  2.6.6
>   Tabella versione:
>  2.6.6 0
>     500 http://ag-projects.com/debian/ unstable/main amd64 Packages
> 
> 
> Thanks
> 
> 
> Il 24/07/18 12:32, Dan Pascu ha scritto:
>> Please paste apt's sources list (you can delete private repositories if you 
>> have any, I only want to see debian's and ag-projects' repositories). 
>> Alternatively you can paste the output from
>> 
>> apt-cache policy iptables mediaproxy-common
>> 
>> On 24 Jul 2018, at 12:20, Simone Sestini wrote:
>> 
>>> Dear list..
>>> 
>>> I'm trying to install mediaproxy software on Debian 8.11.
>>> 
>>> I'm looking around for a solution.. because i'm receiving
>>> test-rtp:/# apt-get install mediaproxy-common  mediaproxy-relay 
>>> mediaproxy-web-sessions
>>> Lettura elenco dei pacchetti... Fatto
>>> Generazione albero delle dipendenze
>>> Lettura informazioni sullo stato... Fatto
>>> Alcuni pacchetti non possono essere installati. Questo può voler dire
>>> che è stata richiesta una situazione impossibile oppure, se si sta
>>> usando una distribuzione in sviluppo, che alcuni pacchetti richiesti
>>> non sono ancora stati creati o sono stati rimossi da Incoming.
>>> Le seguenti informazioni possono aiutare a risolvere la situazione:
>>> 
>>> I seguenti pacchetti hanno dipendenze non soddisfatte:
>>>  mediaproxy-common : Dipende: libiptc0 ma non è installabile
>>> E: Impossibile correggere i problemi, ci sono pacchetti danneggiati 
>>> bloccati.
>>> test-rtp:/#
>>> 
>>> Praticaly mediaproxy-common depend of libiptc0 but it's not found on debian.
>>> 
>>> The only lib exist are
>>> lrwxrwxrwx 1 root root   16 nov  8  2014 /lib/libiptc.so -> libiptc.so.0.0.0
>>> lrwxrwxrwx 1 root root   16 nov  8  2014 /lib/libiptc.so.0 -> 
>>> libiptc.so.0.0.0
>>> -rw-r--r-- 1 root root 5816 nov  8  2014 /lib/libiptc.so.0.0.0
>>> 
>>> and i tried to add libiptc0 links too but it dosn't fix..
>>> 
>>> lrwxrwxrwx 1 root root   16 lug 23 12:49 /lib/libiptc0.so -> 
>>> libiptc.so.0.0.0
>>> lrwxrwxrwx 1 root root   16 lug 23 12:50 /lib/libiptc0.so.0 -> 
>>> libiptc.so.0.0.0
>>> 
>>> Any idea ?
>>> 
>>> Regards
>>> ___
>>> 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
> 
> 
> ___
> 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] Mediaproxy and Debian 8.11

[Dan Pascu]

Please paste apt's sources list (you can delete private repositories if you 
have any, I only want to see debian's and ag-projects' repositories). 
Alternatively you can paste the output from

apt-cache policy iptables mediaproxy-common

On 24 Jul 2018, at 12:20, Simone Sestini wrote:

> Dear list..
> 
> I'm trying to install mediaproxy software on Debian 8.11.
> 
> I'm looking around for a solution.. because i'm receiving 
> test-rtp:/# apt-get install mediaproxy-common  mediaproxy-relay 
> mediaproxy-web-sessions 
> Lettura elenco dei pacchetti... Fatto
> Generazione albero delle dipendenze   
> Lettura informazioni sullo stato... Fatto
> Alcuni pacchetti non possono essere installati. Questo può voler dire
> che è stata richiesta una situazione impossibile oppure, se si sta
> usando una distribuzione in sviluppo, che alcuni pacchetti richiesti
> non sono ancora stati creati o sono stati rimossi da Incoming.
> Le seguenti informazioni possono aiutare a risolvere la situazione:
> 
> I seguenti pacchetti hanno dipendenze non soddisfatte:
>  mediaproxy-common : Dipende: libiptc0 ma non è installabile
> E: Impossibile correggere i problemi, ci sono pacchetti danneggiati bloccati.
> test-rtp:/# 
> 
> Praticaly mediaproxy-common depend of libiptc0 but it's not found on debian.
> 
> The only lib exist are 
> lrwxrwxrwx 1 root root   16 nov  8  2014 /lib/libiptc.so -> libiptc.so.0.0.0
> lrwxrwxrwx 1 root root   16 nov  8  2014 /lib/libiptc.so.0 -> libiptc.so.0.0.0
> -rw-r--r-- 1 root root 5816 nov  8  2014 /lib/libiptc.so.0.0.0
> 
> and i tried to add libiptc0 links too but it dosn't fix..
> 
> lrwxrwxrwx 1 root root   16 lug 23 12:49 /lib/libiptc0.so -> libiptc.so.0.0.0
> lrwxrwxrwx 1 root root   16 lug 23 12:50 /lib/libiptc0.so.0 -> 
> libiptc.so.0.0.0
> 
> Any idea ?
> 
> Regards
> ___
> 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] Issue with shipped TLS certs in mediaproxy

[Dan Pascu]

On 29 May 2018, at 20:47, Dan Pascu wrote:

> We will provide new ones in the next release. Until then follow tls/README 
> that describes how to generate your own.

I've also renewed the ones in the darcs/github repositories, so you can also 
fetch them from there until the next release. I'd recommend you generate your 
own though.

--
Dan





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

Re: [OpenSIPS-Users] Issue with shipped TLS certs in mediaproxy

[Dan Pascu]

We will provide new ones in the next release. Until then follow tls/README that 
describes how to generate your own.

On a side note, we do NOT recommend anyone uses the certificates shipped with 
mediaproxy for anything other than testing. At least not if you care about 
security.

On 29 May 2018, at 16:24, David Setiadi via Users wrote:

> Testing TLS certs of Mediaproxy shipped in the repo seem to have expired 
> Friday, May 25, 2018. Can anyone supply new ones for testing purposes?
> 
> (ca.pem, crl.pem, dispatcher.crt, dispatcher.key, relay.crt, relay.key)
> 
> Is anyone else having the same issue?
> 
> Thanks in advance!
> 
> 
> ___
> 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] question about rtpbleed and MediaProxy by Ag-Projects

[Dan Pascu]

On 15 Mar 2018, at 9:31, Dan Pascu wrote:

> 
> On 14 Mar 2018, at 18:55, Carlos Oliva wrote:
> 
>> Hi!
>> 
>> Many thanks Bodgan and Dan for the analysis.
>> 
>> I made some attack tests in our MediaProxy installation and this 
>> impersonation is possible, but very difficult to success. You must be 
>> quicker than the legitimate user sending RTP to the right ports. Other 
>> relays are continuously learning the media destination from the last 
>> received packet, it not seems to be the case of MediaProxy. I think is not 
>> needed to be in the signalling path, you can spray the port range of media 
>> relay with packets randomly because send UDP packets is very cheap.
> 
> Mediaproxy is a distributed solution, where you can run multiple media 
> relays. If you are not in the signaling path, you will need to spray multiple 
> IPs and port ranges since you do not know which media relay was chosen. This 
> complicates things because you now have to send a lot of RTP packets before 
> you can trigger the attack, which reduces your chances as this will make you 
> a lot slower.

I just realized something regarding this. It won't really work to spray all the 
ports in the range, because the media relay can be waiting on multiple calls to 
setup, which means that the attacker will end up with multiple RTP streams from 
different calls being forwarded to him and he won't know which is the one he 
wants to hijack. In the end he still needs to be in the signaling path to know 
for sure the IP/port.

> 
>> I used rtpnatscan utility (with few modifications) to do the tests.
>> 
>> I think RTP with NAT involved can not be authenticated in any way, is a 
>> problem of the protocol itself and we can do nothing about that. I agree 
>> with Dan the only thing we can do for privacy is to use SRTP or ZRTP where 
>> possible. 
>> 
>> I only found a possible improvement to MediaProxy. It allocates ports in 
>> consecutive and very predictable way and maybe a future improvement could be 
>> to randomize the selected ports to mitigate the possibility of a successful 
>> attack. Just my 2 cents.
> 
> Not sure how this would help if you spray the whole port range. Besides port 
> allocation is predictable if you have access to the relay, otherwise it 
> depends on all other calls made which are random and out of the attacker's 
> control. Plus the relay doesn't necessarily allocate consecutively. It takes 
> the first available port, which is only consecutive in the beginning after 
> the relay was started. After that, as calls are made and dropped, the 
> available ports will have gaps and holes in them given by the active calls.


Since the attacker needs to be in the signaling path, he will know the IP/port, 
so randomizing doesn't help. A better solution is to have the relay prefer RTP 
packets coming from the signaling IP of the endpoint. The signaling IP of the 
endpoint is already passed onto the relay, but at the moment is not used for 
anything (it was used by mediaproxy 1 to guess the endpoint, since mediaproxy 1 
only listened on a single media port for both endpoints). Using this 
information, the relay can learn the IP from the 1st RTP packet, but if it 
later receives media from the signaling IP it can forget the previous address 
and lock onto the signaling IP. That way if an attacker tries to hijack a 
stream, he will get a few RTP packets from the other endpoint in the beginning, 
until the user sends its own RTP packets from the same IP as the SIP signaling 
and overrides the attacker, cutting him out. This should work for the vast 
majority of users that are behind NAT and only expose users to impersonation 
attacks if their signaling and media come from different IP addresses.

--
Dan





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

Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects

[Dan Pascu]

On 14 Mar 2018, at 18:55, Carlos Oliva wrote:

> Hi!
> 
> Many thanks Bodgan and Dan for the analysis.
> 
> I made some attack tests in our MediaProxy installation and this 
> impersonation is possible, but very difficult to success. You must be quicker 
> than the legitimate user sending RTP to the right ports. Other relays are 
> continuously learning the media destination from the last received packet, it 
> not seems to be the case of MediaProxy. I think is not needed to be in the 
> signalling path, you can spray the port range of media relay with packets 
> randomly because send UDP packets is very cheap.

Mediaproxy is a distributed solution, where you can run multiple media relays. 
If you are not in the signaling path, you will need to spray multiple IPs and 
port ranges since you do not know which media relay was chosen. This 
complicates things because you now have to send a lot of RTP packets before you 
can trigger the attack, which reduces your chances as this will make you a lot 
slower.

> I used rtpnatscan utility (with few modifications) to do the tests.
> 
> I think RTP with NAT involved can not be authenticated in any way, is a 
> problem of the protocol itself and we can do nothing about that. I agree with 
> Dan the only thing we can do for privacy is to use SRTP or ZRTP where 
> possible. 
> 
> I only found a possible improvement to MediaProxy. It allocates ports in 
> consecutive and very predictable way and maybe a future improvement could be 
> to randomize the selected ports to mitigate the possibility of a successful 
> attack. Just my 2 cents.

Not sure how this would help if you spray the whole port range. Besides port 
allocation is predictable if you have access to the relay, otherwise it depends 
on all other calls made which are random and out of the attacker's control. 
Plus the relay doesn't necessarily allocate consecutively. It takes the first 
available port, which is only consecutive in the beginning after the relay was 
started. After that, as calls are made and dropped, the available ports will 
have gaps and holes in them given by the active calls.

--
Dan





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

Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects

[Dan Pascu]

I find the information on that site to be confusing because they lump multiple 
distinct problems under the same name as if they are a single issue. They also 
have some mistakes in their assertions.

So rather than address it from the point of view expressed on the site, let me 
explain what the possible problems are.

Mediaproxy 2 doesn't suffer from eavesdropping issues itself, because it learns 
the addresses of the participants and it will only forward traffic between 
those addresses, not to any listening 3rd party. However eavesdropping is a 
general issue for unencrypted RTP streams because any ISP in the path of those 
packets can listen to them without leaving any trace, no matter what relaying 
solution you use or if you use a relay at all.

Mediaproxy 2 can be affected by impersonation. Because the relay learns the 
addresses of the endpoints from the first RTP packets, if an attacker would 
send RTP first, it would take the place of one of the participants in the call 
and all further RTP traffic will be forwarded to this attacker instead of the 
original participant. This allows the attacker to pretend to be the person he 
tries to impersonate. However unlike the site you mentioned claims, the 
attacker needs to have a privileged position within the network to do so. In 
order for this kind of attack to succeed, the attacker needs to be in the SIP 
signaling path, in order to be able to see the SIP traffic and learn the RTP 
IP/port where to send his packets. The ports allocated by mediaproxy cannot be 
guessed otherwise. In addition to having this privileged position in the 
network, the attacker also need to be closer to the media relay than the 
participant he tries to impersonate, so his RTP traffic reaches the relay first 
and mediaproxy learns the attacker's address before the original participant's 
traffic has a chance to arrive at the relay.

In short impersonation can happen if the attacker can see the SIP traffic and 
learn the media IP/port and is closer to the relay to send its RTP first.

To prevent this you should use TLS for SIP signaling. But keep in mind that 
your SIP service provider and any other SIP service provider involved in the 
calls you make need to use TLS, as well as the other endpoint of the call needs 
to use TLS. Otherwise some SIP traffic will be sent in clear.

To prevent eavesdropping you should use encrypted media, but keep in mind that 
if you use SRTP, unless you use TLS end to end for SIP, the encryption keys 
will be leaked in the SIP signaling.

The best solution you have for both eavesdropping and impersonation is to use 
zRTP for media encryption. Not only it will prevent eavesdropping by encrypting 
the media, but it will also authenticate the other user preventing 
impersonation. If an attacker succeeds in impersonating a RTP endpoint you will 
know that you are not talking to who you expect to be talking. In addition zRTP 
negotiates the encryption in real time, so it doesn't suffer from the same 
problem SRTP suffers with leaked keys, so it works even if you do not use TLS 
for SIP signaling.

Hope this clarifies the subject a bit.

On 12 Mar 2018, at 12:58, Carlos Oliva wrote:

> Hi List:
> 
> I have some questions about mediaproxy 2 ad rtpbleed vulnerability 
> https://www.rtpbleed.com/
> 
> Is MediaProxy 2  vulnerable to this attack?
> 
> If so, the media can be hijacked only at very begining or throughout the 
> entire call? 
> 
> If an attacker hijacks the media the other party will stop hears the call or 
> the RTP will be send to both ends?
> 
> 
> Thanks for your help!
> 
> thanks and Regards,
> 
> Carlos Oliva
> ___
> 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] OpenXCAP on Debian...

[Dan Pascu]

On 6 Dec 2017, at 19:11, Boris via Users wrote:

> I just tried to install OpenXCAP on Debian Stretch and was having issues 
> because of missing dependencies (python-twisted-web2).

It seems debian stretch decided to not ship this package. You can ask them why, 
because the package is present in wheezy (old old stable), jessie (old stable) 
and it is still present in unstable. They just seem to have skipped stretch.

https://packages.debian.org/search?keywords=python-twisted-web2

> I then tried on both Jessie and Wheezy, but each of those were exposing 
> different dependency problems.

You'll most likely need the jessie-backports repository for jessie. I won't 
recommend wheezy as it's too old.

--
Dan





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

Re: [OpenSIPS-Users] MediaProxy Got traffic information for stream

[Dan Pascu]

On 31 Mar 2017, at 17:18, Andreas Bøckmann wrote:

> Hello,
> 
> I am hoping somebody can explain to me how MediaProxy receives "traffic 
> information" from OpenSIPS. 

Mediaproxy doesn't receive traffic information from OpenSIPS. Mediaproxy 
determines endpoint addresses based in received media from endpoints. If you 
see Unknown in those log lines from mediaproxy, it means it has not received 
any RTP/RTCP traffic from that endpoint, so it cannot determine where to 
forward the streams, thus no audio.

> 
> I am trying to use two different GWs to reach PSTN but I am experiencing 
> no-audio using one of them and the only thing I can see that is different is 
> in MediaProxy logs.
> .
> The call flow is similar (late offer).
> 
> --> INVITE
> <- 183/180
> <-  200 OK SDP
> --> ACK SDP
> 
> Got traffic information for stream: (audio) Unknown (RTP: 1.2.3.4:10002, 
> RTCP: Unknown) <-> 2.3.4.5:16388 <-> 2.3.4.5:16390 <-> 4.5.6.7:11390 (RTP: 
> 4.5.6.7:11390, RTCP: 4.5.6.7:11391)
> 
> Got traffic information for stream: (audio) Unknown (RTP: 1.2.3.4:1, 
> RTCP: Unknown) <-> 2.3.4.5:16384 <-> 2.3.4.5:16386 <-> 3.4.5.6:22458 (RTP: 
> Unknown, RTCP: Unknown)
> 
> As I see this MediaProxy has all 3 relevant IPs in both cases; but it's not 
> set in "RTP:" for the call which does not have audio so I am wondering how 
> this can be? 
> 
> What's the missing piece here so that MediaProxy knows "3.4.5.6" is "RTP:" ?
> 
> 
> //Andreas
> ___
> 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] Mediaproxy speed calculations

[Dan Pascu]

On 29 Mar 2017, at 0:02, Daniel Zanutti wrote:

> Hi Dan
> 
> Based on your explanation, my physical machine with 2.8GHz is computing at 
> 5MHz, which is surely wrong.

Not according to the time it took to compute that.

> I have a similar scenario deployed on more than 50 machine and almost every 
> time Mediaproxy is started at linux boot, it doesn't calculate and show 
> speed. After restarting the process, speed is calculated fine.

This is news to me. In all my years of using the software, over dozens of 
servers, I have never encountered this problem.

> Could you please consider that the software may have a bug? Are you 
> interested on fixing it? Can I help?

Sure. But I never run into this and unless I can reproduce it, or get access to 
some system that exhibits it I cannot know what is wrong, or if it's a bug or 
something else.

--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy speed calculations

[Dan Pascu]

On 28 Mar 2017, at 20:55, Daniel Zanutti wrote:

> Hi Dan
> 
> Thanks for answering.
> 
> The machine is not overloaded, actually i have the same problem with 10 calls 
> or 1000 calls.
> 
> Syslog:
> Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed calculation 
> time exceeded 10ms: 15214 us for 418 sessions
> 
> 
> TOP:
> load average: 0.56, 0.61, 0.63

You misunderstood me. I was not talking about your virtual machine, I was 
talking about the real hardware being overloaded, probably running too many 
virtual machines.

From inside the virtual machine you cannot assess how loaded the real hardware 
is. You can have 0% CPU load inside your virtual machine, that doesn't mean 
things are OK. The fact that inside your virtual machine an operation takes 600 
times longer than on 5 years old real hardware, means that your system is 
unable to perform as it should. If the real hardware CPU runs at let's say 
3GHz, this is equivalent to saying that your virtual machine has a CPU running 
at 3000MHz/600 = 5MHz. You try to run a media relay that has to react in real 
time inside a virtual machine that behaves as if it has a 5MHz CPU!

You may prefer to run things on virtual machines for reasons related to costs, 
but at the end of the day one thing is clear: a media relay requires a RTOS. 
Linux running on real hardware is not an RTOS, but if the machine doesn't run 
other things that can influence the resource allocation, it can approximate one 
pretty well. A virtual machine running 600 times slower than real hardware, 
with resources shared between multiple virtual machines, is as far removed from 
the idea of a RTOS as it can possibly be.

> You are right about being virtual, but I'm sure the server is not overloaded 
> because I have the same problem during the night, with almost no traffic. 
> During the day, it MAY be overloaded but surely not during the night and this 
> information never shows up on these relays.
> 
> Is there any way to force it? Could you give some directions?

Force what? As I said the traffic calculations are done periodically at an 
interval specified in the configuration, with the default being 15 seconds. You 
can disable them by setting the sampling interval to 0. The warning doesn't 
mean they are skipped, it only means the relay took too long to compute them 
and was unresponsive for other requests during that time.

> 
> Thanks
> 
> 
> On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu <d...@ag-projects.com> wrote:
> 
> On 24 Mar 2017, at 19:51, Daniel Zanutti wrote:
> 
> > Hi
> >
> > Looks like i'm diving deep on mediaproxy.
> >
> > Some of our relays are not calculating the speed on the network. If I 
> > restart a couple times it starts calculating fine.
> >
> > I found this log:
> > media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 
> > 11644 us for 222 sessions
> >
> > Is there any solution to always calculate?
> 
> The relay always calculates. That is just a warning when it takes too long, 
> but the calculation still took place.
> 
> The reasons why you might not see traffic:
> 
> 1. There is no actual traffic, despite having sessions setup, the devices do 
> not send media
> 2. There is traffic but for some reason reading the traffic information from 
> the kernel fails (I have no idea why that could happen, except maybe a 
> severely overloaded virtual machine - see below)
> 
> I noticed something very wrong with that warning. On a machine running on a 
> Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, but 
> something from 5 years ago), the calculation for 222 sessions, takes 20 us 
> (that is micro seconds). You got 11644 us, which is approximately 600 times 
> slower. Which means your virtual machine is severely overloaded, or the 
> amount of resources it has allocated from the real hardware is abysmal.
> 
> On the same machine I mentioned before, having 2000 active sessions results 
> in the speed calculations taking 170 us, which is well below the warning 
> limit of 10 ms. Which means, the relay can drive thousands of sessions and 
> you'll never see the warning.
> 
> In conclusion, unless you run on a severely overloaded system, or a very 
> underpowered virtual machine, you should never see that warning and seeing 
> the warning doesn't mean that calculations didn't take place.
> 
> --
> Dan
> 
> 
> 
> 
> 
> ___
> 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


--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy speed calculations

[Dan Pascu]

On 24 Mar 2017, at 19:51, Daniel Zanutti wrote:

> Hi
> 
> Looks like i'm diving deep on mediaproxy.
> 
> Some of our relays are not calculating the speed on the network. If I restart 
> a couple times it starts calculating fine.
> 
> I found this log:
> media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 
> 11644 us for 222 sessions
> 
> Is there any solution to always calculate?

The relay always calculates. That is just a warning when it takes too long, but 
the calculation still took place.

The reasons why you might not see traffic:

1. There is no actual traffic, despite having sessions setup, the devices do 
not send media
2. There is traffic but for some reason reading the traffic information from 
the kernel fails (I have no idea why that could happen, except maybe a severely 
overloaded virtual machine - see below)

I noticed something very wrong with that warning. On a machine running on a 
Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, but 
something from 5 years ago), the calculation for 222 sessions, takes 20 us 
(that is micro seconds). You got 11644 us, which is approximately 600 times 
slower. Which means your virtual machine is severely overloaded, or the amount 
of resources it has allocated from the real hardware is abysmal.

On the same machine I mentioned before, having 2000 active sessions results in 
the speed calculations taking 170 us, which is well below the warning limit of 
10 ms. Which means, the relay can drive thousands of sessions and you'll never 
see the warning.

In conclusion, unless you run on a severely overloaded system, or a very 
underpowered virtual machine, you should never see that warning and seeing the 
warning doesn't mean that calculations didn't take place.

--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Dan Pascu]

On 17 Mar 2017, at 3:54, Daniel Zanutti wrote:

> Adrian
> 
> You may be correct, overload can be the problem. But since the call is 
> already finished, how can I remove from the relay?

One way is to issue commands to the dispatcher to end certain sessions, in the 
same way that opensips issues them when it receives a BYE. But this is easier 
said than done, because you will need to find out the call-id , from-tag and 
to-tag of the call in order to do that.

At some point we had the idea to add this kind of functionality to the 
monitoring web page allowing you to click a button next to a call to forcefully 
end it, but it never come to fruition.

The only thing you can do for now is make sure you have at least another relay 
connected to the dispatcher, so it can absorb new calls, the run 
/etc/init.d/media-relay stop-gracefully and wait until this relay has no more 
active traffic, then you can run /etc/init.d/media-relay restart to restart it.

--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Dan Pascu]

On 16 Mar 2017, at 16:22, Daniel Zanutti wrote:

> Hi Dan
> 
> Looks like this problem is only happening on virtual machines, not on 
> physical machines. And only while they are on high load.

We have recommended since forever that people run a media relays on real 
hardware, yet time and again people ignore that and use virtual machines. I 
rest my case.

> 
> But i'm not sure about the kernel rule, is there any way to check it? 

You can check the conntrack rules in /proc/net/ip_conntrack

> 
> Please take a look at this case, this Relay will never halt because there are 
> more than 3k sessions that will never finish internally (the call has already 
> hangup hours ago):

Ok, so that is what you meant by "the relay starts to hangup sessions".

This is something we encountered as well, but not to the extent you mention. In 
our case we have some 30-50 sessions in that state after 1-2 months of usage. 
It seems to always be associated with some network failures where sessions are 
not ended properly. We do not know exactly what causes it and given it's small 
impact for us it was never a priority to debug it. All I know is that it seems 
to be correlated with dialog updates that remove a RTP stream by setting its 
port to 0, without ending the session.

> Is there any way to drop these sessions? Maybe using the internal timeout 
> system of mediaproxy?

Mediaproxy already employs several timeout mechanisms, both of its own as well 
as leveraging the timeout mechanism the linux conntrack implementation provides 
for rules that receive no traffic for a while. The problem is not the lack of 
those, the problem seems to be that under certain conditions which we have not 
yet identified, those timeouts seem to be ignored.

--
Dan





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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Dan Pascu]

On 16 Mar 2017, at 15:58, Daniel Zanutti wrote:

> Hi Dan
> 
> This is exactly how I'm monitoring but looking to the dispatcher it's kind 
> hard on a Nagios like system, because I'm monitoring Relay A, B and C, but 
> the status will be on dispatcher machine D. But ok, if it's the only way.

The relay doesn't listen for network connections, you cannot connect directly 
to a relay. A relay will only connect to all configured dispatchers. The 
dispatcher on the other hand has a control port where you can connect and give 
commands, including fetching statistics from relays over the connections the 
relay already established with the dispatcher.

--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Dan Pascu]

One thing came to mind. A case when the relay could get overloaded is if a lot 
of clients start sessions and only one endpoint sends media. That is the only 
case where the relay would have to deal with the media traffic itself and 
having hundreds of such sessions at the same time could overload the relay.

The way the relay works is for each call it starts listening on 4 ports (2 for 
RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP) and 
initially the relay will just listen on these ports and when it receives data 
it learns the endpoint's address. After it learns both endpoint's addresses, it 
adds a conntrack rule in the kernel to allow the kernel to directly relay the 
media streams between the endpoints and it will never see a media packet from 
the endpoints again until the call ends. This allows for very efficient data 
forwarding because it's done entirely in the kernel with no data being 
transferred from kernel to user-space and back like traditional solutions. We 
have seen media relays handling hundreds of calls at a time with 0% CPU load on 
the relay.

So the only thing I can think of causing something like what you describe (even 
though I'm still not sure what you meant by hanging up sessions), is that 
somehow this process didn't finish setting up completely and the relay directly 
receives media streams from hundreds of devices because only one endpoint sends 
data (or the other endpoint's data gets filtered at some firewall), and because 
it cannot learn both endpoint's addresses it cannot setup the kernel conntrack 
rule to move data forwarding to the kernel.

On 14 Mar 2017, at 13:38, Dan Pascu wrote:

> 
> On 13 Mar 2017, at 18:58, Daniel Zanutti wrote:
> 
>> Hi guys
>> 
>> I sent this email a few days ago, anyone from Mediaproxy team could take a 
>> look? I could debug it, just need some directions on where to look.
> 
> We have never encountered this problem, so I', not sure what to suggest, even 
> more considering that the description is not very clear. What do you mean 
> when you say the relay starts to hang some sessions? That it timeouts on them 
> not having traffic and initiates a BYE for those sessions? Because in the 
> next paragraph you imply that they never timeout.
> 
>> 
>> Thanks
>> 
>> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti <daniel.zanu...@gmail.com> 
>> wrote:
>> I'm using mediaproxy on several installations and have noticed that when the 
>> machine is on high load (> 700 sessions), the media-relay process starts to 
>> hang some sessions.
>> 
>> These sessions doesn't have any RTP being sent/received anymore and they 
>> never hangup. After some hours of frozen sessions, the media-relay process 
>> doesn't connect to the dispatcher anymore, but keep using high CPU on the 
>> machine. Maybe it's on loop internally, not sure.
>> 
>> Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 
>> 4+ hours old).
>> 
>> Thanks
>> 
>> 
>> 
>> ___
>> 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


--
Dan





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

Re: [OpenSIPS-Users] Monitoring Mediaproxy

[Dan Pascu]

Lol, what?!?

On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote:

> SIP Options is used as a “SIP ping”. You likely can have an time event 
> trigger route that can send one and then based on that disable/enable 
> accordingly.  Hopefully mediaproxy will not respond to the “SIP ping” if 
> frozen.
>  
> Robert
>  
> From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Daniel 
> Zanutti
> Sent: Wednesday, March 15, 2017 4:55 PM
> To: OpenSIPS users mailling list 
> Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy
>  
> How can this be done?
>  
> Or do you mean SIP options?
>  
> On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq  wrote:
> Send options.
>  
> On 15 Mar 2017 11:48 PM, "Daniel Zanutti"  wrote:
> Hi
>  
> What's the best way to check if a mediaproxy is running fine? Monit is 
> monitoring PID but how can I check the process has is not frozen?
>  
> Thanks
>  
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
>  
> 
> This e-mail and any files transmitted with it may contain privileged or 
> confidential information. It is solely for use by the individual for whom it 
> is intended, even if addressed incorrectly. If you received this e-mail in 
> error, please notify the sender; do not disclose, copy, distribute, or take 
> any action in reliance on the contents of this information; and delete it 
> from your system. Any other use of this e-mail is prohibited.
> 
> 
> Thank you for your compliance.
> 
> ___
> 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] Monitoring Mediaproxy

[Dan Pascu]

On 15 Mar 2017, at 22:18, Daniel Zanutti wrote:

> Hi
> 
> What's the best way to check if a mediaproxy is running fine? Monit is 
> monitoring PID but how can I check the process has is not frozen?

You can connect to the dispatcher on the control port and issue a statistics 
command that will fetch statistics from all the connected relays. The sample 
media sessions web application included with mediaproxy does that to show the 
active sessions. You can use that or use it as an example of how to do it from 
a monitoring script.

--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Dan Pascu]

On 13 Mar 2017, at 18:58, Daniel Zanutti wrote:

> Hi guys
> 
> I sent this email a few days ago, anyone from Mediaproxy team could take a 
> look? I could debug it, just need some directions on where to look.

We have never encountered this problem, so I', not sure what to suggest, even 
more considering that the description is not very clear. What do you mean when 
you say the relay starts to hang some sessions? That it timeouts on them not 
having traffic and initiates a BYE for those sessions? Because in the next 
paragraph you imply that they never timeout.

> 
> Thanks
> 
> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti  
> wrote:
> I'm using mediaproxy on several installations and have noticed that when the 
> machine is on high load (> 700 sessions), the media-relay process starts to 
> hang some sessions.
> 
> These sessions doesn't have any RTP being sent/received anymore and they 
> never hangup. After some hours of frozen sessions, the media-relay process 
> doesn't connect to the dispatcher anymore, but keep using high CPU on the 
> machine. Maybe it's on loop internally, not sure.
> 
> Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 
> 4+ hours old).
> 
> Thanks
> 
> 
> 
> ___
> 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] Sip trunk and mediaproxy

[Dan Pascu]

On 28 Dec 2016, at 13:37, Saioa Perurena wrote:

> Hello,
> 
> We already have a communications infrastructure composed by 2 opensips
> servers in different domain with 1 mediaproxy each and interconnected by
> a TLS trunk. We managed to interconnect both SIP networks and it does
> work. ICE is also working so when sip clients are in the same network
> then the call goes point to point between caller and callee.
> 
> The problem is when we want to use mediaproxy to relay media, let's say
> when sip clients are in different networks. Each opensips server passes
> its mediaproxy candidate to their clients. So opensips-1 passes
> mediaproxy-1 to client-1 and opensips-2 passes mediaproxy-2 to client-2.
> Then when the call is done client-1 will use mediaproxy-1 and client-2
> will use mediaproxy2 and therefore voice in going on diversion, each
> takes its own way.
> 
> Question: how to deal with this?

Media relays can be chained without problems and automatically, unless they are 
behind NAT or if they have IP addresses in the private ranges (10.x.x.x, 
192.168.x.x, ...)

However it is a bit wasteful to have more than one in the path. One way to deal 
with this is to only engage the media relay on one of the proxies (the 
originator or the destination) if the call goes between users on the same 
platform.

--
Dan





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

Re: [OpenSIPS-Users] Issues with mediaproxy-dispatcher

[Dan Pascu]

This exception cannot happen unless you modified the mediaproxy code yourself 
and made a mistake or if the python interpreter you use is seriously broken 
(unlikely).

On 25 Jun 2015, at 17:26, Koldo Aingeru Marcos Fernández wrote:

 Hi everyone,
 
 we are starting to have some strange issues with mediaproxy. Our setup is 
 kamailio 4.2 + mediaproxy 2.6.1 on CentOS 6.6.
 
 Recently we have two incidents were the communication between the dispatcher 
 and the relays (we got two of them, one in the same server) get lost, digging 
 in the logs we see this:
 
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: session with call_id 
 0bc0a5274d9f0f325e5d975a38ffd...@xxx.xxx.xxx.xxx:5060 from relay 
 AAA.AAA.AAA.AAA did timeout
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: Traceback (most recent call 
 last):
 Jun 25 13:07:22 kamailio media-dispatcher[14459]:   File 
 /usr/lib64/python2.6/site-packages/twisted/internet/posixbase.py, line 614, 
 in _doReadOrWrite
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: why = 
 selectable.doRead()
 Jun 25 13:07:22 kamailio media-dispatcher[14459]:   File 
 /usr/lib64/python2.6/site-packages/gnutls/interfaces/twisted/__init__.py, 
 line 79, in doRead
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: return 
 tcp.Connection.doRead(self)
 Jun 25 13:07:22 kamailio media-dispatcher[14459]:   File 
 /usr/lib64/python2.6/site-packages/twisted/internet/tcp.py, line 214, in 
 doRead
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: return 
 self._dataReceived(data)
 Jun 25 13:07:22 kamailio media-dispatcher[14459]:   File 
 /usr/lib64/python2.6/site-packages/twisted/internet/tcp.py, line 220, in 
 _dataReceived
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: rval = 
 self.protocol.dataReceived(data)
 Jun 25 13:07:22 kamailio media-dispatcher[14459]:   File 
 /usr/lib64/python2.6/site-packages/twisted/protocols/basic.py, line 454, in 
 dataReceived
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: self.lineReceived(line)
 Jun 25 13:07:22 kamailio media-dispatcher[14459]:   File 
 /usr/lib64/python2.6/site-packages/mediaproxy/dispatcher.py, line 239, in 
 lineReceived
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: session.expire_time = 
 time()
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: TypeError: 'module' object 
 is not callable
 Jun 25 13:07:22 kamailio media-dispatcher[14459]: error: Connection with 
 relay at AAA.AAA.AAA.AAA was lost: 'module' object is not callable

--
Dan





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

Re: [OpenSIPS-Users] test engage_media_proxy

[Dan Pascu]

On 4 Aug 2014, at 14:29, Edwin wrote:

 For this reason I rather use the engage_media_proxy.

engage_media_proxy is automatic and as a result it has a default behavior that 
may or may not match your needs. if you need control over the process you need 
to use use_media_proxy and end_media_session and customize their behavior to 
your requirements.

 Maybe a feature request should be made. Something like the return of the ip
 addres from the media relay that answered the request, and -1 if no
 media-relay answered?

when you call engage_media_proxy, it only sets a flag. nothing else happens. it 
cannot give you a negative reply because it doesn't attempt to do anything. 
things will happen later when t_relay is called and by that point is to late to 
get an answer.

--
Dan





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

Re: [OpenSIPS-Users] Mediaproxy relay oddness

[Dan Pascu]

On 23 Jul 2014, at 15:38, Jeff Pyle wrote:

 The ports in use are 16384-32768.  That provides for ~8000 session, yes?

Only ~4000. There are 4 ports allocated per session.

  We were nowhere near that many calls.  So, it's much more likely that ports 
 were not being released for some reason.

--
Dan





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

Re: [OpenSIPS-Users] create mediaproxy certificates

[Dan Pascu]

Thanks for this. We’ll include in the README

On 17 Jul 2014, at 17:41, Edwin eahaselh...@gmail.com wrote:

 Hi Adrian,
 
 I came up with the following commands, which gives me a working set of
 certificates. I only have to take al look how to create the crl.pem (is this
 optional)

crl.pem is optional in the sense that it only comes into play if you have 
revoked certificates and you want them to be rejected if they attempt to 
connect.

 
 If you want you can add this lines to the Readme (after testing). If anyone
 has tips / comment / additions please let me know.

It should be noted that the certificate authority generated by these 
instructions will not be password protected, so if anyone gets ahold of it they 
will be able to generate valid certificates that can connect to your network.

Another note is that if you’d use a passphrase to protect the CA and the 
private keys, the private keys need to be exported without including the 
password, else you need to type the password every time you start mediaproxy.

 
 # Create SSL certificate authority 
 openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout ca.key.pem -out
 ca.pem -subj
 /C=NL/ST=NH/L=Amsterdam/O=DEMOTECH/CN=www.example.com/emailAddress=m...@example.com
 
 # Create private key
 openssl genrsa -out dispatcher.key 2048
 openssl genrsa -out relay.key 2048
 
 # Create certificate request
 openssl req -new -key dispatcher.key -out dispatcher.csr -subj
 /C=NL/ST=NH/L=Amsterdam/O=DEMOTECH/CN=www.example.com/emailAddress=m...@example.com
 openssl req -new -key relay.key -out relay.csr -subj
 /C=NL/ST=NH/L=Amsterdam/O=DEMOTECH/CN=www.example.com/emailAddress=m...@example.com
 
 # Sign request with CA
 openssl x509 -req -days 3650 -in dispatcher.csr -CA ca.pem -CAkey ca.key.pem
 -set_serial 01 -out dispatcher.crt
 openssl x509 -req -days 3650 -in relay.csr -CA ca.pem -CAkey ca.key.pem
 -set_serial 01 -out relay.crt
 
 # Place (only) the ca.pem, dispatcher.crt, dispatcher.key, relay.crt,
 relay.key files in de tls folder...
 
 Cheers,
 
 Edwin
 
 
 
 --
 View this message in context: 
 http://opensips-open-sip-server.1449251.n2.nabble.com/create-mediaproxy-certificates-tp7592419p7592468.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] MediaProxy - db user and privileges

[Dan Pascu]

On 17 Jul 2014, at 18:27, Gary Patton gpatton.pub...@outlook.com wrote:

 Good morning everyone.  Back to learning OpenSIPS 1.11.1 + MediaProxy 2.6.1 
 integration.  As a student, I tend to read installation instructions before 
 attempting the actual installation and I have questions.
 
 The MediaProxy config.ini file has a database section.  The installation docs 
 don't mention installing a database as a prerequisite before installing 
 MediaProxy.

Because it’s not a prerequisite. Database accounting is optional. If you don’t 
define the dburi it will not do accounting for the media.

  Also, the example dburi= references a MySQL server, so I assume I can 
 specify the IP address of MySQL server running on my separate OpenSIPS box 
 and use that instance of MySQL.

The most common use case is to specify the same database opensips is using for 
accounting and even use the same username/password as opensips uses (in case 
you don’t feel like creating a new user specifically for mediaproxy).
The only requirement is that the user has to have the CREATE and ALTER 
privileges on the database. 

 
 Also, the example dburi= parameter specifies a user (mediaproxy), a 
 CHANGEME placeholder for the user's password when the user acceses the db, 
 and a MySQL db name (mediaproxy”).

They are just example. If you use the same database as opensips, then the 
database is most likely opensips.

 
 So, my questions:
 
 (1) It appears that the MediaProxy config.ini file will create the table 
 media_session in the mediaproxy database.  Because I don't see anything 
 in the config.ini file that appears to create the mediaproxy MySQL db, I 
 must first manually create the mediaproxy MySQL db on the OpenSIPS box, 
 correct? 

No. It’s automatically created the first time mediaproxy is run (the dispatcher 
more precisely). If it can’t do it (because you provided a user without enough 
privileges) it will log that it could not do it and print the instructions you 
need to paste into a mysql client to create the table yourself.

 
 (2) And also create the mediaproxy user with all privileges against the 
 mediaproxy database?

or use the opensips database and the opensips user

 
 (3) Or, will executing the DEB repository command apt-get install 
 mediaproxy_dispatcher mediaproxy_common on the OpenSIPS server (the 
 MediaProxy dispatcher) automatically create the required mediaproxy 
 database/user/table?

No. Table is create the first time the dispatcher is run (actually every time 
the dispatcher runs will recreate it if it’s missing)

 
 () Should I also grant the opensips user all privileges against the 
 mediaproxy database?

it needs at cleat CREATE and ALTER

 =
 
 I looked over documentation on the ag-project.com site.  There on the 1st 
 page of the installation guide was this:
 
 MediaProxy must run natively on the host operating system and not in a 
 virtual environment.
 
 Because I'm a student and don't have a spare server (or PC), I had planned on 
 signing up for the free server from Amazon's AWS Free Usage Tier and 
 installing MediaProxy on it.  I expected horrible performance, but I thought 
 it would at least work so I could see how NAT transversal worked in OpenSIPS.

For testing you can run it on whatever you want. the recommendation is for 
production systems that need not be affected by the less precise timing of 
virtual machines.

 
 So, as far as you know, MediaProxy *must* be installed on a physical server?

No, but if you want the best performance out of it it is recommended.

  Especially since the config.ini file mentions something about the relay 
 being being NAT but is mapped to a public IP address like in Amazon EC2.
 
 Or can it be installed on a virtual machine but it will have really bad 
 performance?  (I wonder if it's the same for VMware / Rackspace / Azure / . . 
 .  I can accept poor performance - especially with the free AWS server - as 
 long as it still works!
 
 Thanks to everyone for their patience and for helping me trying to understand 
 how OpenSIPS and MediaProxy interact!
 
 Regards,
 
 Gary
 ___
 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] MediaProxy - db user and privileges

[Dan Pascu]

On 18 Jul 2014, at 15:43, Dan Pascu d...@ag-projects.com wrote:

 
 () Should I also grant the opensips user all privileges against the 
 mediaproxy database?
 
 it needs at cleat CREATE and ALTER

it needs at least CREATE and ALTER (sorry for the typo)
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] create mediaproxy certificates

[Dan Pascu]

On 15 Jul 2014, at 22:55, Edwin eahaselh...@gmail.com wrote:

 Hi Adrian,
 
 I already did, but still don't get it (I know to google before asking). I
 really don't know what to do in what order (even after reading the readme
 and the openssl site a lot of times). 
 
 I hope someone will just give an exampe (why not?)

Because none of the people involved with writing that mediaproxy documentation 
have ever used openssl to generate certificates and no one knows the sequence 
of commands you need to run of the top of their head. We found the process of 
generating certificates in the command line with openssl to be unnecessarily 
complicated and we didn’t brother to learn/document it. That’s why we provided 
a way to do it using a program that wraps openssl and hides the complicated 
details in a few easy steps in a friendly GUI.

As mentioned before the program is still available in debian/ubuntu and if you 
run a distro that doesn’t have it packaged, you can still find it here:

https://github.com/warewolf/tinyca2

If for whatever reason you do not want to do it the way it is documented but 
prefer to do it with openssl commands directly, you have to either figure it 
out yourself, or wait for someone that has the knowledge to come along and 
answer your question, because we do not have the answer/example you are looking 
for. However, if you figure it out, I’d be more than happy to include the 
description of generating certificates using openssl into the documentation.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] create mediaproxy certificates

[Dan Pascu]

On 15 Jul 2014, at 20:51, Edwin eahaselh...@gmail.com wrote:

 Hi Saúl,
 
 In fact I have installed opensips and mediaproxy-dispatcher on Debian and
 the mediaproxy-relay on two other Debian servers. But tinyca2 had to run on
 a server with a Gui (like KDE or Gnome), which I (rather) don't run.

tinyca doesn’t need to run on the server. you can run it on any desktop 
computer that already has a GUI.



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

Re: [OpenSIPS-Users] mediaproxy-relay: kernel version problem

[Dan Pascu]

On 6 Nov 2013, at 1:17, steph...@shimaore.net wrote:

 Hello,
 
 I've been using mediaproxy for years without issues, but recently
 encountered a problem when upgrading kernel version on Debian.
 
 In recent Debian versions, /proc/sys/kernel/osrelease
 (KERNEL_VERSION_FILE in media-relay) looks for example this way:
 
$ cat /proc/sys/kernel/osrelease 
3.10-3-amd64

This is how it was forever. I have older machines with 2.6.x and they show up 
the same:

$ cat /proc/sys/kernel/osrelease
2.6.32-3-686

 which doesn't match the format expected by the script (and causes
 media-relay to fail at startup).

Actually this is the format the script expected since I remember it. Mediaproxy 
detects the kernel version fine both on older and newer debian systems as I do 
not see any difference in the format.

 
 It seems odd that we would rely on the various distributions to gather
 the kernel version, when we could use /proc/sys/kernel/version
 
$ cat /proc/sys/kernel/version 
#1 SMP Debian 3.10.11-1 (2013-09-10)

Unfortunately that is not the kernel version and the fact that in your case the 
kernel version is tucked in there is a matter of coincidence. I have 2 
machines, one with 2.6.x and one with 3.x that don't have it in there (both 
Debian BTW, so it seems that it is not present in there even if you use the 
same distribution):

machine1:~$ cat /proc/sys/kernel/osrelease
2.6.32-3-686
machine1:~$ cat /proc/sys/kernel/version
#1 SMP Thu Feb 25 06:14:20 UTC 2010

machine2:~$ cat /proc/sys/kernel/osrelease
3.2.0-0.bpo.2-686-pae
machine2:~$ cat /proc/sys/kernel/version
#1 SMP Sun Jun 3 22:21:19 UTC 2012

Also, while something resembling the kernel version seems to be there, it 
doesn't match the actual kernel version (this is from another Debian system):

machine3:~$ cat /proc/sys/kernel/osrelease
3.10-3-686-pae
machine3:~$ cat /proc/sys/kernel/version
#1 SMP Debian 3.10.11-1 (2013-09-10)
machine3:~$ uname -r
3.10-3-686-pae

As you can see, the file has 3.10.11-1 tucked in there, but the actual kernel 
version is 3.10-3 (as reported by both the osrelease file and uname -r). 

So we can conclude that /proc/sys/kernel/version is pretty much useless in 
determining the kernel version.

 which I assume contains the proper value

Not even (see the last example above).

 (although maybe in a
 not-so-stable format).
 
 I'm proposing the changes described here
  https://gist.github.com/shimaore/7328080
 (which first try to use the current method, then fallback to using
 kernel/version) for consideration  integration by AG Projects.

By looking at your patch, I believe I have an idea why it doesn't work for you. 
Are you using stock mediaproxy version 2.5.2? Because your patch suggests 
otherwise. This change, proposed by the patch:

 try:
-major, minor, revision = [int(num) for num in 
open(KERNEL_VERSION_FILE).read().split( , 1)[3].split(.)[:3]]
+major, minor, revision = [int(num) for num in 
open(OS_RELEASE_FILE).read().split(-, 1)[0].split(.)[:3]]
 except:

indicates that you try to replace this line from the original version:

major, minor, revision = [int(num) for num in 
open(KERNEL_VERSION_FILE).read().split( , 1)[3].split(.)[:3]]

however that line is not present in that form in stock mediaproxy-2.5.2. The 
actual line in our version is:

major, minor, revision = [int(num) for num in 
open(KERNEL_VERSION_FILE).read().split(-, 1)[0].split(.)[:3]]

which is exactly what you try to change it to.

So if the source you try to change looks like in your patch, there is no wonder 
it doesn't work as that form cannot parse the output from osrelease.

So I suggest you try out stock mediaproxy 2.5.2 without any alterations or use 
the latest version from the darcs repository and see if the problem persists. 
If it does, please post the output from the osrelease file and the backtrace so 
we can take a look at what's different. Currently I'm running the latest kernel 
from debian unstable and nothing has changed in the format of that file.

--
Dan





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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

[Dan Pascu]

On 1 Nov 2012, at 13:02, Bogdan-Andrei Iancu wrote:

 Hi Dan,
 
 Well, as Ovidiu said, it is prone. BUT, this is not something particular to 
 re-INVITE, but to whatever
 in-dialog pinging you may have from a mid-proxy.

I never said otherwise.

 On the other hand, as Ryan pointed out here, the need to check the dialog 
 health from proxy side, without relying on special end-UA features (like 
 SST), is really critical.

While it may be useful (I would not call it exactly critical), this doesn't 
mean that the implementation should introduce new issues. I'm not arguing 
against the idea of having a keep-alive mechanism here, but against particular 
implementations that introduce new issues.

 So, I see two approaches:
1) either simply live with the fact that races may occure and calls may be 
 dropped during a re-INVITE, but at least is a clear drop /cut

I'm not sure you can explain your customers that their calls are being dropped 
because you have a race condition in your implementation which you are willing 
to live with...

2) theoretically we can try to address the race at dialog modules level : 
 (a) If you have ongoing in-dialog transaction, do not do your ping ,

This was never the issue. You can always avoid this.

 (b) if you have an ongoing in-dialog ping and receive another in-dilog 
 request from end point, try to delay it until your pinging is done.

This should work, but I don't see it working without a proper async reactor 
model. How do you plan to delay it, without blocking the worker?

On another note, I also believe that a re-INVITE based keep-alive is also 
problematic because it has to implement the whole stream selection mechanism in 
the clients in order to know what streams to propose in the re-INVITE. Even so, 
triggering a SDP renegotiation every now and then is not very nice, regardless 
of it changing nothing in the streams.

--
Dan





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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

[Dan Pascu]

On 3 Nov 2012, at 7:39, Binan AL Halabi wrote:

 Hi ALL,
 
 According to 14.1 and 14.2 of RFC 3261 after receiving 491 the UAC will retry 
 again after 2.1-4.0 seconds if it owns the CALL-ID or 0.0.-2.0 if not.

While the RFC may provide a means to handle this, it's non-practical. When I 
put a call on hold, I don't want to send my voice over for another 4 seconds.

I think we're losing sight here of the fact that a keep-alive mechanism should 
not make the user experience worse. This should be tailored to preserve the 
client's experience while adding the new feature, not to make it right for 
OpenSIPs and screw the clients.

 So 
 If UAS have an ongoing in-dialog ping and receive another one let it send 491 
 and drop the request (the end point will retry it later).

Well good luck with clients acting properly when they receive the 491...

--
Dan





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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

[Dan Pascu]

On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote:

 Hi Saul,
 
 We were thinking at re-INVITE pinging from OpenSIPs level towards the caller 
 and callee. There will be 2 modes (at least this is the current plan).
1) remember all the time the last SDPs from each side and re-use them when 
 pining the other sides (just to trick the SDP negotiation)
2) start with a lateSDP negotiation on one side and do normal SDP on the 
 other side (to avoid SDP storing), but this means at least one of the parties 
 should support late SDP negotiations
3) open to other suggestions

I think this invites trouble as it is prone to race conditions. If any of the 
clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it 
will fail as there is already an active unanswered re-INVITE in progress. The 
client will be confused as it didn't send another re-INVITE itself and the 
negative reply to its own re-INVITE will probably just prompt the client to 
terminate the session thinking there is some issue with it.

I cannot see this working without a full B2BUA, where OpenSIPs would queue the 
client requests if there is a ping in progress and only forward them after it 
has finished the ping transaction.

 
 About the GRUU stuff, could you detail a bit :D ?
 
 Regards,
 
 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com
 
 
 On 10/26/2012 06:51 PM, Saúl Ibarra Corretgé wrote:
 Hi,
 
 On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote:
 
 Hi all,
 
 I would like to start a discussion about the next OpenSIPS major release - 
 and in this discussion anyone is welcomed with options, ideas, critics and 
 other. Your feedback is important to drive the project into a direction 
 that reflects the user's needs!.
 
 So, I will here the starting points, for both release planing and release 
 content.
 
 
 Content
 ---
 What was done:
http://www.opensips.org/Main/Ver190#toc2
 What is planned:
http://www.opensips.org/Main/Ver190#toc9
 Planned items have priorities (for being addressed); it is a must to have 
 all items done for the next release, as we need to fit into a time frame. 
 Whatever is not done, will be left for the next release (1.10)
 
 
 Planing
 ---
 Release candidate:
second half of January 2012, depending on the progress with the items to 
 be done.
 Testing phase:
1 month allocated (it may be extended if critical problems show up)
 Stable release:
second half of February (after the testing phase is done).
 
 
 Once again, your feedback on these matters is important to us.
 
 I'll edit the wiki with the items we've been working on for presence.
 
 Can you give a bit more detail on the dialog ping with re-INVITEs? 
 re-INVITEs are particularly troublesome, because there can only be one of 
 them at a time.
 
 Also, can we add the in-dialog requests when using GRUU bug to the wishlist? 
 :-)
 
 Keep up the good work guys!
 
 
 Regards,
 
 --
 Saúl Ibarra Corretgé
 AG Projects
 
 
 
 
 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
 
 
 ___
 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] MediaProxy one-way-audio oddity

[Dan Pascu]

According to the debug output, it seems that your Gridborg device is not 
sending any media packets to the relay. The last 2 entries from the media relay 
log, indicate that the callee (200.200.200.200) has sent both a RTP and a RTCP 
packet resulting in its addresses being discovered by mediaproxy, however no 
packet was received from the caller side, so mediaproxy doesn't know the caller 
media addresses, thus it can't forward the media because it doesn't know where 
to.

debug: Got initial answer from callee for stream: (audio) 10.10.101.101:20752 
(RTP: Unknown, RTCP: Unknown) - 100.100.100.100:50020 - 
100.100.100.100:50022 - 200.200.200.200:13320 (RTP: Unknown, RTCP: Unknown)
debug: Got traffic information for stream: (audio) 10.10.101.101:20752 (RTP: 
Unknown, RTCP: Unknown) - 100.100.100.100:50020 - 100.100.100.100:50022 - 
200.200.200.200:13320 (RTP: 200.200.200.200:13320, RTCP: Unknown)
debug: Got traffic information for stream: (audio) 10.10.101.101:20752 (RTP: 
Unknown, RTCP: Unknown) - 100.100.100.100:50020 - 100.100.100.100:50022 - 
200.200.200.200:13320 (RTP: 200.200.200.200:13320, RTCP: 200.200.200.200:13321)

Initially mediaproxy doesn't know the address of neither endpoint (all show 
Unknown). Then the callee sends a RTP packet followed by a RTCP packet and you 
can see in the log as the addresses become known. Yet the caller addresses 
remain Unknown because it has never sent a packet to the relay.

I'd look for the problem in the device itself or the router that does the NAT 
traversal for the device. Your server side configurations are fine.

On 20 Jan 2012, at 0:02, Jock McKechnie wrote:

 Greetings;
 
 I've been deploying OpenSIPS (v1.7.0) and MediaProxy (from git) a lot
 lately (huzzah for reliable and flexible software) and have been
 having a great time... until today, and naturally, this system is the
 one that I have my colleagues breathing down my neck on.
 
 Gridborg - OpenSIPS + MediaProxy - Client
 
 Signalling works perfectly. Call comes up normally, call tears down
 normally. However when audio comes _back_ from the client it gets to
 MediaProxy and is not passed on to gridborg.
 
 From the MediaProxy debugging I believe that MP isn't able to
 determine the RTP port on the gridborg system and so cannot pass the
 audio back, but I've been staring at the signalling all day long and I
 just can't work out why not. I have several other systems doing this
 (gridborg - OpenSIPS+MediaProxy) without issue, AND if I use
 something more conventional (Asterisk) it seems to work just fine,
 although this may be a false symptom.
 
 I could really, really use some help. I've included everything I could
 think of trapping, if you think I should find something else, let me
 know and I'll reproduce.
 
 10.10.101.101 is the gridborg system,
 100.100.100.100 is the public IP of the OpenSIPS+MediaProxy server,
 200.200.200.200 is the public IP of the client system.
 We're sending the call to (123) 456-7890.
 (Obviously I've audited the trace/configs to put these addresses in,
 but that's the only editing)
 
 OpenSIPS config:
 http://pastebin.com/YvRyuJjZ
 
 MediaProxy config:
 http://pastebin.com/QjYUzJpp
 
 SIP trace:
 http://pastebin.com/d1f9MxPA
 
 MediaProxy debug:
 http://pastebin.com/PLGNhnR9
 
 My deepest thanks to anyone who can shed light on this;
 
 - Jock
 
 ___
 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] MediaProxy + OpenSIPS Integration

[Dan Pascu]

The reason for the recommendation not to install in a VM, is the fact that 
media relaying requires accurate timing in order to work well and a VM is prone 
to have timing accuracy issues.

Otherwise it'll work, but if the VM cannot forward the packets as they arrive, 
it'll introduce jitter in the RTP streams which will be reflected in the 
quality of the audio.

On 1 Dec 2011, at 5:17, Nick Khamis wrote:

 Hello Everyone,
 
 We have been successful so far with our virutal machine prototpe:
 
 2 VM for HA Mysql
 2 VM for Asterisk
 2 VM for OpenSIPS (in/out)
 
 Now we would like to iinclude MediaProxy with the OpenSIPS-in VM
 however, the webiste mentioned not to install MediaProxy on a VM?
 This is just a protoype, and will be installed on the host once the entire
 architecture is complete, configs etc..
 We want to compile it from source. Do you feel this will be a problem,
 and not function as expected? Good documentation from install to
 configuration of MediaProxy + OpenSIPS would be greatly appreciated.
 
 Thanks in Advnace,
 
 Nick.
 
 ___
 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] Opensips-mi-proxy unable to start

[Dan Pascu]

The MI proxy needs to be adapted to some code changes in pyhton-application and 
it'll work in the next release. Use an older version of python-application for 
the time being (1.2.7 will do).

use

darcs get --to-patch release-1.2.7 
http://devel.ag-projects.com/repositories/python-application

to get python-application version 1.2.7


On 9 Jun 2011, at 16:16, Nethra Chander wrote:

 Hi,
 
 I am unable to start opensips-mi-proxy module successfully.
 
 The logs below:
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: Starting OpenSIPS 
 MI Proxy 1.0.4
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: error: Traceback 
 (most recent call last):
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: error:   File 
 /usr/bin/opensips-mi-proxy, line 59, in module
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: error: from 
 miproxy.proxy import MIProxy
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: error:   File 
 /usr/lib/python2.5/site-packages/miproxy/proxy.py, line 12, in module
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: error: from 
 application.system import default_host_ip
 Jun  9 13:09:38 ip-10-56-67-103 opensips-mi-proxy[16278]: error: ImportError: 
 cannot import name default_host_ip
 
 Please assist as to how I can resolve the issue above.
 
 I installed python-application from the repositories using darcs get 
 http://devel.ag-projects.com/repositories/python-application
 while opensips-mi-proxy is installed from the tar archive. Not sure if this 
 has something to do with the error reported.
 
 Appreciate any help.
 
 
 
 
 
 ___
 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] media-dispatcher and media relay connection problem

[Dan Pascu]

On 26 May 2011, at 11:14, Barsan Liviu wrote:

 Hi,
 
 With the python-gnutls update to 1.2.1 the mediaproxy works fine.
 A suggestion: would be welcome a minimal install guide for Ubuntu/Debian,

apt-get install mediaproxy-relay ;)

If this is too terse to qualify as 'minimal', then the INSTALL file in the 
project explains in a step-by-step fashion, what you need to do to install it 
on debian. It also explains how to install it from source. I take you did read 
that file, but it didn't qualify as a minimal guide for you?

 for example I spent several days until I find out that iptables should be 
 loaded before starting media-relay.

Manually loading it is not necessary. The media-relay startup script takes care 
of loading it for you. The only case where this doesn't apply is if you do not 
use the debian packages and/or try to manually start the relay without using 
the provided init script, but for that case the INSTALL file tells you to use 
the debian startup scripts as examples and they load the iptables module before 
starting the relay.

I'm not quite sure what do you mean when you say you want a debian/ubuntu 
installation guide, yet you do not seem to be using the debian/ubuntu packages 
because you run into issues that are automatically solved for you when you 
install the debian packages (automatic dependency handling, init script already 
properly setting up the environment, ...)

--
Dan





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

Re: [OpenSIPS-Users] when engage_media_proxy() doesn't

[Dan Pascu]

On 23 Mar 2011, at 16:28, Jeff Pyle wrote:

 Ok, Dan.  Great info.  All Opensips and Mediaproxy packages were installed
 from their respective apt repositories.  The opportunity for code
 modification is minimal.

I meant since the feature to create dialogs early from the script was added, 
which was a while back.

--
Dan





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

Re: [OpenSIPS-Users] when engage_media_proxy() doesn't

[Dan Pascu]

On 16 Mar 2011, at 23:14, Jeff Pyle wrote:

 I took a stab at the non-automagic method with
 use_media_proxy()/end_media_session(). So far I've got just a first
 attempt using them, but it works well enough to get to get the media
 stream through the relay.
 
 What would cause engage_media_relay() to silently fail, but
 use_media_proxy() to work?
 
 I have verified there is a create_dialog() in the script before
 engage_media_relay() was called.  In fact all other dialog-related
 activity are okay.

It will not work like that (if the dialog is created before engage_media_proxy 
is called). When you call engage_media_proxy it will set the dialog flag (so 
that the dialog module will trace the call) and also sets another flag on the 
message to indicate that a media relay needs to be used. Later when the dialog 
is created, it will find this flag and register the callbacks to process the 
dialog messages. If you created the dialog prior to calling engage_media_proxy, 
the moment when it would have find the flag and registered the callbacks is 
already past. In other words, unless you have an explicit need to crate the 
dialog early, don't. By simply invoking engage_media_proxy, a dialog will be 
created for you (it automatically sets the dialog flag).

--
Dan





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

Re: [OpenSIPS-Users] multiple use_media_proxy() calls

[Dan Pascu]

On 25 Jan 2011, at 15:35, Jeff Pyle wrote:

 Or, perhaps something already available in the code to force a reset of
 some sorts when the 18x w/ SDP message comes back?  By this point, the
 leaky media has stopped and the legit media is flowing.
 
 I don't think this is your case, because the relay already handles this.
 it will reset it's knowledge of the learnt addresses with every
 request/reply in dialog. So when the 2nd 183 comes in, it does reset the
 ports and attempts to relearn them. If things would be as you describe
 them (1st media stream has stopped when the 2nd 183 comes), then it
 should simply work because the relay would reset and learn the ports from
 the 2nd media stream. But I suspect that the 1st media stream still flows
 a bit past the 2nd 183 and the relay locks onto that again instead of
 locking on the 2nd media stream (that probably comes only after it
 re-locked to the 1st). Otherwise I cannot explain why it wouldn't work
 for you as the relay relearns the addresses after every 183/200
 
 Here's the thing:  there is only one 183, not two.
 
 The carrier sends only a 100, then some of this leaky media as I am
 calling it.  I think the term leaky fits because it arrives outside of
 any SDP.  The relay locks onto this media.  By the time the carrier does
 send the 183 (and SDP), the leaky media has stopped and the legit media
 has started.  But, since there is only one 183, it appears the relay
 doesn't have an opportunity to reset.  There is only one stream at a time.

Then there is some misunderstanding somewhere. Before the first 183 arrives, 
mediaproxy cannot lock onto anything as it doesn't yet have information about 
both endpoints. It needs a request (INVITE) and a reply that carries media 
(183/200), before it can even begin to listen to packets. So how can it lock to 
media before even allocating the ports and listening is beyond me.

 
 We have examined the Mediaproxy accounting records after the fact.  They
 show the port on the carrier-side as the one from the leaky media, not the
 one from the SDP.  For some reason the relay does not reset at 200 OK time.

I checked the code and it does reset on any new request/reply.

 
 This is on Mediaproxy 2.3.8, as far as we can go on CentOS with the Python

Hmm, I really can't recall if that version had this ability or not. I suggest 
you try the latest version and see if it fixes your problem.

 package limitations.  I am rebuilding into Debian Lenny with Opensips 1.6
 and Mediaproxy 2.4 from the package repositories.  Perhaps we will see a
 different behavior with more current versions.

--
Dan





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

Re: [OpenSIPS-Users] multiple use_media_proxy() calls

[Dan Pascu]

On 25 Jan 2011, at 16:39, Jeff Pyle wrote:
 Then there is some misunderstanding somewhere. Before the first 183
 arrives, mediaproxy cannot lock onto anything as it doesn't yet have
 information about both endpoints. It needs a request (INVITE) and a reply
 that carries media (183/200), before it can even begin to listen to
 packets. So how can it lock to media before even allocating the ports and
 listening is beyond me.
 
 Interesting.  I will re-verify the leaky media has stopped before the 183
 arrives.  A plausible explanation is that I am incorrect, and it is still
 flowing after the 183.

You may be right. A closer look at the code shows that the relay may learn 
stream addresses even before receiving any SDP from the destination. I have 
forgotten this detail, so you can have a problem even if the leaky media stops 
before the SDP in first 18x

 I checked the code and it does reset on any new request/reply.
 
 Does this mean that it resets once on any request/reply pair, or that it
 resets on each new request and each new reply?

On each request and each reply. Once a new SIP message (be that request or 
reply) with SDP is received it will reset.

 One fine point:  We have been saying 183 throughout this entire
 discussion.  That isn't accurate.  In most cases the GSX at this carrier
 sends a 180 with SDP.  I bring it up only to rule out some weird
 difference that may exist within Mediaproxy between a 183 and a 180 with
 SDP.  An SDP is an SDP, regardless of the code it rides in on, no?

Yes. As long as it has SDP is processed, regardless of code.

--
Dan





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

Re: [OpenSIPS-Users] multiple use_media_proxy() calls

[Dan Pascu]

Well, your problem seems pretty obvious. You seem to have a race condition, 
where the original media stream continues to flow past the 2nd 183, so even 
though mediaproxy resets the ports and expects to re-learn them, it will still 
lock to the old one as the stream continues to flow past the reset point.

Unfortunately for you, you cannot fix this with any manual use of 
use_media_proxy/end_media_session. engage_media_proxy is jus tan automated way 
to appropriately call those 2 for every message in the dialog, to release you 
from the need of calling them yourself on every message. Using one or another 
will have the same result, the only difference is that one is automated and 
once started cannot be stopped, while the other is manual and allows more 
control over starting/stopping it later after the dialog started.

Fortunately for you, there is a simple solution for all this. The media relay 
can store the original media IP/port it received from the SDP (it may already 
store them, I haven't checked). Then later when it receives a packet outside of 
the conntrack rule that was added after locking to a stream, it can compare 
that address with the stored SDP address. If the new address is the same as the 
stored SDP address, but different from the locked address, the relay can 
re-trigger another reset (or simply remove the conntrack rule and add one with 
the SDP address). In other words, the relay should always favor media coming 
from the same address advertised in the SDP over the automatic discovery of the 
port.

The fix should be simple to implement, but currently I cannot allocate time for 
this. If you have the knowledge or you know someone that can help, feel free to 
make a patch and I will include it. Otherwise it may take a while until I can 
get to address it.

On 21 Jan 2011, at 16:42, Jeff Pyle wrote:

 Dan,
 
 Excellent info.
 
 Here's the call flow I'm having trouble with:
 
 - INVITE from Opensips to carrier (Sonus GSX), mediaproxy previously
 engaged.
 - GSX fires back 100.
 - GSX tries a route on SS7 to terminate the call.
 - Some media comes from the GSX on port, say, 16400 as a function of this
 first termination attempt.
 - Mediaproxy sees this RTP and locks onto it.
 - GSX's primary SS7 route fails, so he tries a second one.
 - This route is good, and the GSX relays back a 183 w/ SDP, indicating
 port 16800.
 - Media begins to flow from the GSX on port 16800, but it's too late
 because the relay has locked onto the leaky media on port 16400.  And
 the call is shot.
 
 I went rounds with the carrier for quite a while on this.  I think they
 tried for a while to see what they could do, but ended up citing a part of
 an RFC I can't find at the moment that says a UAC should ignore any media
 not defined in the SDP.  Mediaproxy isn't doing that, so as far as they
 are concerned the case is closed because my UAC is broken.
 
 I have no practical experience yet with the manual
 use_media_proxy/end_media_proxy calls; I've used only engage_media_proxy.
 I would not try to mix them (I know that's a no-no).  My hope was to try
 to find a combination with the manual commands above and beyond what the
 automatic engage'r could do.
 
 Can you think of a way I could handle this scenario either with
 engage_media_proxy or with use_media_proxy/end_media_proxy?  Much to my
 chagrin I've seen a few more carriers exhibit this type of behavior.  One
 way or another I think we're going to have to find a way to accommodate
 it.  
 
 
 - Jeff
 
 
 On 1/21/11 2:39 AM, Dan Pascu d...@ag-projects.com wrote:
 
 Unfortunately for you this will not work, for 3 reasons.
 
 1. engage_media_proxy already calls use_media_proxy for every message in
 the dialog, so by manually calling use_media_proxy on a certain message
 you do not change the conditions of the problem, as engage_media_proxy
 already called it for that message by using dialog hooks. You will only
 end up calling it twice which doesn't help, on the contrary (see point
 2). Also every time a new message is received in dialog and forwarded to
 mediaproxy for processing, mediaproxy will reset it's known expected
 ports and re-learn them when it receives the next media packet from
 endpoints.
 
 2. by calling use_media_proxy twice, the 2nd call won't overwrite the
 previous value. Unfortunately, this is not a mediaproxy issue, is a
 generic opensips issue that results from the way changes are applied to
 the existing message using lumps. Any other opensips function that
 modifies the message, if called twice will corrupt the message by
 appending each change after each other, instead of overwriting the
 previous one. So in case of mediaproxy you will see 2 IP addresses
 concatenated like: xx.xx.xx.xxyy.yy.yy.yy where the IP address was
 replaced.
 
 3. You cannot mix engage_media_proxy with
 use_media_proxy/end_media_session (this is clearly mentioned in the
 docs). If you start the call with engage_media_proxy and later expect to
 call

Re: [OpenSIPS-Users] multiple use_media_proxy() calls

[Dan Pascu]

On 21 Jan 2011, at 18:32, Jeff Pyle wrote:

 Dan,
 
 Brett and I communicated privately.  It turns out the majority of both our 
 headaches with this issue is from the same, rather large carrier.  Does 
 anything come to mind on how we might handle it?
 
 I'd love an option I could include in engage_media_proxy to tell it to 
 immediately set up the conntrack rules using the ports in the SDP rather than 
 try to detect the ports on the fly.

This can be automated as described in the previous message so both automatic 
detection and preferring SDP addresses can coexist.

 
 Or, perhaps something already available in the code to force a reset of some 
 sorts when the 18x w/ SDP message comes back?  By this point, the leaky media 
 has stopped and the legit media is flowing.

I don't think this is your case, because the relay already handles this. it 
will reset it's knowledge of the learnt addresses with every request/reply in 
dialog. So when the 2nd 183 comes in, it does reset the ports and attempts to 
relearn them. If things would be as you describe them (1st media stream has 
stopped when the 2nd 183 comes), then it should simply work because the relay 
would reset and learn the ports from the 2nd media stream. But I suspect that 
the 1st media stream still flows a bit past the 2nd 183 and the relay locks 
onto that again instead of locking on the 2nd media stream (that probably comes 
only after it re-locked to the 1st). Otherwise I cannot explain why it wouldn't 
work for you as the relay relearns the addresses after every 183/200

--
Dan





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

Re: [OpenSIPS-Users] multiple use_media_proxy() calls

[Dan Pascu]

Unfortunately for you this will not work, for 3 reasons.

1. engage_media_proxy already calls use_media_proxy for every message in the 
dialog, so by manually calling use_media_proxy on a certain message you do not 
change the conditions of the problem, as engage_media_proxy already called it 
for that message by using dialog hooks. You will only end up calling it twice 
which doesn't help, on the contrary (see point 2). Also every time a new 
message is received in dialog and forwarded to mediaproxy for processing, 
mediaproxy will reset it's known expected ports and re-learn them when it 
receives the next media packet from endpoints.

2. by calling use_media_proxy twice, the 2nd call won't overwrite the previous 
value. Unfortunately, this is not a mediaproxy issue, is a generic opensips 
issue that results from the way changes are applied to the existing message 
using lumps. Any other opensips function that modifies the message, if called 
twice will corrupt the message by appending each change after each other, 
instead of overwriting the previous one. So in case of mediaproxy you will see 
2 IP addresses concatenated like: xx.xx.xx.xxyy.yy.yy.yy where the IP address 
was replaced.

3. You cannot mix engage_media_proxy with use_media_proxy/end_media_session 
(this is clearly mentioned in the docs). If you start the call with 
engage_media_proxy and later expect to call end_media_session to end it and 
start using use_media_proxy it won't work. It will remove the session from the 
media relay, but it will not reset the dialog callbacks, which means that the 
dialog module will keep calling the callbacks that the original 
engage_media_proxy triggered. So while the session may be gone from the relay, 
the next message that triggers a dialog callback will attempt to add it back, 
however considering that half of the original information about the call was 
lost in the relay when the session was removed, it will not be able to restore 
the session anymore and you'll end up with a corrupted state and things won't 
work. You need go decide early which mechanism to use and stick with that for 
that call.

In the end I really don't understand why you think all these things will help. 
mediaproxy is already prepared for IP/port changes following a SIP 
request/reply. So when a new request/reply is received and forwarded to 
mediaproxy, it will reset the ports it learned and allow them to change. Then 
the first media packets it receives after a SIP message will make it learn the 
new IP/ports for the media streams. This is already done as it is necessary for 
it to work (think about starting media when a 183 is received, but later some 
other endpoint answers the call with a 200 OK and media will come from a 
different device than the early media). mediaproy can handle this right now and 
what you describe doesn't sound different, with the only exception that it 
looks like a buggy behavior, not something that resulted from a normal call 
flow.

On 20 Jan 2011, at 22:13, Jeff Pyle wrote:

 Yikes.  Good to know; thanks.
 
 Here's the issue.  Today I use media relay in limited cases, only when I have 
 to have it for internal network reasons.  Long story, but if I don't use it, 
 QoS doesn't happen right.  Anyway, it's about 1% of total traffic.  No big 
 deal.
 
 I've had no issues with the dialog module over the last 2 years or so.  
 (Counting blessings…)  As such, I use the engage_media_proxy() command.  It 
 works — most of the time.  Unless an upstream carrier lets some media leak 
 through outside of the ports indicated in the SDP that hasn't arrived yet.  
 The relay locks onto the wrong ports, and we get one-way or no-way audio.
 
 This happens in one particular carrier's case when they route-advance on SS7 
 behind the scenes as a function of their Sonus GSX.  They can't tell me why 
 any media comes through at all on the first (disregarded) route.  But, the 
 SDPs they send do have the correct ports for the second (utilized) route.  
 This SDP comes after the leaky media.  Mediaproxy, being primarily a NAT 
 traversal mechanism, listens more to what's really happening on the network 
 rather than what's happening in the SDP.
 
 And now the part I haven't researched fully.  I'm hoping to be able to 
 reset the media relay with an end_media_session() then use_media_relay() in 
 an onreply_route to force a port re-detection in the relay when the 180 w/ 
 SDP comes through (after the incorrect media dribble has completed), and 
 ultimately the 200 OK.  I may break more than I fix with this.  Time will 
 tell.
 
 If this or something like it works, I'll be able to use the relays more.  
 Which is something I'd like to do – mostly for accounting.
 
 
 - Jeff
 
 From: Duane Larson duane.lar...@gmail.com
 Reply-To: OpenSIPS users mailling list users@lists.opensips.org
 Date: Thu, 20 Jan 2011 14:54:13 -0500
 To: OpenSIPS users mailling list users@lists.opensips.org
 Subject: Re: [OpenSIPS-Users] multiple 

Re: [OpenSIPS-Users] [MediaProxy] desirable media-relay server attributes

[Dan Pascu]

On 3 Jan 2011, at 22:41, Jeff Pyle wrote:

 Hello,
 
 I'm spec'ing out some servers to be media relays running Mediaproxy 2.4.x.  
 Assuming a standard Debian stable install with the appropriate packages 
 pulled from testing, which attributes are most desirable:  fewer, faster 
 processing cores or more, slower processing cores?

I do not think the CPU will be limiting you. Consider that Cisco routers do not 
have multiple cores, yet still manage to route traffic that saturates their 
interfaces.

The most limiting factor will be your network card. RTP traffic consists in a 
lot of small UDP packets (even as low as a few bytes). That means that the 
network card will have to deal with a lot of packets and most standard cards 
generate one interrupt per packet received. As a result your CPU will be 
saturated with handling interrupts, not with the actual processing/forwarding 
of the data.

Probably more cores can help here given that they handle interrupts 
independently, so the more core you have the more interrupts you can handle. 
But that is only true if the interrupt handling is independent per core and not 
shared by all cores.

The best you can do is get some smart network cards that can aggregate multiple 
packets received and only send 1 interrupt for a bunch of them, thus relaxing 
its burden on the system.

 
 For example, would it be better to have an 2 processor box each with 8 cores 
 at 2.0 GHz (AMD), or a box with 2 processors each with 4 cores at 3.6 GHz 
 (Intel)?  I'm not interested in the brand warfare but rather the question of 
 speed and quantity of processing cores.
 
 I would imagine this comes down the multithreaded ability of the linux kernel 
 and how the conntracks use it.  There are those on this list with much more 
 knowledge and experience than I at these things.  Any thoughts?
 
 Also, would memory speed come into play here, or would I run out of bandwidth 
 way before it would matter?

I don't think memory bandwidth will be an issue. Mediaproxy only makes your 
linux box act as a dedicated router with specific routing rules. Linux is 
perfectly capable of working like that, people use it as a router and drive up 
to 34GBps/s with a box. As I said your biggest problem will be given by the 
insane amount of small packets the system needs to process that generate too 
many interrupts from most network cards. 

--
Dan





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

Re: [OpenSIPS-Users] mediaproxy 2.4.2

[Dan Pascu]

On 2 Dec 2010, at 20:04, Richard Revels wrote:

Here is the m line from an INVITE/200 after the messages were  
modified by use_media_proxy in each direction.  The call happened to  
be mine and although it did not stay up long enough for me to be  
100% sure, I think the person on the other end of the line was  
someone other than the person who called me.


That is very unlikely. When you call use_media_proxy and the relay  
allocates a port pair for an endpoint, it is not possible that that  
port is substituted in another INVITE/reply from a different dialog.  
Of course someone can watch the SIP traffic and see your port and  
initiate a RTP connection to that port before the actual endpoint who  
was supposed to connect there does, but a doubt that was the case  
here. Plus that is not a software bug, but an exploit which is  
actively pursued by someone based on the fact that SIP traffic is not  
encrypted.


I have only seen the port be offset by two when using the  
mediaproxy.  Is that not the expected behavior always?


m=audio 52352 RTP/AVP 0 97 18 101.
m=audio 58676 RTP/AVP 0 101.


While normally ports are +2 apart, that is not always true. the relay  
will keep track of ports which cannot be used because they are already  
in use on the system and remove them from the list, which creates  
gaps. Also, later the relay will put those unavailable ports back in  
the available ports pool in order to be tried again, if their number  
exceeds the available ports number. When this is done, they are not  
placed in their original ordered positions, but added to the end of  
the list, making the ports list fragmented.


There are other details about how ports are organized internally which  
will influence this even under normal usage when all ports are  
available, but I will not dwell into them. Suffice to say that your  
ports will be +2 apart only after you start the relay and before all  
ports in the port range were used once and the port allocation will  
roll over and start from the beginning.


--
Dan







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

Re: [OpenSIPS-Users] nat_traversal nat_keepalive vs. fix_contact

[Dan Pascu]

On 29 Sep 2010, at 05:37, Jody Rudolph wrote:

 All,


 Is there any reason that nat_keepalive and fix_contact should not be  
 used on the same register message? When both are used as shown  
 below, the keep-alives are not sent. If the fix_contact is commented  
 out the keep-alives are sent, however, the RFC1918 contact is sent  
 to the registrar.

You should not fix the contact for REGISTER messages. The whole system  
not only works just fine without it, it is required by the RFC that  
the contact is not modified.
I can't recall right now why it behaves like you describe, but I'd  
venture to guess that since you fixed the contact and it was saved  
with a public IP, the keepalive system ignores it, considering that it  
doesn't need keepalives anymore.

   
   if (client_nat_test(3)) {


   nat_keepalive();
   add_path();
   ds_select_dst(1, 4);
   #fix_contact();   if uncommented the keep-alives 
 are  
 not sent
   if (!t_relay()) {
   sl_reply_error();
   };
   exit;
   }


 Thanks,
 Jody Rudolph
 ___
 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] Mediaproxy: closing expired call when one party stops sending RTP

[Dan Pascu]

On 20 Sep 2010, at 17:30, John Khvatov wrote:

 Hello!

 Thank you all for your replies! I'll try SST module to solve the
 problem.

 On Mon, 20 Sep 2010, Dan Pascu wrote:


 On 16 Sep 2010, at 14:52, John Khvatov wrote:

 Hello all.

 I have a problem with RTP timeouts on media relay.

 Media relay sends expired command only when _both_ parties stop
 sending RTP. When we have one-directional RTP flow, media relay does
 not
 throws timeout.

 Is it a known behaviour? Any suggestions on how to fix it?

 This is not a bug, it's a feature. Consider the case where one party
 uses voice activation and doesn't say anything for a few minutes,  
 just
 listens to the other party.

 Indeed, but FreeSWITCH will disconnect the call in this case.

That may be Freeswitch's decision to do so, but it doesn't mean that  
every other device or software may do the same. Others will keep the  
call active and I see no reason to not support users that use voice  
activation.


 Hmm, actually that doesn't say anything is doesn't send RTP?

Exactly. That's what voice activation does.

--
Dan







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

Re: [OpenSIPS-Users] Mediaproxy: closing expired call when one party stops sending RTP

[Dan Pascu]

On 16 Sep 2010, at 14:52, John Khvatov wrote:

 Hello all.

 I have a problem with RTP timeouts on media relay.

 Media relay sends expired command only when _both_ parties stop
 sending RTP. When we have one-directional RTP flow, media relay does  
 not
 throws timeout.

 Is it a known behaviour? Any suggestions on how to fix it?

This is not a bug, it's a feature. Consider the case where one party  
uses voice activation and doesn't say anything for a few minutes, just  
listens to the other party.

--
Dan







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

Re: [OpenSIPS-Users] Mediaproxy: closing expired call when one party stops sending RTP

[Dan Pascu]

On 20 Sep 2010, at 00:14, Richard Revels wrote:

 Media relay uses linux connection tracking.  The rules are bi- 
 directional.  If packets are still coming from the called party side  
 back to the (no longer there) calling party side then the packet  
 counters are still incrementing.

Not only conntrack rules are bidirectional and won't timeout if they  
receive packets from at least one endpoint, but mediaproxy was made to  
behave this way by design. Consider the case where one party uses  
voice activation and doesn't say anything for a few minutes. How can  
you distinguish between this valid case and the case where one  
endpoint just died?

 There might also be a way to poll the conntrack packet count  
 externally and compare them against dialogs via the MI interface.

The relay is not necessarily on the same host as opensips, so it may  
not be able to inspect the MI interface. Plus, it wouldn't even help  
since the dialogs are still there. If one endpoint dies, it won't send  
a BYE to close the dialog, because in that case it would close the  
media as well and there wouldn't be a problem anymore.

IMO this cannot be solved within the context of mediaproxy alone,  
since it's not just a media issue. Itg also involves signaling and the  
ability to distinguish between a dead endpoint and a silent one.

--
Dan







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

Re: [OpenSIPS-Users] media-dispatcher | BYE retransmition and end_media_session()

[Dan Pascu]

On 6 Sep 2010, at 17:11, Julien Chavanton wrote:

 Hi,

 Some SIP UA are sending retransmition of BYE, we do  
 end_media_session() when we receive one, this does create some error  
 on media-dispatcher :

  Sep  6 15:00:32 osip2 media-dispatcher[5871]: error: Got  
 `remove' command from OpenSIPS for unknown session with call-id  
 `3880952242`

 If excessive occurrences are faced, not sure why excatly eventualy  
 the media-dispatcher start to malfunction.

 My question is how can we protect the media-dispatcher from this  
 situation ?

You can use engage_media_proxy(). It is dialog based and will only  
send a remove request once when the dialog is terminated.

--
Dan







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

Re: [OpenSIPS-Users] Contact problems using nat_traversal

[Dan Pascu]

On 29 Aug 2010, at 23:47, Yaniv Vaknin wrote:


 Hi,
 I have two Opensips servers, both with public IP's, I use them as an
 outbound proxy.
 both servers are running version 1.6.2, the difference is that they  
 run
 different OS and that one of them installed via SVN.
 The problem is that when I register a client via one server the  
 contact
 field is set to my server instead of the client IP address.

You need to call nat_keepalive() on the border server that's the entry  
point, not later.

Phone - Pa - Pb - Pc - Destination

Pa needs to call nat_keepalive() in the above example, not Pb nor Pc.  
Also call it the first time the SIP message enters the proxy, not  
later after you maybe looped the message through the proxy and it  
comes from itself.



 I copied the configuration file from the working server but the  
 problem
 persist...

 I use the following :

 loadmodule nat_traversal.so
 modparam(nat_traversal, keepalive_interval, 90)
 modparam(nat_traversal, keepalive_method, NOTIFY)

 if (client_nat_test(3)) {
 xlog (L_WARN, source uri is.$source_uri\n\n\n);
 force_rport();
 fix_contact();

 if ((method==REGISTER  ||(method==INVITE  !has_totag())) )
  {
  nat_keepalive();
  }
 }

 here is the asterisk sip trace:

 1.1.1.1 - Asterisk server
 2.2.2.2 - Opensips server

 REGISTER sip:1.1.1.1 SIP/2.0
 Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bKaf29.e5f35d04.0
 Via: SIP/2.0/UDP
 192.168.5.102:5060;received=84.108.207.103;branch=z9hG4bK- 
 ln3bfw2dzns8;rport=1201
 From: sip:2...@1.1.1.1;tag=z1vu2n07nk
 To: sip:2...@1.1.1.1
 Call-ID: 3c26c9e8ac62-3f9tq2ss8sef
 CSeq: 143 REGISTER
 Max-Forwards: 69
 Contact:
 sip:2...@2.2.2.2:1201;reg-id=1;q=1.0;+sip.instance=urn:uuid:403adde2-966a-4810-9884-1297ab488584
  
  
 ;audio 
 ;mobility 
 = 
 fixed 
 ;duplex 
 = 
 full 
 ;description 
 = 
 snom320 
 ;actor 
 = 
 principal 
 ;events 
 = 
 dialog 
 ;methods 
 = 
 INVITE 
 ,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO
 User-Agent: snom320/7.3.30
 Supported: gruu
 Allow-Events: dialog
 X-Real-IP: 192.168.5.102
 Expires: 0
 Content-Length: 0


 And here is the correct packet from asterisk:

 REGISTER sip:1.1.1.1 SIP/2.0
 Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK7c0e.d7ff3973.0
 Via: SIP/2.0/UDP
 192.168.5.102:5060;received=84.108.207.103;branch=z9hG4bK- 
 gjsza8t89n7x;rport=1201
 From: sip:2...@1.1.1.1;tag=oa2wzegbv1
 To: sip:2...@1.1.1.1
 Call-ID: 3c26c27d340f-t3j6g9ehuz4q
 CSeq: 123 REGISTER
 Max-Forwards: 69
 Contact:
 sip:2...@84.108.207.103:1201;reg-id=1;q=1.0;+sip.instance=urn:uuid:c6252d37-19ae-47b6-982b-3932725a444c
  
  
 ;audio 
 ;mobility 
 = 
 fixed 
 ;duplex 
 = 
 full 
 ;description 
 = 
 snom320 
 ;actor 
 = 
 principal 
 ;events 
 = 
 dialog 
 ;methods 
 = 
 INVITE 
 ,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO
 User-Agent: snom320/7.3.30
 Supported: gruu
 Allow-Events: dialog
 X-Real-IP: 192.168.5.102
 Expires: 3600
 Content-Length: 0





 Thanks,
 Yaniv
 -- 
 View this message in context: 
 http://opensips-open-sip-server.1449251.n2.nabble.com/Contact-problems-using-nat-traversal-tp5475891p5475891.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



--
Dan







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

Re: [OpenSIPS-Users] OpenXCAP and Presence with SNOM version 8.2.29

[Dan Pascu]

On 2 Jun 2010, at 17:12, osiris123d wrote:

 Sorry Saul,
 Â
 I got my Sniff's messed up.  It should have been the other way  
 around (Should have double checked my message).
 Â
 Attached is a txt file with both the Firefox and Snom sniff.  I  
 have also included a good Counterpath Bria sniff from a different  
 user.  From the looks of it the difference here for the good HTTP  
 GETS is that the GET starts with the /[hidden email]/ path for the  
 URI, whereas the SNOM phone starts with 
 https://xcap.server.com:443/xcap-r...@.../ 
  path.

It appears that openxcap has a problem in handling absolute URIs in  
the request, this is why it prepends https://server-host/ to the  
request URI and you get the double host in the error message in the log.
We'll check it. Most likely openxcap assumes that it has to receive an  
absolute path. I'm not sure if the xcap rfc specifies otherwise, but  
at least the http rfc says that the requested resource can be an  
absolute URI or an absolute path.

--
Dan







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

Re: [OpenSIPS-Users] OpenXCAP and Presence with SNOM version 8.2.29

[Dan Pascu]

On 3 Jun 2010, at 00:16, osiris123d wrote:


 Sweet.  I might have found my first bug on this forum .

 I went ahead and posted my findings on Snom's forum today.  I will  
 see what
 they say.  Also would like to hear what you find after checking.

Unless the xcap RFC has some particular specification about the format  
of the resource in the GET request, that overrides what the http RFC  
says, I'd say it's a bug. If so it'll be fixed.

--
Dan







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

Re: [OpenSIPS-Users] mediaproxy and open file descriptors

[Dan Pascu]

On 27 May 2010, at 05:48, Jeff Pyle wrote:

 Hello,

 Does Mediaproxy use a significant amount of file descriptors during  
 its operations?  The default allowed on Debian and CentOS systems I  
 have is 1024.  If Mediaproxy does use them, how many calls would  
 this allow?

It can potentially use as many as the ports in the port range setting  
and then some. However you do not need to take special precautions for  
this. During startup, the relay automatically increases the limit of  
allowed open file descriptors to port_range_end - port_range_start +  
1000 and if it can't do that it will give an error and refuse to start.


 It seems I have some ugliness occurring at either the relays or the  
 dispatcher when I go into the hundreds.  I haven't able to identify  
 a specific quantity yet.  I do see the relays reporting disconnects  
 from the dispatcher, however.

 I keep telling myself that if it were easy, it wouldn't be any fun!


 Thanks,
 Jeff
 ___
 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] media-relay warning

[Dan Pascu]

On 25 May 2010, at 19:52, Jeff Pyle wrote:

 Hi Saúl,

 That makes sense.  I'm more busy today than curious but thanks for  
 the info!

 Is this calculation used for documentation only?  Does disabling it  
 affect any operational aspect?

It won't affect any operational aspect. It's only used to gather  
statistics. If you disable it you won't know how much data was moved  
through the relay by each session.

  Would its running too slow cause any traffic issues through the  
 relay, particularly unscheduled disconnections from the dispatcher?

No. It has no relation with the connections. The only downside of  
having it enabled when it takes too much to compute is that the  
function that gathers the statistics is blocking. That means that if  
the relay is asked to add a new session at that time it won't do it  
until the statistics gathering function returns. Existing streams that  
belong to already established sessions won't be affected as they are  
already processed inside the kernel. The only thing affected is  
setting up new streams which is only delayed until the statistics  
gathering function finishes its job. In your case if such a request  
comes it will be delayed by approximately 11ms, which will not affect  
your operations in any visible way. The message is printed as a  
warning. We considered that blocking the processing of requests for  
more than 10ms is undesirable, but in practice you won't see any  
difference even if it takes 100ms to gather the statistics.

 I'm trying to diagnose the root causes of some issues we had this  
 morning and this information will be most helpful.

If you have one way audio or disconnections, those are in no way  
caused by this. As I said, once the session is established, the data  
is forwarded by conntrack rules in the kernel and it will not be  
affected by any delay in response from the relay. The only negative  
effect you can expect if the statistics gathering time is too high, is  
a delay in establishing the session.




 - Jeff


 On May 25, 2010, at 12:19 PM, Saúl Ibarra Corretgé wrote:

 Hi Jeff and Lazslo,

 On 25/5/10 4:45 PM, Jeff Pyle wrote:
 Laszlo,

 Good suggestion... I haven't dug into the source to see if the two  
 are
 related. I've set that value to 0 to disable it. We'll see.


 Indeed, that setting disables that calculation. If too many streams  
 are
 traversing the MediaProxy relay at the same time, the calculation  
 could
 take too long (depending on the configuration setting) so it's not a
 good idea to do it. You may want to increase the traffic sampling  
 period.

 In case you are curious, look at the _measure_speed function in the
 SessionManager class (mediacontrol.py file). That function is called
 recurrently each traffic_sample_rate seconds, that's why is not a  
 good
 idea for it to take long making the calculation.


 Regards,

 -- 
 Saúl Ibarra Corretgé
 AG Projects

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


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



--
Dan







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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Dan Pascu]

On 5 May 2010, at 12:08, Bogdan-Andrei Iancu wrote:

 Hi Dan,

 what you are saying is similar with the idea I suggested (keeping the
 new message per header - each header has its own buffer ) - see
 http://lists.opensips.org/pipermail/users/2010-April/012401.html

Consider it enforced then ;)

--
Dan







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

Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Dan Pascu]

IMO lumps should go. They're a hackish solution that caused enough  
problems already.
As I see it, we must have the original message and the current message  
(original plus all changes applied in realtime) so one can get at any  
moment the original message and the modified message without any  
complication (modified message should be per branch of course). Re- 
parsing can be kept to a minimum or even avoided completely in certain  
circumstances if the modified message is kept as a dictionary of SIP  
header name/value pairs, plus some extra info about the first line in  
the message and the content.
In other words while the original message is kept both parsed and  
unparsed, the current modified messages are only kept parsed and are  
reconstructed in a text buffer only when sent out.

On 28 Apr 2010, at 13:40, Bogdan-Andrei Iancu wrote:

 Hi,

 sorry for crossposting, but I thing this topic is interesting both for
 users (as experience) and for developers (as solution).

 So, right now the code for 2.0 got to a stage were we need to apply
 changes on the received messages (like adding VIA headers, changing
 headers, etc). And before starting the work on this area, I would like
 to get some opinions on the available options:

1) keep the current mechanism for changing the SIP messages by  
 using
 lumps that are applied only when the message is sent out :
   Advantages: code is there and works; the mechanism is very  
 fast ;
 no need to re-parse the message after the parsing
   Disadvantages : from script or code, you are not able to see the
 previous changes you did on the message, like:
 if you remove a hdr, it will be marked to be removed,
 but you will still see it there after the removed
 if you add a new hdr, you will not be able to see it
 (it will be actually added only when the message will be sent out)
 if you replace the contact hdr (like after
 fix_nated_contact() ) will not see the new contact, but the old one
 trying to apply 2 changes in the same area (like
 changing twice the contact) will result in bogus result.

2) find a new approach that will allow to push in realtime the
 changes on messages
   Advantages: the change will take affect instantly, so all the
 disadvantages from 1) (as user experience in operating opensips) will
 disappear .
   Disadvantages : the code will probably be slower (the changes
 part), but will speed up other parts of the code (where you need to
 manually identify the prev changes);
 changed parts of the SIP message will require re-parsing
 (so the code will have to check the state of a header (if parsed or  
 not)
 before each usage)
 you will not be able to undo changes on the SIP messages  
 in
 an easy way (for example during the parallel and serial forking on
 per-branch changes)

 So this is the dilemma: if the current mechanism (with applying  
 changes
 at the end) such a bad user experience (scripting) in order to try for
 2.0 a different approach ?

 I would like to hear some opinions from both people writing scripts  
 and
 people writing code.

 Thanks and regards,
 Bogdan

 -- 
 Bogdan-Andrei Iancu
 www.voice-system.ro


 ___
 Devel mailing list
 de...@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



--
Dan







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

Re: [OpenSIPS-Users] Question about mediaproxy relay preference

[Dan Pascu]

On 10 Apr 2010, at 17:13, Henk Hesselink wrote:

 Dan Pascu wrote:

 On 9 Apr 2010, at 02:14, Henk Hesselink wrote:

 Hi Dan,

 The clean way would seem to be to have different selection  
 algorithms in
 the dispatcher that can be chosen through modparam and/or an avp.  
 Maybe
 the time and motivation will become available at some point :-)

 Are you volunteering to code this? :-)

 We might, if we have time.  That's why I asked for a hint where to  
 start
 (send_command method in the RelayFactory class?).

I don't recall the details, but it's where the random choice of a  
relay is done. I guess it should be somewhere in that function.

--
Dan







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

Re: [OpenSIPS-Users] Question about mediaproxy relay preference

[Dan Pascu]

On 9 Apr 2010, at 02:14, Henk Hesselink wrote:

 Hi Dan,

 The clean way would seem to be to have different selection  
 algorithms in
 the dispatcher that can be chosen through modparam and/or an avp.   
 Maybe
 the time and motivation will become available at some point :-)

Are you volunteering to code this? :-)


 Our situation is this:

 - we don't know to which datacenter a UA will send its traffic: we're
  BGP multi-homed so this can also change randomly.  And for the same
  reason we usually can't say anything about how 'far away' a UA is
 - we do know where the servers (media/conf./PSTN gw./etc.) are,  
 because
  they're in our datacenters (we provide hosted VOIP)
 - we don't have idle relays: front-end SIP dispatchers do  
 loadbalancing
  across the datacenters, and the media dispatchers' random selection
  means that all media relays have about equal load

 What we're trying to achieve is to minimize the media path by  
 preferring
 a relay that is close to (i.e. in the same datacenter as) the server  
 for
 a particular call leg, and to only choose a relay that is farther away
 when all the local ones are unavailable (down/high load/whatever).

 As it is now, about 20-30% of our calls would be completely local to
 one datacenter except that the dispatcher assigns a relay in another
 one.

This would be solved by a 'choose the relay that minimizes the voice  
path' algorithm I proposed before.


 Any suggestions how to improve that?

By coding those selection algorithms. As it is now you cannot do much,  
except manually select a specific relay for a call.


 Henk


 Dan Pascu wrote:
 On 7 Apr 2010, at 10:45, Saúl Ibarra Corretgé wrote:

 Hi,

 On 5/4/10 10:13 PM, Henk Hesselink wrote:
 Hi Adrian,

 The way I read the code I can indicate one preferred relay, but  
 not a
 set.  So I can't say prefer this set of relays (i.e. the ones in
 this
 particular datacenter) over the rest.  That's less flexible than  
 the
 SRV style.

 What would be great would be a dispatcher option to say based on  
 the
 media streams in the SDP, prefer 'local' relays for some
 definition of
 local - for instance relays that are on the same subnet as one or
 more
 of the media endpoints.  I might be able to code up a patch for
 that if
 you can give me a hint where to start (looks like that would be the
 send_command method in the RelayFactory class).


 Having that said, here is my proposal: modify both OpenSIPS module  
 and
 MdediaProxy to accept a list of space separated relays. The way of
 building that list should be decoupled from the whole process  
 IMHO, so
 you could do it by having the DNS query results cached somewhere.  
 This
 would prevent the delay that DNS query may cause.


 I'm pretty much opposed to such hacks in mediaproxy. They do not add
 any value only increase the complexity. This would be just a hack on
 top of another hack (the ability to specify the media relay from
 OpenSIPS's configuration was a hack to fill the lack of a better  
 relay
 selection algorithm than the 'choose a random relay').

 What mediaproxy needs to solve such issues is configurable relay
 selection algorithms. We planned that from the start, we just didn't
 have the time and motivation to implement anything more elaborate  
 than
 the random selection yet.

 One such algorithm would be to prefer a relay that is closer to the
 proxy. Or one that is closer to the PSTN gateway.

 Another one would be for the dispatcher to determine the relay that  
 is
 closest to the UA and prefer that (this is what we had in mind from
 the beginning).

 Also this has to keep in mind how much a relay is loaded. A relay
 should be able to inform the dispatchers when it cannot accept  
 anymore
 sessions (by monitoring the CPU/network load) so a relay is not
 overloaded. The proposed solution cannot guarantee this as in the
 OpenSIPS configuration there is no way of knowing it.

 Besides the original feature proposal only tries to emulate the old
 model where some mediaproxies were idle waiting for the main ones to
 fail in order to enter the scene. This is no longer the model for
 mediaproxy-2. If you always prefer relays close to the proxy, then
 when are the ones which are farther away be used? Also what if the
 ones close to the proxy are not close to the endpoints and only add
 lag to the conversation. What if the ones close to the proxy are
 overloaded while the others are completely idle. Such a solution will
 not address any of these issues.

 --
 Dan







 ___
 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] Question about mediaproxy relay preference

[Dan Pascu]

On 7 Apr 2010, at 10:45, Saúl Ibarra Corretgé wrote:

 Hi,

 On 5/4/10 10:13 PM, Henk Hesselink wrote:
 Hi Adrian,

 The way I read the code I can indicate one preferred relay, but not a
 set.  So I can't say prefer this set of relays (i.e. the ones in  
 this
 particular datacenter) over the rest.  That's less flexible than the
 SRV style.

 What would be great would be a dispatcher option to say based on the
 media streams in the SDP, prefer 'local' relays for some  
 definition of
 local - for instance relays that are on the same subnet as one or  
 more
 of the media endpoints.  I might be able to code up a patch for  
 that if
 you can give me a hint where to start (looks like that would be the
 send_command method in the RelayFactory class).


 Having that said, here is my proposal: modify both OpenSIPS module and
 MdediaProxy to accept a list of space separated relays. The way of
 building that list should be decoupled from the whole process IMHO, so
 you could do it by having the DNS query results cached somewhere. This
 would prevent the delay that DNS query may cause.


I'm pretty much opposed to such hacks in mediaproxy. They do not add  
any value only increase the complexity. This would be just a hack on  
top of another hack (the ability to specify the media relay from  
OpenSIPS's configuration was a hack to fill the lack of a better relay  
selection algorithm than the 'choose a random relay').

What mediaproxy needs to solve such issues is configurable relay  
selection algorithms. We planned that from the start, we just didn't  
have the time and motivation to implement anything more elaborate than  
the random selection yet.

One such algorithm would be to prefer a relay that is closer to the  
proxy. Or one that is closer to the PSTN gateway.

Another one would be for the dispatcher to determine the relay that is  
closest to the UA and prefer that (this is what we had in mind from  
the beginning).

Also this has to keep in mind how much a relay is loaded. A relay  
should be able to inform the dispatchers when it cannot accept anymore  
sessions (by monitoring the CPU/network load) so a relay is not  
overloaded. The proposed solution cannot guarantee this as in the  
OpenSIPS configuration there is no way of knowing it.

Besides the original feature proposal only tries to emulate the old  
model where some mediaproxies were idle waiting for the main ones to  
fail in order to enter the scene. This is no longer the model for  
mediaproxy-2. If you always prefer relays close to the proxy, then  
when are the ones which are farther away be used? Also what if the  
ones close to the proxy are not close to the endpoints and only add  
lag to the conversation. What if the ones close to the proxy are  
overloaded while the others are completely idle. Such a solution will  
not address any of these issues.

--
Dan







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

Re: [OpenSIPS-Users] Mediaproxy error

[Dan Pascu]

On 10 Feb 2010, at 11:51, a...@pmnt.net wrote:

 Thanks for answer

 I find next modules for my Debian Linux kernel

 ipt_MASQUERADE
 nf_nat_sip
 nf_conntrack_sip
 iptable_nat
 nf_nat
 nf_conntrack_ipv4
 nf_conntrack

 Pls could you tell me what modules from the sheet  must present in
 kernel?

iptables. This one is loaded by /etc/init.d/mediaproxy-relay (look for  
modprobe lines) since it appears it is not automatically loaded. All  
the others are automatically loaded when needed (at least if your  
kernel supports autoloading, which every debian provided kernel should  
do)

--
Dan




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

Re: [OpenSIPS-Users] Mediaproxy error

[Dan Pascu]

On 10 Feb 2010, at 12:43, a...@pmnt.net wrote:

 Dan

 As per iptables this module is present.

 But error present regulary

Check if you have the iptable_raw and iptable_nat modules loaded


 Feb 10 08:58:03 sip media-relay[20476]: Traceback (most recent call  
 last):
 Feb 10 08:58:03 sip media-relay[20476]:   File /usr/lib/python2.5/ 
 site-packages/twisted/internet/udp.py, line 126, in doRead
 Feb 10 08:58:03 sip media-relay[20476]:  
 self.protocol.datagramReceived(data, addr)
 Feb 10 08:58:03 sip media-relay[20476]:   File /usr/lib/pymodules/ 
 python2.5/mediaproxy/mediacontrol.py, line 127, in datagramReceived
 Feb 10 08:58:03 sip media-relay[20476]: self.cb_func(host, port,  
 data)
 Feb 10 08:58:03 sip media-relay[20476]:   File /usr/lib/pymodules/ 
 python2.5/mediaproxy/mediacontrol.py, line 202, in got_data
 Feb 10 08:58:03 sip media-relay[20476]:  
 self.substream.check_create_conntrack()
 Feb 10 08:58:03 sip media-relay[20476]:   File /usr/lib/pymodules/ 
 python2.5/mediaproxy/mediacontrol.py, line 252, in  
 check_create_conntrack
 Feb 10 08:58:03 sip media-relay[20476]: self.forwarding_rule =  
 _conntrack.ForwardingRule(self.caller.remote, self.caller.local,  
 self.callee.remote, self.callee.local, se
 Feb 10 08:58:03 sip media-relay[20476]: Error: Table does not exist  
 (do you need to insmod?)

 As previous mail now I check all conntrack modules.

 Any other suggestions about this error?

 A want to add that I can't receive traffic in my radius accounting.
 Call duration is calculated OK, but caller and callee traffic always  
 0.
 Is it undependent  or is in touch with this media-relay error?

 Best wishes, Ant


 ___
 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] mediaproxy media_relay_avp

[Dan Pascu]

On 19 Jan 2010, at 20:31, Jeff Pyle wrote:

 Hello,

 The relays in my network use a different interface for relaying  
 packets than they do for other machine operations.  For example, a  
 relay's eth0 IP may be 207.x.x.x, while its eth1 is 66.x.x.x, and  
 the relay IP as defined by config.ini is the 66.x.x.x address.  This  
 works fine for the most part.

 I now have a need to start specifying media relays with the  
 media_relay_avp parameter in Opensips.  Do I specify the 207.x.x.x  
 IP address the relay uses to connect to the dispatcher, or the  
 66.x.x.x IP the relay uses to relay RTP?

you need to specify the address the relay used to connect to the  
dispatcher.


 The media_relay_avp documentation says, ... it will be preferred by  
 the dispatcher over the normal selection algorithm.  Is it accurate  
 to say that if the specified relay is not available, the dispatcher  
 will revert to its regular selection?  Or, will no relay be used at  
 all?

it will be preferred, but if not found/unavailable it'll fall back to  
the default selection mechanism. it will just get the highest priority  
in the search list if you will.

--
Dan




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

Re: [OpenSIPS-Users] need help on mediaproxy that cannot start

[Dan Pascu]

On 8 Jan 2010, at 22:17, Richard Revels wrote:

 I've been meaning to come back to this.  I'll try to get something  
 coherent together this weekend for CentOS users.  The process  
 outlined at the link below is somewhat overkill as most of the  
 python stuff can be done via easy_install with just a couple tweaks  
 to the readme.  The gnutls must be compiled and installed from  
 source but a standard ./configure; make; make install is all that is  
 needed there as well.

 I had a problem with asking for specific versions of both sqlobject  
 and python-application because easy_install is not able to find them  
 wherever it looks by default.  This is a drag since it worked fine  
 for sqlobject just a couple of weeks ago.  Here are the command  
 lines I am using to get around that:

 #get recent version of setup tools
 easy_install -U setuptools

 #let easy_install download and install from svn for specific version  
 (notice space between url and package identifier)
 easy_install http://svn.colorstudy.com/SQLObject/tags/0.9.0/  
 sqlobject==0.9.0

Why do you need sqlobject==0.9.0? I'm running with 0.11.0 just fine  
and I expect it to run with 0.12.0 as well as there were no changes in  
it to affect the code.

--
Dan




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

Re: [OpenSIPS-Users] need help on mediaproxy that cannot start

[Dan Pascu]

Either use python2.5 or use python-application-1.1.5. python- 
application-1.2.x depends on python2.5, however mediaproxy doesn't  
require python-application-1.2.x to work, so it can work just fine  
with python2.4 if you use python-application-1.1.5

On 8 Jan 2010, at 05:59, ha do wrote:

 Hi all


 i follow the instruction : 
 http://www.smartvox.co.uk/serfaq_install_mediaproxy2.htm

 my centos version:
 [r...@centos-cucku application]# uname -a
 Linux CentOS-Cucku 2.6.18-128.el5PAE #1 SMP Wed Jan 21 11:19:46 EST  
 2009 i686 i686 i386 GNU/Linux

 i get the error when start the mediaproxy on Centos :
 [r...@centos-cucku application]# /usr/bin/media-dispatcher
 Traceback (most recent call last):
   File /usr/bin/media-dispatcher, line 12, in ?
 from application.process import process, ProcessError
   File /usr/lib/python2.4/site-packages/application/process.py,  
 line 12, in ?
 from application import log
   File /usr/lib/python2.4/site-packages/application/log/ 
 __init__.py, line 12, in ?
 from application.log.extensions import twisted
   File /usr/lib/python2.4/site-packages/application/log/extensions/ 
 twisted/__init__.py, line 4
 from __future__ import absolute_import
 SyntaxError: future feature absolute_import is not defined


 please help

 thank you
 Ha`

 ___
 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] Media-dispatcher

[Dan Pascu]

On 4 Jan 2010, at 21:00, Richard Revels wrote:

 Interesting.  I think you may have mentioned this before Dan but I  
 didn't catch it for some reason.  That makes installing media proxy  
 on CentOS / RHEL 5.x easier.  I've found that creating an RPM to  
 install python 2.5 (along with the 2.4 rather than upgrading it) and  
 then using the virtualenv package to use it in a sandbox for non- 
 distribution applications made things a lot easier too.

 So, looking at the INSTALL file it seems that the two changes needed  
 would be

 easy_install python-application1.2.0
 and
 easy_install sqlobject==0.9

 I'll try that out this afternoon.  Will that 1.2.0 work for  
 easy_install or do I need to go find a specific version that I want  
 to use?

I'm not sure if easy_install can pick an earlier version. If it can,  
just specify 1.1.5. Otherwise you can find it here:

http://pypi.python.org/pypi?:action=displayname=python-applicationversion=1.1.5

And you can install it with python setup.py install

--
Dan




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

Re: [OpenSIPS-Users] Media-dispatcher

[Dan Pascu]

On 31 Dec 2009, at 13:07, Raúl Alexis Betancor Santana wrote:

 On Thursday 31 December 2009 09:24:51 Saúl Ibarra Corretgé wrote:
 However Python 2.4 is getting quite old now so you better upgrade to
 version 2.5 at least because at some future point Python 2.4 support
 will be dropped.

 Umm ... it had been dropped, since it doesn't run on python 2.4 ... so
 no will be dropped, better .. it had been dropped ... ;-)

Actually it hadn't. The one that requires python 2.5 is python- 
application 1.2.0+
One can run mediaproxy on python 2.4 just fine as long as it uses a  
python-application  1.2.0
There is no requirement to upgrade python-application as well.

:P

--
Dan




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

Re: [OpenSIPS-Users] Media-dispatcher

[Dan Pascu]

On 31 Dec 2009, at 10:52, Chandrakant Solanki wrote:


 Hello

 I have installed media-proxy 2.3.8 using 
 http://www.smartvox.co.uk/serfaq_install_mediaproxy2.htm

 But when i start media-dispatcher/media-relay it gives following error

 [r...@users ~]# media-dispatcher
 Traceback (most recent call last):
   File /usr/bin/media-dispatcher, line 12, in ?
 from application.process import process, ProcessError
   File build/bdist.linux-i686/egg/application/process.py, line 12,  
 in ?
   File build/bdist.linux-i686/egg/application/log/__init__.py,  
 line 12, in ?
   File /usr/lib/python2.4/site-packages/python_application-1.2.1- 
 py2.4.egg/application/log/extensions/twisted/__init__.py, line 4
 SyntaxError: future feature absolute_import is not defined

Either use python2.5 or use a python-application package  1.2.0


--
Dan




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

Re: [OpenSIPS-Users] CDRTool rating engine callcontrole prepaid Need advice

[Dan Pascu]

On 1 Dec 2009, at 14:09, Ilya Pichugin wrote:


 I found my mistake - it was necessary to tune  my e164_class.
 And now debiting is OK.. but!

 Why function call_control() always return 1 retcode, even there is
 balance =0 (No credit)?

 I cannot understand..

Because $retcode is the last function's return code and you called  
xlog(CALL_CONTROL); before the switch statement, so you actually  
test the retcode of xlog.



 Syslog:
 Dec  1 14:47:32 cdrtool call-control[7107]: Call id  
 MDY2YjZlZTc0YzA4OTUwMjhlNTNmY2IwOGRlZmRhMzU. of 3097...@a.x.y to 
 sip:3364...@a.x.y 
  forbidden because credit is too low

 Dec  1 15:06:16 cdrtool /usr/local/opensips16/sbin/opensips[9386]:  
 Call has limit and is under callcontrol management RETCODE is 1


 OpenSIPS code is:


 if (method==INVITE  nat_uac_test(2))
 {
xlog(L_INFO, record route section | INVITE  nat test: M=$rm
 RURI=$ru F=$fU T=$tu IP=$si\n);
call_control();
xlog(CALL_CONTROL);
switch ($retcode) {
case 2:
xlog(Call with no limit RETCODE is $retcode );
case 1:
xlog(Call has limit and is under callcontrol management  
 RETCODE is $retcode \n);
break;
case -1:
xlog(Not enough credit (prepaid call) RETCODE is $retcode );
sl_send_reply(402, Not enough credit);
exit;
break;
case -2:
xlog(Locked by another call in progress (prepaid call));
sl_send_reply(403, Call locked by another call in  
 progress);
exit;
break;



 Hi All!

 I've installed subject applications. I'm trying to test prepaid calls
 but it's no successful

 Why does rating engine always return 'postpaid not limited'?

 mysql select * from prepaid;
 ++-+-+-- 
 +-+-+-+
 | id | reseller_id | account | balance  |
 change_date | active_sessions | session_counter |
 ++-+-+-- 
 +-+-+-+
 |  1 |   0 | 3097...@a.x.y   | -32.6667 |
 2009-11-27 18:01:43 | null|   0 |


 I tried to force debit balance (telnet ip 9024), but call_control()  
 on
 each INVITE returnes '+1' and in syslog I see 'postpaid not limited'

 And if I call MaxSessionTime, rating engine returne 'none'

 Nov 30 12:07:25 cdrtool call-control[2230]: Call id
 MDRjZmQ2ZGI5MDFlYzJiMmIyNDgwNjI5Y2FmMTk2YTc. of 3097...@a.x.y to 
 sip:3364...@a.x.y 
  is postpaid not
 limited

 I have enabled quota-based accounts but it does not work ;-(

 mysql select  
 id 
 ,datasource 
 ,account 
 ,domain,quota,blocked,calls,duration,cost,traffic,change_date from  
 quota_usage;
 ++-+-+- 
 +---+-+---+--+--+- 
 +-+
 | id | datasource  | account | domain
 | quota | blocked | calls | duration | cost | traffic |  
 change_date |
 ++-+-+- 
 +---+-+---+--+--+- 
 +-+
 |  4 | opensips_radius | 3097...@a.x.y   | a.x.y
 |10 | 1   |23 |   91 | 658.3667 | 0   |  
 2009-11-30 12:49:53 |
 ++-+-+- 
 +---+-+---+--+--+- 
 +-+
 2 rows in set (0.00 sec)

 Where is my mistake?

 I hope for your help


 ---

 Ilya Pichugin



 ---

 Ilya Pichugin




 ___
 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] Fwd: New CallControl release 2.0.6

[Dan Pascu]

There is a typo in the code that causes that error. We will make a new  
release in the next days to fix this.

On 26 Nov 2009, at 12:17, ram wrote:



 I have installed the latest version

 trying to restart


 /etc/init.d/callcontrol restart
 Restarting SIP Call Control: callcontrolglobal name 'requirements'  
 is not defined

 /etc/init.d/callcontrol stop
 Stopping SIP Call Control: callcontrol.
 /etc/init.d/callcontrol start
 Starting SIP Call Control: callcontrolglobal name 'requirements' is  
 not defined
 already running.

 any one see this problem..

 any suggestions

 Ram

 On Fri, Jul 31, 2009 at 8:45 PM, Adrian Georgescu a...@ag- 
 projects.com wrote:
 Hello,

 There is a new release of CallControl prepaid application available,
 it contains bug fixes and better compatibility with and checks for the
 software it depends upon.

 To upgrade your debian unstable installation:

 apt-get update
 apt-get install callcontrol

 Or download the tar file from:

 http://download.ag-projects.com/CallControl/

 Changelog

 callcontrol (2.0.6) unstable; urgency=low

   * Replaced python-all-dev build dependency with python
   * Replaced use of deprecated __configfile__ with __cfgfile__
   * Added dependency checking using application.dependency
   * Replaced use of deprecated mode argument of listenUNIX with chmod
   * Modified config.ini.sample to reflect the need for doubling
 percent signs

 callcontrol (2.0.5) unstable; urgency=low

   * Replaced use of deprecated _datatypes attribute with ConfigSetting
   * Replaced use of print statement with log.error
   * Fixed handling of debug option of daemon
   * Fixed use of process.system_config_directory
   * Replaced use of read_settings with ConfigSection attributes
   * Updated dependency on python-application to = 1.1.2

 Regards,
 Adrian


 ___
 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


--
Dan




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

Re: [OpenSIPS-Users] Cleanup acc mediaproxy when dialog bye_on_timeout triggers

[Dan Pascu]

On 15 Nov 2009, at 21:31, Bogdan-Andrei Iancu wrote:

 The other problem is how to end the media proxy session. The  
 transaction flags set for the Invite are
 not visible in the local_route block when it is handling the  
 internally generated BYE's so I cannot
 try the normal checks that would be used in the main route block  
 for BYE. Perhaps I should just call
 end_media_session(), but will it even work from local_route? If I  
 change my script to start using
 engage_media_proxy() will I lose the flexibility of being able to  
 check which calls need media proxy
 and which don't? I don't want them all using it - only those with  
 far-end NAT.

 Shouldn't the media proxy automatically stop when the dialog is
 destroyed ? if you use the enagage_mediaproxy(), I think you do not  
 have
 to explicitly terminate the relay session as the this op will be done
 based on the dialog destroyed event.


When using engage_media_proxy() the media session will terminated  
automatically when the dialog ends. However if I understand it right,  
his problem is that when using use_media_proxy and end_media_session  
he has to do that manually and the local_route is triggered twice  
(once for each BYE). Now calling end_media_session twice, should do no  
harm, but it'll log an error since it will not find the session the  
second time.

--
Dan




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

Re: [OpenSIPS-Users] Call-control exception with custom scenario

[Dan Pascu]

That is a typo in the code. Edit callcontrol/controller.py and on line  
303 replace valueError with ValueError (capital V). Will be fixed in  
the next release.

On 6 Nov 2009, at 11:28, Carlo Dimaggio wrote:

 Hi all,

 I'm experiencing with a Call Control exception and a custom scenario:
 - User 1...@domain1.sip.xxx.it calls number 00390832097193 (dbaliased
 to 65310...@domain2.sip.xxx.it)
 - 65310...@domain2.sip.xxx.it has a call redirect to 1...@domain1.sip.xxx.it
 - Finally 1...@domain1.sip.xxx.it calls user 1...@domain1.sip.xxx.it
 - The billing party is 65310...@domain2.sip.xxx.it (the problem arise
 either with postpaid or prepaid)


 My syslog shows:

 Call control log:

 Nov  6 10:15:55 sip call-control[2657]: Call id 35436eb2766e5f7f of 
 1...@domain1.sip.xxx.it
  to sip:1...@domain1.sip.xxx.it is postpaid not limited
 Nov  6 10:15:55 sip call-control[2657]: error: Unhandled error in
 Deferred:
 Nov  6 10:15:55 sip call-control[2657]: Traceback (most recent call
 last):
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/python2.5/
 site-packages/twisted/internet/defer.py, line 328, in _runCallbacks
 Nov  6 10:15:55 sip call-control[2657]: self.result =
 callback(self.result, *args, **kw)
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/pymodules/
 python2.5/callcontrol/sip.py, line 185, in _setup_finish_calllimit
 Nov  6 10:15:55 sip call-control[2657]: deferred.callback(None)
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/python2.5/
 site-packages/twisted/internet/defer.py, line 243, in callback
 Nov  6 10:15:55 sip call-control[2657]:
 self._startRunCallbacks(result)
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/python2.5/
 site-packages/twisted/internet/defer.py, line 312, in
 _startRunCallbacks
 Nov  6 10:15:55 sip call-control[2657]: self._runCallbacks()
 Nov  6 10:15:55 sip call-control[2657]: --- exception caught here  
 ---
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/python2.5/
 site-packages/twisted/internet/defer.py, line 328, in _runCallbacks
 Nov  6 10:15:55 sip call-control[2657]: self.result =
 callback(self.result, *args, **kw)
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/pymodules/
 python2.5/callcontrol/controller.py, line 206, in _CC_finish_init
 Nov  6 10:15:55 sip call-control[2657]:
 self.factory.application.clean_call(req.callid)
 Nov  6 10:15:55 sip call-control[2657]:   File /usr/lib/pymodules/
 python2.5/callcontrol/controller.py, line 303, in clean_call
 Nov  6 10:15:55 sip call-control[2657]: except valueError:
 Nov  6 10:15:55 sip call-control[2657]: exceptions.NameError: global
 name 'valueError' is not defined

 Cdrtool log:

 Nov  6 10:15:55 mproxy1 cdrtool[10373]: DebitBalance Duration=0
 CallId=35436eb2766e5f7f From=sip:1...@domain1.sip.xxx.it
 Gateway=10.0.6.32 To=sip:00390832097...@domain1.sip.xxx.it:5060
 Nov  6 10:15:55 mproxy1 cdrtool[10373]: MaxSessionTime Duration=36000
 CallId=35436eb2766e5f7f From=sip:65310...@domain2.sip.xxx.it
 Gateway=10.0.6.32 To=sip:1...@domain1.sip.xxx.it


 What can be tha cause for this exception? In other cases all the
 process is ok...

 Thanks and regards,
 Carlo

 ___
 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] OpenXCAP install error

[Dan Pascu]

It looks for it in /usr/lib (you should link them there)

On 6 Nov 2009, at 12:15, Susheela Mohan wrote:

 HI,

 while starting openxcap i am getting below error, i hv  python- 
 gnutls-1.1.8 and gnutls-2.4.1 installed.

 When i do find of libgnutls.so.26 i get file in below dirs. Am I  
 missing something here??
 any help appreciated.



 ./usr/local/lib/libgnutls.so.26
 ./home/ovadm/xcap/gnutls-2.4.1/lib/.libs/libgnutls.so.26


 Thanks
 Susheela.
 

 In exception OpenXCAP 1.1.2, libgnutls.so.26: cannot open shared  
 object file: No such file or directory
 fatal error: failed to create OpenXCAP 1.1.2: libgnutls.so.26:  
 cannot open shared object file: No such file or directory
 Traceback (most recent call last):
 --- exception caught here ---
   File /etc/init.d/openxcap, line 64, in module
 from xcap.server import XCAPServer
   File /usr/local/lib/python2.6/site-packages/xcap/server.py, line  
 24, in module
 from xcap.tls import Certificate, PrivateKey
   File /usr/local/lib/python2.6/site-packages/xcap/tls.py, line 8,  
 in module
 from gnutls.crypto import X509Certificate,  X509PrivateKey
   File /usr/local/lib/python2.6/site-packages/gnutls/crypto.py,  
 line 11, in module
 from gnutls.validators import method_args, one_of
   File /usr/local/lib/python2.6/site-packages/gnutls/ 
 validators.py, line 9, in module
 from gnutls.constants import *
   File /usr/local/lib/python2.6/site-packages/gnutls/constants.py,  
 line 38, in module
 from gnutls.library import constants
   File /usr/local/lib/python2.6/site-packages/gnutls/library/ 
 __init__.py, line 4, in module
 from gnutls.library import _gnutls_init
 exceptions.ImportError: libgnutls.so.26: cannot open shared object  
 file: No such file or directory
 ___
 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] Media Proxy Problems

[Dan Pascu]

On 30 Oct 2009, at 15:31, Ross Beer wrote:

 Hi Dan,

 I didn't have rp_filter switched off!

 Is is a requirment to have UFW (Unbuntu Firwall) enabled, or can I  
 disable it totaly and allow our hardware firewall to manage this?

Mediaproxy doesn't require any firewall enabled in order to work. On  
the contrary, it can be prevented from working properly if firewalls  
are enabled.

--
Dan




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