Re: [OpenSIPS-Users] Possible Bug / Unexpected behavior with ACC.
Hi, Jim!
I tried to reproduce this but did not succeed. Is there a single leg for
the call? Are you doing manual or cdr accounting?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 08/31/2016 09:54 PM, Jim DeVito wrote:
Hi All,
Strange situation. I'm using the ACC module with Flatstore and it was
working fine until the update to 2.2.1 a couple days ago. It seems the
variable $rU is populated with hex for all 0's in very specific
situations. Namely receiving a 503 back from the carrier. This is
causing it to get put into the ACC Flat store file. See below for the
specifics and relevant configuration info. I do have a dev system I
can reproduce the problem on if there is some specific debugging you
suggest.
ACC Flatstore file line (the
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 is the
bad part. It should be 011610408287261)
INVITE|TM1AqTt8A57InEKZ75B293||20160831182524021875-339cad6d567da38f5d19c82b315b47ef|503|Service
Unavailable|1472667931|\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|115|sip-proxy02|from-c5-ns|
modparam("acc", "db_url","flatstore:/var/log/opensips/acc")
modparam("acc", "db_extra", "to_tn=$rU; etc)
$rU is the extra parameter that is supposed to be 011610408287261 but
it comes out as
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Thanks!!
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty
Hi, OpenSIPS by itself does not send any 404. If it does, it does it because you put that into the script. So, you have to look into your script and see the logical path that makes OpenSIPS to get to sending a 404 reply. You may use the script_trace : http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc43 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.08.2016 22:26, Denis wrote: Re: Opensips 2.2.1 dr_rules is empty Hello! Some time ago i wrote about a problem when Opensips began reject all calls with 404 code. Unfortunately i did not received any answer. Since that time i have made upgrade from 2.1.2 to 2.2.1 and today i have got the same problem. Opensips began rejects all calls with 404 code. Based on the information from log, i make suggest that problem began when dr_reload command has been received. And the problem has been solved, again, when the dr_reload command has been received (the period about two commands is about a couple of minutes). I please help to solve the problem. Thank you. mailto:denis7...@mail.ru Hello! Recently i begun to get such problem. Opensips rejects all calls with 404 code. I can solve the problem by making dr_reload. I tried to analyze a log and what i could found you can see in attachment. As i could understand last problem began after dr_reload. Thank you for any help. mailto:denis7...@mail.ru ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] What does mean "a=inactive"?
Dear OpenSIPS users; I'm not sure if the following question is about OpenSIPS, or SIP, or SDP, but... I have 2 softphones (Microsip) with SIP UAC: in phone A and in phone B. There is a SIP Proxy (OpenSIPS) between they too. When A calls B, I can see the SIP messages (via wireshark) and in some moment A sends a SIP UPDATE do B. The SIP UPDATE has SDP with lines like this: v=0 o=- 3681643549 3681643550 IN IP4 XXX.YYY.240.204 s=pjmedia b=AS:84 t=0 0 a=X-nat:1 m=audio 64568 RTP/AVP 110 8 101 c=IN IP4 XXX.YYY.240.204 b=TIAS:64000 a=rtpmap:110 speex/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ice-ufrag:139d7049 a=ice-pwd:692c4a80 a=rtcp:64571 IN IP4 XXX.YYY.240.204 a=candidate:Sc0a81485 1 UDP 1862270975 XXX.YYY.240.204 64568 typ srflx raddr 192.168.20.133 rport 64568 a=candidate:Sc0a81485 2 UDP 1862270974 XXX.YYY.240.204 64571 typ srflx raddr 192.168.20.133 rport 64571 a=remote-candidates:1 XXX.YYY.240.71 64993 2 XXX.YYY.240.71 64996 a=sendrecv However, if I replace the SIP Proxy with another one containing the same software (Same OpenSIPS, database, network, etc. Just hardware is different) and run the same call (A calls B), that "a=sendrecv" in SIP UPDATE changes to "a=inactive". If the peers are still the same, how could a media attribute changes? I have no idea what could cause this difference related to media attribute! Could OpenSIPS take care of this case? Could someone here give me some examples of what could cause an "a=inactive", so that I will have a point to start my analyze of the problem? I will also take a look in the SIP RFC to get some hint. Any hint will be very very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Possible Bug / Unexpected behavior with ACC.
Hi Răzvan,
It is a single leg of the call. And I am doing CDR accounting with the
flags below.
if (is_method("INVITE")) {
do_accounting("db", "cdr|failed|missed", "acc");
---
Jim DeVito
On 2016-09-01 01:43, Răzvan Crainea wrote:
Hi, Jim!
I tried to reproduce this but did not succeed. Is there a single leg
for the call? Are you doing manual or cdr accounting?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 08/31/2016 09:54 PM, Jim DeVito wrote:
Hi All,
Strange situation. I'm using the ACC module with Flatstore and it was
working fine until the update to 2.2.1 a couple days ago. It seems the
variable $rU is populated with hex for all 0's in very specific
situations. Namely receiving a 503 back from the carrier. This is
causing it to get put into the ACC Flat store file. See below for the
specifics and relevant configuration info. I do have a dev system I
can reproduce the problem on if there is some specific debugging you
suggest.
ACC Flatstore file line (the
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 is the
bad part. It should be 011610408287261)
INVITE|TM1AqTt8A57InEKZ75B293||20160831182524021875-339cad6d567da38f5d19c82b315b47ef|503|Service
Unavailable|1472667931|\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|115|sip-proxy02|from-c5-ns|
modparam("acc", "db_url","flatstore:/var/log/opensips/acc")
modparam("acc", "db_extra", "to_tn=$rU; etc)
$rU is the extra parameter that is supposed to be 011610408287261 but
it comes out as
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
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
Re: [OpenSIPS-Users] Possible Bug / Unexpected behavior with ACC.
Hi, Jim!
That was exact scenario I tried, but did not find anything. Is there any
chance I could get access to your testing environmen?
Or can we meet on IRC so we can run the debugging live?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 09/01/2016 03:20 PM, Jim DeVito wrote:
Hi Răzvan,
It is a single leg of the call. And I am doing CDR accounting with the
flags below.
if (is_method("INVITE")) {
do_accounting("db", "cdr|failed|missed", "acc");
---
Jim DeVito
On 2016-09-01 01:43, Răzvan Crainea wrote:
Hi, Jim!
I tried to reproduce this but did not succeed. Is there a single leg
for the call? Are you doing manual or cdr accounting?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 08/31/2016 09:54 PM, Jim DeVito wrote:
Hi All,
Strange situation. I'm using the ACC module with Flatstore and it
was working fine until the update to 2.2.1 a couple days ago. It
seems the variable $rU is populated with hex for all 0's in very
specific situations. Namely receiving a 503 back from the carrier.
This is causing it to get put into the ACC Flat store file. See
below for the specifics and relevant configuration info. I do have a
dev system I can reproduce the problem on if there is some specific
debugging you suggest.
ACC Flatstore file line (the
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 is the
bad part. It should be 011610408287261)
INVITE|TM1AqTt8A57InEKZ75B293||20160831182524021875-339cad6d567da38f5d19c82b315b47ef|503|Service
Unavailable|1472667931|\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|115|sip-proxy02|from-c5-ns|
modparam("acc", "db_url","flatstore:/var/log/opensips/acc")
modparam("acc", "db_extra", "to_tn=$rU; etc)
$rU is the extra parameter that is supposed to be 011610408287261
but it comes out as
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Topology Hiding module Call_ID encryption
Hi Adrian,
After some digging I found that the issue was fixed in March 2016 :
https://github.com/OpenSIPS/opensips/commit/dc229a1ac6312cba9db75e49bc09b931a549375f
So, update your 2.1 to the latest minor release (or git code) and it
should be fine :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.08.2016 21:36, Adrian Fretwell wrote:
Hi Bogdan,
Yes it happens every time the encrypted Call-ID ends up with an equals
sign, but I have worked around it with a transformation that so far
has not failed:
$(TH_callee_callid{re.subst,/=/-/g})
Kind regards,
Adrian Fretwell
On 07/08/16 18:50, Bogdan-Andrei Iancu wrote:
Hi Adrian,
The code (for the $TH_callee_callid variable) should convert the
internal '=' into '-', but it looks like it fails. Is this happening
all the time for you ? (I'm just looking for an easy way to reproduce).
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05.08.2016 18:14, Adrian Fretwell wrote:
Hello, may I ask for a little help?
Using Topology Hiding Module in Opensips 2.1.2. I'm finding that
looking at a tcpdump the Call_ID looks like this:
LTXCH01_c1FNUVlRXkNvaA--
But when I log $TH_callee_callid "xlog("L_INFO", "sequential: Callee
side callid is $TH_callee_callid");" the Call_ID looks like this:
LTXCH01_c1FNUVlRXkNvaA==
Notice the dashes are replaced with equals signs.
If I rewrite the Call-ID for NOTIFY messages with the value of
$TH_callee_callid the tcpdump will show the Call-ID with the equals
signs (==) not the dashes
if (is_method("NOTIFY")) {
if( !remove_hf("Call-ID")) {
sl_send_reply("503", "Service Unavailable");
xlog("L_INFO", "sequential: could not remove header");
exit;
}
append_hf("Call-ID: $TH_callee_callid\r\n", "To");
}
Could this be a bug or am I doing something silly?
Kind regards,
Adrian Fretwell
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty
Hello, Bogdan I am sorry that i did not describe the problem more clearly. 404 opensips sends because in opensips.cfg i wrote a logic that if in dr_rules opensips finds no rules for routing it must send 404. And the problem i think is there. Opensips began rejects all calls with 404, i.e. it could not find any rules in dr_rules table. Everthing began fine after fifo dr_reload command execution, i.e. after dr_rules updating. -- mailto:denis7...@mail.ru Hi, OpenSIPS by itself does not send any 404. If it does, it does it because you put that into the script. So, you have to look into your script and see the logical path that makes OpenSIPS to get to sending a 404 reply. You may use the script_trace : http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc43 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 30.08.2016 22:26, Denis wrote: Re: Opensips 2.2.1 dr_rules is empty Hello! Some time ago i wrote about a problem when Opensips began reject all calls with 404 code. Unfortunately i did not received any answer. Since that time i have made upgrade from 2.1.2 to 2.2.1 and today i have got the same problem. Opensips began rejects all calls with 404 code. Based on the information from log, i make suggest that problem began when dr_reload command has been received. And the problem has been solved, again, when the dr_reload command has been received (the period about two commands is about a couple of minutes). I please help to solve the problem. Thank you. mailto:denis7...@mail.ru Hello! Recently i begun to get such problem. Opensips rejects all calls with 404 code. I can solve the problem by making dr_reload. I tried to analyze a log and what i could found you can see in attachment. As i could understand last problem began after dr_reload. Thank you for any help. mailto:denis7...@mail.ru ___ 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
