date:20170227

Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10

2017-02-27 Thread Ramachandran, Agalya (Contractor)

Hi Liviu,

I have tired with 2.2.3 version. I am still facing crash when async is tried 
with https.
I am running OpenSIPS on centos based on open stack cloud VM.  I have not 
installed any specific curl libraries.
Curl is available by default in my centos box, and its version is,

curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC 
zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

Let me know if I can able to help you to reproduce this issue and solve it.
Here is the core dump trace.

Program terminated with signal 11, Segmentation fault.
#0  0x7fe5ed512a1e in Curl_raw_nequal () from /lib64/libcurl.so.4
Missing separate debuginfos, use: debuginfo-install 
cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 glibc-2.17-106.el7_2.4.x86_64 
keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.13.2-12.el7_2.x86_64 
libcom_err-1.42.9-7.el7.x86_64 libcurl-7.29.0-25.el7.centos.x86_64 
libidn-1.28-4.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 
libssh2-1.4.3-10.el7_2.1.x86_64 nspr-4.10.8-2.el7_1.x86_64 
nss-3.19.1-19.el7_2.x86_64 nss-softokn-3.16.2.3-13.el7_1.x86_64 
nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64 nss-sysinit-3.19.1-19.el7_2.x86_64 
nss-util-3.19.1-9.el7_2.x86_64 openldap-2.4.40-9.el7_2.x86_64 
openssl-libs-1.0.1e-51.el7_2.4.x86_64 pcre-8.32-15.el7.x86_64 
sqlite-3.7.17-8.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 
zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0  0x7fe5ed512a1e in Curl_raw_nequal () from /lib64/libcurl.so.4
#1  0x7fe5ed4e0d0f in Curl_checkheaders () from /lib64/libcurl.so.4
#2  0x7fe5ed4e21e5 in Curl_http () from /lib64/libcurl.so.4
#3  0x7fe5ed4f2b4b in Curl_do () from /lib64/libcurl.so.4
#4  0x7fe5ed502a1b in multi_runsingle () from /lib64/libcurl.so.4
#5  0x7fe5ed503121 in curl_multi_perform () from /lib64/libcurl.so.4
#6  0x7fe5ed73c446 in resume_async_http_req (fd=9, msg=0x7fe5eecd6380 
, _param=0x7fe5f132f870)
at rest_methods.c:411
#7  0x7fe5eea7d44e in t_resume_async (fd=0x7fe5f1321308, 
param=0x7fe5ef585e20) at async.c:125
#8  0x0059b258 in handle_io (idx=, event_type=, fm=) at net/net_udp.c:267
#9  io_wait_loop_epoll (h=, t=, repeat=) at net/../io_wait_loop.h:225
#10 udp_rcv_loop (si=si@entry=0x7fe5f13016c8) at net/net_udp.c:308
#11 0x0059c7d8 in udp_start_processes (chd_rank=chd_rank@entry=0x845810 
, startup_done=startup_done@entry=0x0)
at net/net_udp.c:372
#12 0x00419df0 in main_loop () at main.c:671
#13 main (argc=, argv=) at main.c:1261

Regards,
Agalya

From: Ramachandran, Agalya (Contractor)
Sent: Friday, February 24, 2017 10:39 AM
To: users@lists.opensips.org
Subject: RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 
1.11.10

Thank you Liviu. I will try in the latest version and will update you my 
observation.

Regards,
Agalya

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Liviu Chircu
Sent: Friday, February 24, 2017 3:44 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 
1.11.10

Hi Agalya,

There are no specific fixes addressing this issue, since it should be working 
right out of the box - libcurl should be able to handle it. Personally, I 
haven't been able to reproduce it. If problems persist for you even in 2.2.3, 
we are here to help!

Regards,


Liviu Chircu

OpenSIPS Developer

http://www.opensips-solutions.com
On 24.02.2017 00:00, Ramachandran, Agalya (Contractor) wrote:
Hi Liviu,

Its great news. I have a question with respect to rest_client module.
Does async with https support is added in 2.2.3?

Regards,
Agalya

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Liviu Chircu
Sent: Thursday, February 23, 2017 12:57 PM
To: OpenSIPS users mailling list 
; OpenSIPS devel 
mailling list ; 
n...@lists.opensips.org
Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10


Hi, all!



We are happy to announce a new set of OpenSIPS minor versions, namely 2.2.3 and 
1.11.10,

incorporating the last 4 months of backports and no less than 126 commits!



While roughly half of these commits strictly relate to static code analysis 
issues

(thank you Răzvan for the Coverity initiative!), the rest of them include

important corner-case fixes in more critical areas such as the TCP layer, 
usrloc contact management,

dialog replication, dispatcher, drouting, rest_client - to name a few.



All three releases are ready for production use and even more  stable/accurate 
than before.

Since they contain the latest bug fixes, we strongly recommend you to upgrade 
your current instances.



Thank you all for your reports, fixes, pull requests and all other 
contributions to this pro

Re: [OpenSIPS-Users] Siptrace usage in 2.2.2

2017-02-27 Thread Ramachandran, Agalya (Contractor)

Hi Ionut,

Am getting the following error when I use the below config.

loadmodule "siptrace.so"
loadmodule "proto_hep.so"
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_local_ip", "LocalIP")
modparam("siptrace", "trace_id","[tid]uri=hep:HomerIP:9060;version=2;")

In route, I have the following lines added,
route{
$avp(traced_user) = "1";
$var(trace_id) = "tid";
sip_trace("$var(trace_id)", , "$avp(traced_user)");
…..
}

Let me know if anything am missing or what is causing this error?

Feb 27 18:22:53 /usr/local/sbin/opensips[2749]: CRITICAL:siptrace:msg_send: 
#012>>> using proto 8 which is not init!#012#012It seems you have hit a 
programming bug.#012Please help us make OpenSIPS better by reporting it at 
https://github.com/OpenSIPS/opensips/issues
Feb 27 18:22:53 /usr/local/sbin/opensips[2749]: 
ERROR:siptrace:trace_send_hep_duplicate: cannot send duplicate message
Feb 27 18:22:53 /usr/local/sbin/opensips[2749]: ERROR:siptrace:save_siptrace: 
Failed to duplicate with hep to <:>
Feb 27 18:22:53 /usr/local/sbin/opensips[2749]: ERROR:tm:_reply_light: failed 
to generate 200 reply when a final 200 was sent out


Regards,
Agalya
From: Ionut Ionita [mailto:ionution...@opensips.org]
Sent: Thursday, February 23, 2017 3:24 AM
To: Ramachandran, Agalya (Contractor) ; 
OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] Siptrace usage in 2.2.2


From the errors it seems like kamailio expects hep packets so you should use 
hep instead of sip in your trace_id. What is more, take care that by default 
the trace_id uses HEP version 3. Your kamailio  seems to be using 
hepv2_received function which might require version 1 or 2 of hep. So your 
trace_id definitin should look like

modparam("siptrace", "trace_id","[tid]uri=hep:homerIP:9060;version=2;")

Ionut Ionita

OpenSIPS Developer
On 02/22/2017 04:56 PM, Ramachandran, Agalya (Contractor) wrote:
Hi Ionut,

Am using the below config. Let me know if this is correct?
But am not seeing any packets in the Homer side, rather seeing errors in 
Kamailio logs, which is mentioned below.
Please help me to resolve this issue, if am doing anything wrong.
Kamailio is running and listening on port 9060.

loadmodule "siptrace.so"
loadmodule "proto_hep.so"
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_local_ip", "localIP")
modparam("siptrace", "trace_id","[tid]uri=sip:homerIP:9060;") // I tried to use 
both sip and hep

In route, am using
$var(trace_id) = "tid";
sip_trace("$var(trace_id)", , "$avp(traced_user)");

Am seeing below error in Kamailio logs, (on the Homer Side)
Feb 22 14:40:41 poc-homerserver-cmc-e-002 kamailio[9416]: ERROR: sipcapture 
[hep.c:136]: hepv2_received(): ERROR: sipcapture:hep_msg_received: unknow 
protocol [1]
Feb 22 14:40:41 poc-homerserver-cmc-e-002 kamailio[9415]: ERROR: sipcapture 
[hep.c:136]: hepv2_received(): ERROR: sipcapture:hep_msg_received: unknow 
protocol [1]
Feb 22 14:41:48 poc-homerserver-cmc-e-002 kamailio[9418]: ERROR: sipcapture 
[hep.c:86]: hep_msg_received(): ERROR: sipcapture:hep_msg_received: not 
supported version or bad length: v:[73] l:[78]
Feb 22 14:41:51 poc-homerserver-cmc-e-002 kamailio[9419]: ERROR: sipcapture 
[hep.c:86]: hep_msg_received(): ERROR: sipcapture:hep_msg_received: not 
supported version or bad length: v:[67] l:[65]

Regards,
Agalya




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

[OpenSIPS-Users] Question on memory debugging.

2017-02-27 Thread Jim DeVito

Hi All,

Looking at a possible memory issue I followed the memory debugging KB
article but I am unclear about one thing.

I've compiled 2.2.3 onto one of my production boxes with the debugging
flags and memdump on. Now I'm just waiting for the problem to happen again.
My question is. When it does happen can I restart under load and get the
info you guys need OR do I need to take the load away from the server for a
period of time to allow memory to free itself before getting the dump info?

For reference this is what I am finally getting around to looking at.

https://opensips.org/pipermail/users/2016-November/035860.html

Thanks!!

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

Re: [OpenSIPS-Users] 2.2.x and CP with json

2017-02-27 Thread Jeff Wilkie

Disregard. I was giving you the version of opensips in which the errors
occurred. My subject says 2.2.x. It was actually dev

Thanks

Jeff Wilkie
USIP Communications

On Feb 27, 2017 5:09 AM, "Bogdan-Andrei Iancu"  wrote:

> Hi Jeff,
>
> What do you mean ? I tried the "version" command via the MI tool and it
> properly works - what kind of error do you experience ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 02/24/2017 07:21 PM, Jeff Wilkie wrote:
>
> Thanks Bogdan,  I will dl 2.2.3 and retest.  This error occurred on the
> following BTW
>
> Array
> (
> [Server] => OpenSIPS (2.3.0-dev (x86_64/linux))
> )
>
>
> Jeff Wilkie
>
> On Fri, Feb 24, 2017 at 4:46 AM, Bogdan-Andrei Iancu 
> wrote:
>
>> Hi Jeff,
>>
>> There was an issue on how the MI output of the address_dump was formated
>> when using JSON. This issue was leading to an invalid JSON being returned.
>> And CP was dropping the returned JSON as not able being able to parse it.
>> If you do the direct web query, there is nothing to parse/validate the
>> JSON, so it is displayed.
>>
>> The issue was fixed in latest 2.2, so please grab the 2.2.3 and give it a
>> try please.
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 02/22/2017 08:24 PM, Jeff Wilkie wrote:
>>
>> Ok, question part 2, now that the proper module is loaded :)  From the MI
>> interface in CP, I have 1 small issue.  Using json to interface with
>> opensips, I execute the command "*address_dump" *and execute.  I receive
>> the output of address dump   |  son:127.0.0.1:/json Successfully
>> executed, no output generated.  Other commands like domain_dump work as
>> expected in the SYSTEM/MI interface.  If I bypass CP and use web direct
>> command 127.0.0.1:/json/address_dump I receive the proper output.
>> Not sure why CP provides no output from this command though.
>> The web query directly looks like this as a response when not using MI
>> via CP
>> http://10.10.20.229:/json/address_dump
>>
>> {"part": [{"value":"default", "children":{"dest": [{"value":"   8 
>> <10.10.10.99,2, 5060, 1, NULL, 151559>"}, {"value":" 19 
>> <10.10.20.193,2, 5060, 1, NULL, 151559>"}, {"value":"81 
>> <192.168.1.203,1, 5060, 1, NULL, NULL>"}]}}]}
>>
>> It's not a show stopper but bugging me why it doesn't work for that
>> command only from what I can tell from initial testing.
>> Jeff Wilkie
>>
>>> Yes, you did overlook to load the dialplan module into your OpenSIPS
>>> (the dp_reload command is prvided by this modules). Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 02/22/2017 05:56 PM, Jeff Wilkie wrote:
>>>
>>> When using the mi_json module combined with CP, it appears that not all
>>> of the functions were ported over for this interaction to complete 100%.
>>> JSON enabled in opensips-cp/config/boxes.global.inc.php only allows
>>> some commands to work.  One particular command that appears to not be
>>> working is under SYSTEM/DIALPLAN of CP when you attempt to hit "apply to
>>> server".  I receive a Sending to *json:127.0.0.1:/json
>>> * : Error code 500 (Command not found) for
>>> the dp_reload command.  If I do the same thing under the SYSTEM/PERMISSIONS
>>> page "apply to server" returns success for address_reload.   Is this a
>>> known issue?  Did I overlook something small in the config?  How do I
>>> remedy this issue?
>>> Thanks
>>> Jeff Wilkie
>>>
>>> ___
>>> Users mailing 
>>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CP 6.2 drouting Error code 500 (Internal server error)

2017-02-27 Thread Bogdan-Andrei Iancu


Hi Jeff,

Thank for this report - it seems to be a problem with the "dr_gw_status" 
MI command - not returning a reply when used to changed the GW status.
I pushed the fix on GIT repo, so if you pull from the 2.2 branch you 
should have the fix.


Thanks and regards,

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

On 02/24/2017 10:56 PM, Jeff Wilkie wrote:

Running opensips 2.2.3 with CP 6.2

When attempting to enable a GATEWAY in CP under the system/drouting 
section using the toggle button under "Memory State", the screen 
produces an "Error code 500 (Internal server error)".  The process 
does appear to execute properly though.


The httpd logs produce the following warnings only:

PHP Notice: Undefined index: gateways_search_address in 
/var/www/opensips-cp/web/tools/system/drouting/template/gateways.main.php 
on line 42, referer: 
http://xx.xx.xx.xx/cp/tools/system/drouting/gateways.php?action=disablegw&gwid=2



Opensips logs look like this on enable and disable:


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: START *** cls=(nil), 
connection=0x1c83380, url=/json/dr_gw_status, method=GET, 
versio=HTTP/1.1, upload_data[0]=(nil), *con_cls=(nil)


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:getConnectionHeader: Accept=*/*


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: accept_type=[-1]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: normalised_url=[/dr_gw_status]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_answer_to_connection: START *** cls=(nil), 
connection=0x1c83380, url=/dr_gw_status, method=GET, versio=HTTP/1.1, 
upload_data[0]=(nil), *con_cls=(nil)


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: got command=dr_gw_status


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: command=dr_gw_status accepts parameters


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: got string param [2]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: got string param [0]


*Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
ERROR:mi_json:mi_json_run_mi_cmd: failed to process the command*


*Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
ERROR:mi_json:mi_json_answer_to_connection: no reply*


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: MHD_create_response_from_data 
[0x7f0a7ddcc600:60]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: START *** cls=(nil), 
connection=0x1c83380, url=/json/dr_gw_status, method=GET, 
versio=HTTP/1.1, upload_data[0]=(nil), *con_cls=(nil)


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:getConnectionHeader: Accept=*/*


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: accept_type=[-1]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: normalised_url=[/dr_gw_status]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_answer_to_connection: START *** cls=(nil), 
connection=0x1c83380, url=/dr_gw_status, method=GET, versio=HTTP/1.1, 
upload_data[0]=(nil), *con_cls=(nil)


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: got command=dr_gw_status


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: command=dr_gw_status accepts parameters


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: but no parameters were found


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_run_mi_cmd: got mi_rpl=[0x7f0a885c4c60]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_answer_to_connection: building on page 
[0x7f0a86dc3318:0]


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_build_page: start


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_build_content: start


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_recur_write_tree: Treat as an array


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_recur_write_tree: done


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:mi_json:mi_json_build_content: done


Feb 24 15:50:41 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: MHD_create_response_from_data 
[0x7f0a86dc3318:445]





Feb 24 15:50:47 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: START *** cls=(nil), 
connection=0x1c83380, url=/json/dr_gw_status, method=GET, 
versio=HTTP/1.1, upload_data[0]=(nil), *con_cls=(nil)


Feb 24 15:50:47 opensips4 /sbin/opensips[31078]: 
DBG:httpd:getConnectionHeader: Accept=*/*


Feb 24 15:50:47 opensips4 /sbin/opensips[31078]: 
DBG:httpd:answer_to_connection: accept_type=[-1]


Feb 24 15:50:47 opensips4 /sbin/opensips[310

Re: [OpenSIPS-Users] 2.2.x and CP with json

2017-02-27 Thread Bogdan-Andrei Iancu

Hi Jeff,

just ignore them - you are probably using some older version of gcc (do
gcc -v) that is wrongly detects just cases.

Regards,

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

On 02/24/2017 09:14 PM, Jeff Wilkie wrote:

Compiling the 2.2.3, I'm seeing several warnings of similar type below:

lookup.c: In function ‘is_contact_registered’:

lookup.c:559: warning: ‘callid.len’ may be used uninitialized in this
function

lookup.c:559: warning: ‘callid.s’ may be used uninitialized in this
function

dlg_replication.c: In function ‘dlg_replicated_profiles’:

dlg_replication.c:838: warning: ‘old_name.s’ may be used uninitialized
in this function

dlg_replication.c:838: warning: ‘old_name.len’ may be used
uninitialized in this function

Is this anything to worry about?

Jeff Wilkie

On Fri, Feb 24, 2017 at 12:21 PM, Jeff Wilkie > wrote:

Thanks Bogdan, I will dl 2.2.3 and retest. This error occurred
on the following BTW

Array
(
[Server] => OpenSIPS (2.3.0-dev (x86_64/linux))
)

Jeff Wilkie

On Fri, Feb 24, 2017 at 4:46 AM, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Jeff,

There was an issue on how the MI output of the address_dump
was formated when using JSON. This issue was leading to an
invalid JSON being returned. And CP was dropping the returned
JSON as not able being able to parse it. If you do the direct
web query, there is nothing to parse/validate the JSON, so it
is displayed.

The issue was fixed in latest 2.2, so please grab the 2.2.3
and give it a try please.

Best regards,

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

On 02/22/2017 08:24 PM, Jeff Wilkie wrote:

Ok, question part 2, now that the proper module is loaded :)
From the MI interface in CP, I have 1 small issue. Using
json to interface with opensips, I execute the command
"*address_dump" *and execute. I receive the output of
address dump** | son:127.0.0.1:/json
Successfully executed, no output
generated. Other commands like domain_dump work as expected
in the SYSTEM/MI interface. If I bypass CP and use web
direct command 127.0.0.1:/json/address_dump
I receive the
proper output. Not sure why CP provides no output from this
command though.
The web query directly looks like this as a response when not
using MI via CP
http://10.10.20.229:/json/address_dump

{"part": [{"value":"default", "children":{"dest": [{"value":" 8 <10.10.10.99,2, 5060, 1, NULL, 151559>"},
{"value":" 19 <10.10.20.193,2, 5060, 1, NULL, 151559>"}, {"value":" 81 <192.168.1.203,1, 5060, 1, NULL, NULL>"}]}}]}
It's not a show stopper but bugging me why it doesn't work
for that command only from what I can tell from initial testing.
Jeff Wilkie

Yes, you did overlook to load the dialplan module into
your OpenSIPS (the dp_reload command is prvided by this
modules). Regards,

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

On 02/22/2017 05:56 PM, Jeff Wilkie wrote:

When using the mi_json module combined with CP, it
appears that not all of the functions were ported over
for this interaction to complete 100%. JSON enabled
in opensips-cp/config/boxes.gl
obal.inc.php only allows some commands
to work. One particular command that appears to not be
working is under SYSTEM/DIALPLAN of CP when you attempt
to hit "apply to server". I receive a Sending to
*json:127.0.0.1:/json
* : Error code 500 (Command
not found) for the dp_reload command. If I do the same
thing under the SYSTEM/PERMISSIONS page "apply to
server" returns success for address_reload. Is this a
known issue? Did I overlook something small in the
config? How do I remedy this issue?
Thanks
Jeff Wilkie

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

___
Users ma

Re: [OpenSIPS-Users] 2.2.x and CP with json

2017-02-27 Thread Bogdan-Andrei Iancu

Hi Jeff,

What do you mean ? I tried the "version" command via the MI tool and it
properly works - what kind of error do you experience ?

Regards,

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

On 02/24/2017 07:21 PM, Jeff Wilkie wrote:
Thanks Bogdan, I will dl 2.2.3 and retest. This error occurred on
the following BTW

Array
(
[Server] => OpenSIPS (2.3.0-dev (x86_64/linux))
)

Jeff Wilkie

On Fri, Feb 24, 2017 at 4:46 AM, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Jeff,

There was an issue on how the MI output of the address_dump was
formated when using JSON. This issue was leading to an invalid
JSON being returned. And CP was dropping the returned JSON as not
able being able to parse it. If you do the direct web query, there
is nothing to parse/validate the JSON, so it is displayed.

The issue was fixed in latest 2.2, so please grab the 2.2.3 and
give it a try please.

Best regards,

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

On 02/22/2017 08:24 PM, Jeff Wilkie wrote:

Ok, question part 2, now that the proper module is loaded :)
From the MI interface in CP, I have 1 small issue. Using json to
interface with opensips, I execute the command "*address_dump"
*and execute. I receive the output of address dump** |
son:127.0.0.1:/json Successfully
executed, no output generated. Other commands like domain_dump
work as expected in the SYSTEM/MI interface. If I bypass CP and
use web direct command 127.0.0.1:/json/address_dump
I receive the proper
output. Not sure why CP provides no output from this command
though.
The web query directly looks like this as a response when not
using MI via CP
http://10.10.20.229:/json/address_dump

{"part": [{"value":"default", "children":{"dest": [{"value":" 8 <10.10.10.99,2, 5060, 1, NULL, 151559>"},
{"value":" 19 <10.10.20.193,2, 5060, 1, NULL, 151559>"}, {"value":" 81 <192.168.1.203,1, 5060, 1, NULL, NULL>"}]}}]}
It's not a show stopper but bugging me why it doesn't work for
that command only from what I can tell from initial testing.
Jeff Wilkie

Yes, you did overlook to load the dialplan module into your
OpenSIPS (the dp_reload command is prvided by this modules).
Regards,

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

On 02/22/2017 05:56 PM, Jeff Wilkie wrote:

When using the mi_json module combined with CP, it appears
that not all of the functions were ported over for this
interaction to complete 100%. JSON enabled
in opensips-cp/config/boxes.gl obal.inc.php
only allows some commands to work. One particular command
that appears to not be working is under SYSTEM/DIALPLAN of
CP when you attempt to hit "apply to server". I receive a
Sending to *json:127.0.0.1:/json
* : Error code 500 (Command not
found) for the dp_reload command. If I do the same thing
under the SYSTEM/PERMISSIONS page "apply to server" returns
success for address_reload. Is this a known issue? Did I
overlook something small in the config? How do I remedy
this issue?
Thanks
Jeff Wilkie

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

[OpenSIPS-Users] Dialog handling in proxy authentication required method.

2017-02-27 Thread Stefan Carlsson

Hi !

I wonder how the dialog that started with a INVITE that has a respond of 407 is 
ended.

A "Normal" dialog ends with cancel/bye or via a timer but the initial INVITE I 
don't have a clue.

Anyone that knows this ...

Kind Regards

Stefan Carlsson


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

Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10

Re: [OpenSIPS-Users] Siptrace usage in 2.2.2

[OpenSIPS-Users] Question on memory debugging.

Re: [OpenSIPS-Users] 2.2.x and CP with json

Re: [OpenSIPS-Users] CP 6.2 drouting Error code 500 (Internal server error)

Re: [OpenSIPS-Users] 2.2.x and CP with json

Re: [OpenSIPS-Users] 2.2.x and CP with json

[OpenSIPS-Users] Dialog handling in proxy authentication required method.

8 matches

Site Navigation

Mail list logo

Footer information