[OpenSIPS-Users] Low Latency Message Queue Recommendations
What are the recommended solutions for posting data to an external system with the lowest latency? Today we're using a Redis list to push data from OpenSIPS and pull it from Redis using Logstash. These are call detail records that need to reach our OpenSearch index with minimum delay. We have Redis running in memory-only mode to reduce latency, largely because the underlying storage is a very busy SAN. The current pipeline works until there is a disruption to Logstash or OpenSearch. If the disruption is not corrected quickly enough, Redis runs out of memory and we lose data. If Redis crashes, OpenSIPS itself breaks down. Is there a more robust solution for getting things to OpenSearch? Latency is the goal, but we need to tolerate disruption without data loss. Calvin Ellison Systems Architect calvin.elli...@voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] question on call handling.
Johan, is there also a PRACK happening in this call flow, but omitted from your diagram? The SDP offer/answer model is extended a bit by reliable provisional response messages. The Offer/Answer Model and PRACK https://datatracker.ietf.org/doc/html/rfc3262#section-5 Calvin Ellison Systems Architect calvin.elli...@voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. On Fri, Oct 1, 2021 at 8:07 AM johan wrote: > Scenario is this > > > A ---> OPENSIPS and rtpengine -> B > > INV -> > INV > > 183 sdp < <183 sdp > > < 480 > > > -> Voicemail > > > INV > > < 200 with diff sdp > > 200 with diff sdp < > > would giving rtpengine the port latching option fix this ? > > > wkr, > On 1/10/2021 16:41, Ben Newlin wrote: > > No, this is not allowed by the specification, though some devices do > handle it. > > > > https://datatracker.ietf.org/doc/html/rfc3261#section-13.2.1 > > > > Ben Newlin > > > > *From: *Users > on behalf of johan > > *Date: *Friday, October 1, 2021 at 10:35 AM > *To: *OpenSIPS users mailling list > > *Subject: *[OpenSIPS-Users] question on call handling. > > Dears, > > > this is more a general sip question. when establishing a dialog is it > then allowed to change the sdp that you have sent in 183 to somehting > else in 200 Ok ? > > > wkr, > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ > 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 > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] add SDP to 200ok without SDP
This doesn't answer your question: I'm curious if that is a broken behavior from the party sending the 200 without SDP. It is my understanding that all subsequent 18x and the 200 must use the same SDP if no UPDATE has taken place in the meantime. Please, correct me if that is a misunderstanding. Calvin Ellison Systems Architect calvin.elli...@voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. On Wed, Sep 15, 2021 at 10:02 AM Mario San Vicente wrote: > Hello Everyone, > > has anyone face the following issue: customer not accepting 200ok with no > SDP as valid. Previously an 18[03] with SDP was sent, but the final answer > is 200 ok with no SDP from the termination leg. So i was wondering if > there is a way to store the SDP and the append it to answering 200ok. > > Client --> Opensips as Proxy + rtpproxy --> Termination Leg > > > Thank you in advance. > Mario SV > ___ > 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] fr_timeout CANCEL message sent to timed out dispatcher endpoint IP
Despite what the RFC states, some SBCs (Sansay) will send CANCEL even if no provisional response has been received. This can prevent billing disputes in cases where a 200 OK to the INVITE would have been sent but not received. It can also be helpful in troubleshooting to see whether the far end responds with 481 to the CANCEL, 487 Request Terminated to the INVITE with 200 to the CANCEL, or not at all. Calvin Ellison Systems Architect calvin.elli...@voxox.com <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. On Wed, Jun 30, 2021 at 8:59 AM John Quick wrote: > Ben, > > Yes, you're right. Section 9.1 of RFC3261 says "If no provisional response > has been received, the CANCEL request MUST NOT be sent" > > So then it is a question the developers will need to answer, although from > a > practical point of view I doubt that it would cause a problem for the > reasons I gave. > > John Quick > Smartvox Limited > > > From: Ben Newlin > > Sent: 30 June 2021 16:25 > > To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list > > > Cc: solar...@one-n.co.uk > > Subject: Re: [OpenSIPS-Users] fr_timeout CANCEL message sent to timed out > dispatcher endpoint IP > > > > I'm pretty sure the RFCs state that a CANCEL should only be sent if some > response, usually 100 Trying, has been received. This is to avoid the > possibility of the INVITE and CANCEL > being received out of order at the > destination. > > > > Ben Newlin > > > ___ > 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] Generate CANCEL on 180
Once you receive 200 it is too late to CANCEL. You will need to ACK the 200
and then BYE the call.
Regards,
*Calvin Ellison*
Systems Architect
calvin.elli...@voxox.com
+1 (213) 285-0555
---
*voxox.com <http://www.voxox.com/> *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]
On Tue, Apr 20, 2021 at 1:14 PM Antonis Psaras wrote:
> I did the following
>
> if (t_check_status("180"))
> {
> t_cancel_branch();
>drop;
> }
>
> But there is an issue.
>
> When 180 is followed by 200 instantly, the CANCEL is not working as
> expected.
>
> When I add a delay on Answer ie 1sec then CANCEL works.
>
> Any suggestion?
>
> Antonis Psaras
>
> -Original Message-
> From: Users On Behalf Of Kingsley Tart
> Sent: Τρίτη, 20 Απριλίου 2021 20:10
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] Generate CANCEL on 180
>
> Firstly, I'm new to OpenSIPS so treat my comments accordingly.
>
> But, can you do something in an onreply route?
>
> eg, in a test setup I have, when I get an INVITE I do this:
>
> create_dialog("pPB");
> t_on_reply("doodle");
>
> (I can't remember whether the dialog is needed for this)
>
> and then I have this:
>
> onreply_route[doodle] {
> # expect $T_reply_code to likely first be 100
> # then 180 or 183 for a progressing call
> # 200 when call is answered
> # or failure code (eg 4xx) or whatever
> if (t_check_status("^1[0-9][0-9]$")) {
> switch ($T_reply_code) {
> case 180: $acc_extra(t_ringing) = $Ts; break;
> case 183: $acc_extra(t_progress) = $Ts; break;
> }
> } else if (t_check_status("^2[0-9][0-9]$")) {
> $acc_extra(t_answer) = $Ts;
> } else {
> xlog("Something else\n");
> }
> }
>
> so when a 180 is received, it calls the above route function. Could you
> send a CANCEL from there?
>
> Cheers,
> Kingsley.
>
> On Tue, 2021-04-20 at 16:55 +0300, Antonis Psaras wrote:
> > Dear all
> >
> > I am trying to create a service which will generate missed calls. In
> > order to be more accurate, I want to CANCEL the request when 180 is
> > received.
> >
> > The scenario is the following
> >
> > Asterisk Invite -> OpenSIPs -> Carrier
> >
> > Carrier 183 -> OpenSIPs -> Asterisk
> >
> > Carrier 180 -> OpenSIPs
> >
> > OpenSIPs Cancel -> Carrier
> >
> >
> > Is that possible to be done from script without external app?
> >
> > Regards
> >
> > ___
> > 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Gracefully handling bad from header
I would like to more gracefully handle non-RFC compliant From headers. Is it possible to fix them with regex or a string replacement so I can process them? Most often the misbehavior is a space in the user part: #015#012To: #015#012From: ;tag=sansay2313795380rdb15209#015#012Call-ID: ers-1718949283-0-660497714@redact#015#012CSeq: 1 INVITE#015#012Contact: #015#012P-Asserted-Identity: #015#012Remote-Party-ID: ;privacy=off;screen=yes#015#012Max-Forwards: 63#015#012Content-Length: 0#015#012#015#012 Regards, *Calvin Ellison* Systems Architect calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] regex value too long OR how to properly quote/escape Redis raw query
Any suggestion for resolving "regex value too long" when using the re.subst
transformation?
Any way to fix the Redis client so it does not break on spaces when the
value is single-quoted? From what I understand, modern Redis servers
support single-quoted strings.
On Sun, Apr 4, 2021 at 1:09 PM Calvin Ellison
wrote:
> I need to post a JSON object to Elsasticsearch, and I am using Redis as a
> queue via cache_raw_query and the RPUSH command. The JSON object contains
> spaces, which appears to cause the OpenSIPS Redis client to break the
> string into pieces and push each of them to Redis separately.
>
> 1. Maybe I'm not quoting correctly?
> RPUSH snarf-cdrs 'object_goes_here'
>
> It doesn't seem to matter if I enclose the Resid list value in single
> quotes or not.
>
> I initially resolved this problem by escaping spaces with their escaped
> Unicode equivalent. This has the desired result in Elasticsearch, but now
> my JSON object is bigger and the regex replacement fails. Is there a
> workaround?
>
> $var(replaceSpace) = "/ /\\\u00a0/sg";
> $avp(body) = $(json_compact(body){re.subst,$var(replaceSpace)});
>
> DBG:core:tr_eval_re: Trying to apply regexp [/ /\\u00a0/sg] on :
> [{"index":"snarf-2021.04.03","time":"2021-04-03T03:34:18","TID":"006508","BLOCKED":1,"SVCPORT":"8.38.43.182","CALLID":"bf0ea503853749618c747a995b7f0102","SOURCEIP":"192.168.47.130","MEDIAIP":"192.168.47.130","ANI":"2132850555","DNIS":"2132850555","SNARF":"NONE","FRAUD":0,"TCPA":0,"NEIGHLATA":"1","NEIGHRC":"1","NEIGHBLOCK":"1","NEIGHPREFIX":"1","ATFN":0,"BTFN":0,"ALRN":"2132620105","AState":"CA","ANetwork":"
> BANDWIDTH.COM CLEC- LLC - CA","AOCN":"979E","ARatecenter":"LSAN DA
> 01","AClass":"L","ALATA":"730","ACountry":"US","AReachable":"1","AReason":"SS7
> ID","ADNC":"0","AGood":"1","ADNO":"0","BLRN":"2132620105","BState":"CA","BNetwork":"
> BANDWIDTH.COM CLEC- LLC - CA","BOCN":"979E","BRatecenter":"LSAN DA
> 01","BClass":"L","BLATA":"730","BCountry":"US","BReachable":"1","BReason":"SS7
> ID","BDNC":"0","BGood":"1","BDNO":"0","TRIGGERS":["neighBlock"],"RULES":{"tid":"006508","rep":"none","fraud":0,"tcpa":95,"aclass":false,"adno":false,"atfn":false,"bclass":false,"bdnc":false,"bgood":false,"neighBlock":true,"neighLata":false,"neighRc":false,"neighPrefix":false}}]
> Apr 3 03:34:18 ve-lab /usr/sbin/opensips[14291]: DBG:core:tr_eval_re: we
> must compile the regexp
> Apr 3 03:34:18 ve-lab /usr/sbin/opensips[14291]: DBG:core:subst_parser:
> ok, se is 0x7f8737c1f0e8
> Apr 3 03:34:18 ve-lab /usr/sbin/opensips[14291]: ERROR:core:tr_eval_re:
> regex value too long
> [{"index":"snarf-2021.04.03","time":"2021-04-03T03:34:18","TID":"006508","BLOCKED":1,"SVCPORT":"8.38.43.182","CALLID":"bf0ea503853749618c747a995b7f0102","SOURCEIP":"192.168.47.130","MEDIAIP":"192.168.47.130","ANI":"2132850555","DNIS":"2132850555","SNARF":"NONE","FRAUD":0,"TCPA":0,"NEIGHLATA":"1","NEIGHRC":"1","NEIGHBLOCK":"1","NEIGHPREFIX":"1","ATFN":0,"BTFN":0,"ALRN":"2132620105","AState":"CA","ANetwork":"
> BANDWIDTH.COM CLEC- LLC - CA","AOCN":"979E","ARatecenter":"LSAN DA
> 01","AClass":"L","ALATA":"730","ACountry":"US","AReachable":"1","AReason":"SS7
> ID","ADNC":"0","AGood":"1","ADNO":"0","BLRN":"2132620105","BState":"CA","BNetwork":"
> BANDWIDTH.COM CLEC- LLC - CA","BOCN":"979E","BRatecenter":"LSAN DA
> 01","BClass":"L","BLATA":"730","BCountry":"US","BReachable":"1","BReason":"SS7
> ID","BDNC":"0","BGood":"1","BDNO":"0","TRIGGERS":["neighBlock"],"RULES":{"tid":"006508","rep":"none","fraud":0,"tcpa":95,"aclass":false,"adno":false,"atfn":false,"bclass":false,"bdnc":false,"bgood":false,"neighBlock":true,"neighLata":false,"neighRc":false,"neighPrefix":false}}]
>
> opensips 3.1.1
> Ubuntu 18.04.5 LTS
> Linux ve-lab 4.15.0-140-generic #144-Ubuntu SMP Fri Mar 19 14:12:35 UTC
> 2021 x86_64 x86_64 x86_64 GNU/Linux
>
>
> Regards,
>
> *Calvin Ellison*
> Systems Architect
> calvin.elli...@voxox.com
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] regex value too long OR how to properly quote/escape Redis raw query
I need to post a JSON object to Elsasticsearch, and I am using Redis as a
queue via cache_raw_query and the RPUSH command. The JSON object contains
spaces, which appears to cause the OpenSIPS Redis client to break the
string into pieces and push each of them to Redis separately.
1. Maybe I'm not quoting correctly?
RPUSH snarf-cdrs 'object_goes_here'
It doesn't seem to matter if I enclose the Resid list value in single
quotes or not.
I initially resolved this problem by escaping spaces with their escaped
Unicode equivalent. This has the desired result in Elasticsearch, but now
my JSON object is bigger and the regex replacement fails. Is there a
workaround?
$var(replaceSpace) = "/ /\\\u00a0/sg";
$avp(body) = $(json_compact(body){re.subst,$var(replaceSpace)});
DBG:core:tr_eval_re: Trying to apply regexp [/ /\\u00a0/sg] on :
[{"index":"snarf-2021.04.03","time":"2021-04-03T03:34:18","TID":"006508","BLOCKED":1,"SVCPORT":"8.38.43.182","CALLID":"bf0ea503853749618c747a995b7f0102","SOURCEIP":"192.168.47.130","MEDIAIP":"192.168.47.130","ANI":"2132850555","DNIS":"2132850555","SNARF":"NONE","FRAUD":0,"TCPA":0,"NEIGHLATA":"1","NEIGHRC":"1","NEIGHBLOCK":"1","NEIGHPREFIX":"1","ATFN":0,"BTFN":0,"ALRN":"2132620105","AState":"CA","ANetwork":"
BANDWIDTH.COM CLEC- LLC - CA","AOCN":"979E","ARatecenter":"LSAN DA
01","AClass":"L","ALATA":"730","ACountry":"US","AReachable":"1","AReason":"SS7
ID","ADNC":"0","AGood":"1","ADNO":"0","BLRN":"2132620105","BState":"CA","BNetwork":"
BANDWIDTH.COM CLEC- LLC - CA","BOCN":"979E","BRatecenter":"LSAN DA
01","BClass":"L","BLATA":"730","BCountry":"US","BReachable":"1","BReason":"SS7
ID","BDNC":"0","BGood":"1","BDNO":"0","TRIGGERS":["neighBlock"],"RULES":{"tid":"006508","rep":"none","fraud":0,"tcpa":95,"aclass":false,"adno":false,"atfn":false,"bclass":false,"bdnc":false,"bgood":false,"neighBlock":true,"neighLata":false,"neighRc":false,"neighPrefix":false}}]
Apr 3 03:34:18 ve-lab /usr/sbin/opensips[14291]: DBG:core:tr_eval_re: we
must compile the regexp
Apr 3 03:34:18 ve-lab /usr/sbin/opensips[14291]: DBG:core:subst_parser:
ok, se is 0x7f8737c1f0e8
Apr 3 03:34:18 ve-lab /usr/sbin/opensips[14291]: ERROR:core:tr_eval_re:
regex value too long
[{"index":"snarf-2021.04.03","time":"2021-04-03T03:34:18","TID":"006508","BLOCKED":1,"SVCPORT":"8.38.43.182","CALLID":"bf0ea503853749618c747a995b7f0102","SOURCEIP":"192.168.47.130","MEDIAIP":"192.168.47.130","ANI":"2132850555","DNIS":"2132850555","SNARF":"NONE","FRAUD":0,"TCPA":0,"NEIGHLATA":"1","NEIGHRC":"1","NEIGHBLOCK":"1","NEIGHPREFIX":"1","ATFN":0,"BTFN":0,"ALRN":"2132620105","AState":"CA","ANetwork":"
BANDWIDTH.COM CLEC- LLC - CA","AOCN":"979E","ARatecenter":"LSAN DA
01","AClass":"L","ALATA":"730","ACountry":"US","AReachable":"1","AReason":"SS7
ID","ADNC":"0","AGood":"1","ADNO":"0","BLRN":"2132620105","BState":"CA","BNetwork":"
BANDWIDTH.COM CLEC- LLC - CA","BOCN":"979E","BRatecenter":"LSAN DA
01","BClass":"L","BLATA":"730","BCountry":"US","BReachable":"1","BReason":"SS7
ID","BDNC":"0","BGood":"1","BDNO":"0","TRIGGERS":["neighBlock"],"RULES":{"tid":"006508","rep":"none","fraud":0,"tcpa":95,"aclass":false,"adno":false,"atfn":false,"bclass":false,"bdnc":false,"bgood":false,"neighBlock":true,"neighLata":false,"neighRc":false,"neighPrefix":false}}]
opensips 3.1.1
Ubuntu 18.04.5 LTS
Linux ve-lab 4.15.0-140-generic #144-Ubuntu SMP Fri Mar 19 14:12:35 UTC
2021 x86_64 x86_64 x86_64 GNU/Linux
Regards,
*Calvin Ellison*
Systems Architect
calvin.elli...@voxox.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to manage REFER Packet
Hi Donat You're right, I did mean a 3xx response, not a made-up redirect method. My apologies, we use Redirect internally as the text of our 3xx codes and I confused myself. I blame the rest on, um, brain fog? My point to the original question of the author is whether REFER is really what they want, or if a 3xx is a better solution for their scenario. As you pointed out, there's a lot more involved in supporting REFER. If that's all Freeswitch will give them, they have a bit of a hill to climb, but it's doable. Sorry again for creating any confusion. Regards, *Calvin Ellison* Systems Architect calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Thu, Mar 11, 2021 at 9:13 AM Donat Zenichev wrote: > Good day Calvin. > There is no SIP method called "REDIREDCT" as you say. > Currently there are 6 general methods defined in RFC 3261, you can see > them here: https://tools.ietf.org/html/rfc3261#section-27.4 > > And of course a list of SIP specifications (documents) including following > methods: PRACK, SUBSCRIBE, NOTIFY, PUBLISH, REFER, MESSAGE, UPDATE > which are defined in the list of other RFC documents. > > But there is no method which you called. So that, please do not confuse > the community with a wrong terminology. > > The thing you are referring to (if I managed to understand this correctly) > is just a basic processing of 3XX type of responses (Redirection server). > This block of response codes is commonly called as redirection responses. > Response codes are not the same thing as SIP methods. > And most of all would be "302 Moved Temporarily" used, to provide Contact > information where to find the requested side. Depends on setup. > > This however seems to be completely not related to the original question > of the author. > > Best regards. > > > On Thu, Mar 11, 2021 at 6:26 PM Calvin Ellison > wrote: > >> Is it your intention to transfer an established call, or do you really a >> redirect? >> >> In the case of a redirect you're actually looking for the REDIREDCT >> method not the REFER method. Instead of returning a 200 OK then REFER, you >> would return a 300 REDIRECT with the new URI in the Contact header. That >> completes the first dialogue and then you start a new dialogue to the >> destination provided by the REDIRECT. >> >> >> Regards, >> >> >> Calvin Ellison >> Systems Architect >> calvin.elli...@voxox.com >> +1 (213) 285-0555 >> >> --- >> voxox.com >> 5825 Oberlin Drive, Suite 5 >> San Diego, CA 92121 >> >> On Sun, Mar 7, 2021, 23:12 Vinayak Makwana >> wrote: >> >>> Hello Everyone, >>> I would like to manage REFER packet with opensips script >>> In my case i want manage REFER packet like whenever i opensips proxy >>> getting REFER packet from freeswitch at that time i need to convert this >>> REFER packet into INVITE packet from opensips script and send to the >>> endpoint. >>> Is their any possibilities where I can manage this thing in opensips >>> 3.1.x ? >>> Please suggest me. >>> >>> My scenario like this: >>> >>> AopensipsB(Freswitch) >>> | -INVITE --->| ---INVITE--> | >>> >>> | <-200OK ---| <---200OK--| >>> | <-INVITE --- | <---REFER| >>> >>> *Disclaimer* >>> In addition to generic Disclaimer which you have agreed on our website, >>> any views or opinions presented in this email are solely those of the >>> originator and do not necessarily represent those of the Company or its >>> sister concerns. Any liability (in negligence, contract or otherwise) >>> arising from any third party taking any action, or refraining from taking >>> any action on the basis of any of the information contained in this email >>> is hereby excluded. >>> >>> *Confidentiality* >>> This communication (including any attachment/s) is intended only for the >>> use of the addressee(s) and contains information that is PRIVILEGED AND >>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >>> of this communication is prohibited. Please inform originator if you have >>> received it in error. >>> >>> *Caution for viruses, malware etc.* >>> This communication, including any a
Re: [OpenSIPS-Users] How to manage REFER Packet
Is it your intention to transfer an established call, or do you really a redirect? In the case of a redirect you're actually looking for the REDIREDCT method not the REFER method. Instead of returning a 200 OK then REFER, you would return a 300 REDIRECT with the new URI in the Contact header. That completes the first dialogue and then you start a new dialogue to the destination provided by the REDIRECT. Regards, Calvin Ellison Systems Architect calvin.elli...@voxox.com +1 (213) 285-0555 --- voxox.com 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 On Sun, Mar 7, 2021, 23:12 Vinayak Makwana wrote: > Hello Everyone, > I would like to manage REFER packet with opensips script > In my case i want manage REFER packet like whenever i opensips proxy > getting REFER packet from freeswitch at that time i need to convert this > REFER packet into INVITE packet from opensips script and send to the > endpoint. > Is their any possibilities where I can manage this thing in opensips > 3.1.x ? > Please suggest me. > > My scenario like this: > > AopensipsB(Freswitch) > | -INVITE --->| ---INVITE--> | > > | <-200OK ---| <---200OK--| > | <-INVITE --- | <---REFER| > > *Disclaimer* > In addition to generic Disclaimer which you have agreed on our website, > any views or opinions presented in this email are solely those of the > originator and do not necessarily represent those of the Company or its > sister concerns. Any liability (in negligence, contract or otherwise) > arising from any third party taking any action, or refraining from taking > any action on the basis of any of the information contained in this email > is hereby excluded. > > *Confidentiality* > This communication (including any attachment/s) is intended only for the > use of the addressee(s) and contains information that is PRIVILEGED AND > CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying > of this communication is prohibited. Please inform originator if you have > received it in error. > > *Caution for viruses, malware etc.* > This communication, including any attachments, may not be free of viruses, > trojans, similar or new contaminants/malware, interceptions or > interference, and may not be compatible with your systems. You shall carry > out virus/malware scanning on your own before opening any attachment to > this e-mail. The sender of this e-mail and Company including its sister > concerns shall not be liable for any damage that may incur to you as a > result of viruses, incompleteness of this message, a delay in receipt of > this message or any other computer problems. > ___ > 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] Getting call analytics to Elasticsearch
Is there any best practice or standard method of getting data from OpenSIPS to Elasticsearch? The scenario is an internal call filter that will block or permit a call. e.g. 503 route advance or 603 stop route. Checks are performed against pre-populated caches and database queries, and we want the results of those checks to ultimately reach Elasticsearch. I'd prefer to avoid file-based things like syslog + logstash. The "OpenSIPS and BigData" presentation from 2016 suggested using the Elasticsearch REST API directly with async(rest_post()) or RabbitMQ. Our experience with Elasticsearch indicates it will not keep up with our call volume without a message queue, and now I'm seeing talking about Kafka being the new standard for this. Is this a solved problem? Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
I attempted to reproduce the original breakdown around 3000 CPS using the default 212992 byte receive buffer and could not, which tells me I broke a cardinal rule of load testing and changed more than one thing at a time. Also, don't do load testing when tired. I suspect that I had also made a change to the sipp scenario recv/sched loops, or I had unknowingly broken something while checking out the tuned package. I deeply appreciate Alex's instance that I was wrong and to keep digging. I am happy to retract my claim regarding "absolutely terrible sysctl defaults". Using synchronous/blocking DB queries, the 8-core server reached 14,000 CPS, at which point I declared it fixed and went to bed. It could probably go higher: there's only one DB query with a <10ms response time, Memcache for the query response, and some logic to decide how to respond. There's only a single non-200 final response, so it's probably as minimalist as it gets. If anyone else is trying to tune their setup, I think Alex's advice to "not run more than 2 * (CPU threads) [children]" is the best place to start. I had inherited this project from someone else's work under version 1.11 and they had used 128 children. They were using remote DB servers with much higher latency than the local DBs we have today, so that might have been the reason. Or they were just wrong to being with. The Description for Asynchronous Statements is extremely tempting and was what started me down that path; it might be missing a qualification that Async can be an improvement for slow blocking operations, but the additional overhead may be a disadvantage for very fast blocking operations. Thank you to everyone who responded to this topic. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com On Fri, Jun 12, 2020 at 6:42 PM Alex Balashov wrote: ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
On Fri, Jun 12, 2020 at 5:23 PM Alex Balashov wrote: > One should see the forest for the trees, instead of cultivating a myopic > preoccupation with short-term, stop-gap solutions. > Understanding that text lacks tone, this a rather offputting comment for a mailing list intended to help users. I appreciate your time and feedback, there's no need to be insulting. Perhaps you could stop assuming what my preoccupations and scope of vision are and concentrate on the problem and the solution? The question now is why increasing buffers made any difference at all. You suggested to "Monitor your receive queue scrupulously at a very high timing resolution". How do I do this? You propose there is a pathological issue and the increased buffer size is masking it. How do I determine what that issue is? I've asked repeatedly about children, shared memory, process memory, timer_partitions, etc. but the only answers have been "try more". I've been trying more and less of these things two weeks and changing the buffers was the only thing that appeared to have any immediate impact. How do I know when enough is enough versus too much? Note, there have been no memory-related log messages. The 16-thread servers have 48GB RAM and the 8-thread servers have 16GB. I'm happy to give all that to OpenSIPS once I know the right way to carve it up. Should I even be using 2.4? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
On Fri, Jun 12, 2020 at 4:35 PM David Villasmil < david.villasmil.w...@gmail.com> wrote: > Basically, the application is not processing the received packets as > quickly as it should, so the kernel stores the packets in the buffer so it > doesn’t have to throw them away. > > It’s not so difficult to understand. If this is happening all the time, > you won’t solve this by making the buffer bigger. You solve this by > figuring out why the application is not processing the packets fast enough. > That's been the point of this discussion. Unfortunately, there answers so far have added to up "keep changing settings until you find what works best" and "buffers are a Ponzi scheme" despite and immediate 3x performance increase. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
Agreed it's not a big deal that the kernel default is 212992, it's that value because it's enough for lots of things. It is a big deal not being aware of its effect on things could be the difference between less than 3,000 CPS and more than 10,000. On Fri, Jun 12, 2020 at 4:50 PM David Villasmil < david.villasmil.w...@gmail.com> wrote: > Keep in mundo the don’t make Ubuntu for SIP applications, which have their > own idiosyncrasies. They make it general purpose. So finding a value that > doesn’t work perfectly with what you need for this very specific > application, is not a big deal. > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
I doubt the system will be using all of that buffer. I also don't know if the issue was in the receive buffer or send buffer since I changed both at once. Many resources are available online from people who have already done much more scientific testing that indicate the default values should be increased for certain applications, which is the reason I changed it to begin with. There's no one-size-fits all for server configurations, and what works for this UDP application with a small number of clients might not work well for a different application with many TCS connections. "absolutely terrible" may be too strong of a way to put it, but that the before and after don't lie. On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov wrote: > But increasing the depth of the queue by 78x (if I'm not mistaken, > 212992 is the default--at least, it is on all my CentOS 7.x and 8.x > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
I think the important point here is that the receive buffers are used to hold received data until it is read by the application. In fact, too small of a receive buffer would cause packets to be discarded outright, regardless of how fast the application can respond. Not knowing how large of a buffer is needed was the problem, not the raw processing power. It doesn't matter how fast I can eat if the server only has very small plates to bring the food every trip from the kitchen. On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov wrote: > Perhaps a simpler way look at it: buffers. It's in the name - they > buffer things. > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
I don't disagree that there is a physical limit to what any hardware can achieve. However, there was a dramatic difference between the default setting and the increased setting. I have no explanation for this, as I am not a kernel or network developer. I'm happy to run the load test again both ways and see if there was any difference in response times. On Fri, Jun 12, 2020 at 3:51 PM Alex Balashov wrote: > There's no free lunch, but it seems like you and others want one. :-) > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
I noticed a way-too-small receive buffer value in the OpenSIPS startup messages and it turns out that a fresh Ubuntu 18 Server install has absolutely terrible sysctl defaults for high-performance networking. I got my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a spread of all dips in non-async mode just by setting the following to match "maxbuffer=16777216": net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 Does OpenSIPS have guidelines for sysclt and other OS parameters? Async requires the TM module which adds additional overhead and memory > allocation. According to with the docs: "By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory." So which is it? When should async be used, and when should async not be used? One can only invest so many hours in load testing combinations of sync/async, the number of children, timer_partitions, etc. Some fuzzy math based on CPU core count, SpecInt Rate, BogoMIPS, etc. would be a great starting point. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
We've checked our F5 BigIP configuration and added a second database server
to the pool. Both DBs have been checked for max connections, open files,
etc. Memcached has been moved to a dedicated server. Using a SIPp scenario
for load testing from a separate host, things seem to fall apart on
OpenSIPS around 3,000 CPS with every CPU core at or near 100% and no logs
indicating fallback to sync/blocking mode. Both databases barely noticed
the few hundred connections. Does this seem reasonable for a dual CPU
server with 8 cores and 16 threads?
https://ark.intel.com/content/www/us/en/ark/products/47925/intel-xeon-processor-e5620-12m-cache-2-40-ghz-5-86-gt-s-intel-qpi.html
What is the OpenSIPS opinion on Hyper-Threading?
Is there a way to estimate max CPS based on SPECrate, BogoMIPS, or some
other metric?
I would love to know if my opensips.cfg has any mistakes, omissions, or
inefficiencies. Is there a person or group who does sanity checks?
What should I be looking at within OpenSIPS during a load test to identify
bottlenecks?
I'm still looking for guidance on the things below, especially children
vs timer_partitions:
Is there an established method for fine-tuning these things?
> shared memory
> process memory
> children
> db_max_async_connections
> listen=... use_children
> modparam("tm", "timer_partitions", ?)
What else is worth considering?
Regards,
Calvin Ellison
Senior Voice Operations Engineer
calvin.elli...@voxox.com
On Thu, Jun 4, 2020 at 5:18 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:
>
> Maybe you are hitting the max connections? How many connections are there
when it starts to show those errors?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Maybe it's a bug
+1 to ceil() rounding, and stating in the documentation that this is the method used. Alternatively, some new option to specify ceiling, floor, round, truncate, etc. I can back up SM's claim that a single billing interval discrepancy will cost people real money. Clarification in the documentation will help people avoid that pitfall. I also concur with Vlad that the duration in milliseconds is preferable. The millisecond data can help to settle any billing disputes from clients or vendors, and it demystifies CDRs for everyone: one field for actual call duration in ms, another field for call duration after rounding, and/or one for the final charged call duration after rounding and billing interval. Regards, Calvin Ellison Senior Voice Operations Engineer calvin.elli...@voxox.com On Tue, Jun 9, 2020 at 12:14 PM Johan De Clercq wrote: > > Upwards seems best. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
On Thu, Jun 4, 2020 at 5:18 PM David Villasmil wrote: > > Maybe you are hitting the max connections? How many connections are there > when it starts to show those errors? I'd definitely benefit from a monitor on this. Is this available from within opensips? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries
> A) Is the LRN database located locally on the OpenSIPs box or is it remote? We are using an F5 BIG-IP to proxy a pool of database servers. Opensips is showing two connection-related errors: Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: ERROR:db_mysql:db_mysql_connect: driver error(2013): Lost connection to MySQL server at 'reading authorization packet', system error: 110 Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: ERROR:db_mysql:db_mysql_new_connection: initial connect failed Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: ERROR:core:db_init_async: failed to open new DB connection on mysql://:@10.0.5.38:0/ Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: INFO:db_mysql:db_mysql_async_raw_query: Failed to open new connection (current: 1 + 8). Running in sync mode! Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7f8903f16d10 Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: INFO:db_mysql:reset_all_statements: resetting all statements on connection: (0x7f8903f16bb0) 0x7f8903f16d10 Jun 4 10:41:48 TC-521 /usr/sbin/opensips[12318]: INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f8903f16d10 Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: ERROR:db_mysql:db_mysql_connect: driver error(2003): Can't connect to MySQL server on '10.0.5.38' (110) Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: ERROR:db_mysql:db_mysql_new_connection: initial connect failed Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: ERROR:core:db_init_async: failed to open new DB connection on mysql://:@10.0.5.38:0/ Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: INFO:db_mysql:db_mysql_async_raw_query: Failed to open new connection (current: 1 + 10). Running in sync mode! Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7f8903f16d10 Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: INFO:db_mysql:reset_all_statements: resetting all statements on connection: (0x7f8903f16bb0) 0x7f8903f16d10 Jun 4 10:44:29 TC-521 /usr/sbin/opensips[12342]: INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f8903f16d10 MariaDB is also showing an error from its perspective: 2020-06-04 23:40:27 64783 [Warning] Aborted connection 64783 to db: 'unconnected' user: 'anonymous' host: '8.38.42.13' (Got timeout reading communication packets) > B) Have you tried only doing sync database queries? Async introduces some > overhead, and I'm not sure if it causes extra database connections to be > created. When using sync there is a connection per child process that stays > up. Using synchronous mode appeared to be causing context switching issues under heavy load. We specifically moved to async for this reason and that appeared to reduce the CPU load dramatically. From the docs: "Using the asynchronous, "suspend-resume" logic instead of forking a large number of processes in order to scale also has the advantage of optimizing system resource usage, increasing its maximal throughput. By requiring less processes to complete the same amount of work in the same amount of time, process context switching is minimized and overall CPU usage is improved. Less processes will also eat up less system memory." I've been tweaking each of the configuration settings I've mentioned, but without any clear path forward. Would 3.x provide any solutions? Is it possible to have too many children or timer partitions, and starve opensips with context switches? Would that cause connection issues? > C) Does the database have enough memory to contain the LRN and DNC datasets > fully in memory? The extra latency for the non-cache hits sent to the > database may stack up if the database has to hit disk. DB says query response time is like 0.001s and doesn't show any sign of strain. I'm not personally familiar with the TokuDB engine, but I'm lead to believe the entire dataset is in memory. I have two DBA triple checking things. It's possible we're hitting a max connections or open files limit that's set too low. Sometimes our peak hours include spikes as well. > D) How many child processes are you using now? If you are hitting 100% you > may need to increase them. Only one hits 100% initially, then they topple over after that. This seems to be related to the intermittent database connection errors. We'll see what raising the max connections and ulimits on the server does. I've also backed off on children and increased the async connection pool size to result in the same number of total maximum connections. Presumably this will reduce context switches and timer delays. > E) Are your memcached processes using heavy cpu? If you are caching multiple > lists, I've found it helps to use unique memcached instance per list. All of the various SIP dips are the same db stored procedure with many fields in the response. Those fields are cached as a CSV string, so any cached dip can be used by any
[OpenSIPS-Users] Fine tuning high CPS and msyql queries
The scenario is INVITE -> MySQL query -> non-200 final response. No
calls are connected here, only dipping things like LRN, Do Not Call,
and Wireless/Landline. A similar service runs on a second port,
specific to a different kind of traffic and dip. We're using async
avp_db_query and memcached, with about 3:1 cache hits.
Our target is up to 10,000 CPS across two opensips servers, which are
dual-CPU Xeon E5620 with 48G RAM. Both are run memcached, and both
servers are using both memcached to share a distributed cache thanks
to this:
'modparam("cachedb_memcached","cachedb_url","memcached:lrn://lrn-d,lrn-e/")'.
At a glance there are over 200mil total cached items, distributed
nearly equally.
The issue is that individual child processes start getting suck at
100% CPU. Logs indicate connection failures to the MySQL database
causing children to run in sync mode, and there are warnings about
delayed timer jobs tm-timer and blcore-expire. Eventually, the service
becomes unresponsive. Restarting opensips restores service and the
children return to single-digit CPU utilization, but eventually,
children get suck again.
I'm not certain if the issue is on the database server, or if the
opensips servers are overloaded, or if the config is just not right
yet.
Is there an established method for fine-tuning these things?
shared memory
process memory
children
db_max_async_connections
listen=... use_children
modparam("tm", "timer_partitions", ?)
What else is worth considering?
Does a child ever return to async mode after running in sync mode?
How do I know when my servers have reached their limit?
opensips.cfg is available on request.
version: opensips 2.4.7 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 9e1fcc915
main.c compiled on with gcc 7
*re-built using dpkg-buildpackage including the patch to support DB
floating point types:
https://opensips.org/pipermail/users/2020-March/042528.html
$ lsb_release -d
Description:Ubuntu 18.04.4 LTS
$ uname -a
Linux TC-521 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
$ free -mw
totalusedfree shared buffers
cache available
Mem: 482811085 337 871729
45128 46551
$ lscpu
Architecture:x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 2
NUMA node(s):2
Vendor ID: GenuineIntel
CPU family: 6
Model: 44
Model name: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
Stepping:2
CPU MHz: 2527.029
BogoMIPS:4788.05
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:256K
L3 cache:12288K
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca
sse4_1 sse4_2 popcnt aes lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow
vnmi flexpriority ept vpid dtherm ida arat flush_l1d
Regards,
Calvin Ellison
Senior Voice Operations Engineer
calvin.elli...@voxox.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Stir_shaken signature length
On Mon, Apr 13, 2020 at 8:13 AM Saint Michael wrote: > I am trying to do the same. The question I need to ask here is: how do you > generate the signature from the certificate, the caller ID and the > destination number? > I have the API working in staging mode, but now I need to really sign a call > and send it forward with Opensips 2.4.7 For 2.4.x you could try using the exec module with a CLI tool, or an external HTTP API. A C Library with CLI and HTTP server was posted to the VoceOps mailing list in January: https://puck.nether.net/pipermail/voiceops/2020-January/008264.html https://github.com/asipto/secsipidx ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one
We developed a small patch to check if there is a second result set
when the first result set has zero rows. It's pretty specific and
probably shouldn't be merged, but might help someone else if they are
stuck in a similar situation.
modules/db_mysql/dbase.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/modules/db_mysql/dbase.c b/modules/db_mysql/dbase.c
index cb2abcff3..e487c2ed1 100644
--- a/modules/db_mysql/dbase.c
+++ b/modules/db_mysql/dbase.c
@@ -863,8 +863,17 @@ static int db_mysql_store_result(const db_con_t*
_h, db_res_t** _r)
return -2;
}
- if (!CON_HAS_PS(_h))
- CON_RESULT(_h) = mysql_store_result(CON_CONNECTION(_h));
+if (!CON_HAS_PS(_h)) {
+CON_RESULT(_h) = mysql_store_result(CON_CONNECTION(_h));
+int currentRes = mysql_num_rows(CON_RESULT(_h));
+if(currentRes == 0) {
+int next = mysql_next_result(CON_CONNECTION(_h));
+if(next == 0) {
+CON_RESULT(_h) =
mysql_store_result(CON_CONNECTION(_h));
+}
+}
+}
+
if (!CON_RESULT(_h)) {
if (mysql_errno(CON_CONNECTION(_h)) > 0) {
LM_ERR("driver error: %s\n",
mysql_error(CON_CONNECTION(_h)));
--
Regards,
Calvin Ellison
Senior Voice Operations Engineer
calvin.elli...@voxox.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one
We can bring this up with the vendor, but it's a 3rd party system we have no control over. I understand limiting what OpenSIPS does that isn't SIP, and it would only be safe to combine the results sets if they have the same fields. Anything else could throw an error or just return combine results sets up to the first one that's different. avp_db_query can already handle multiple rows from there. This doesn't need to become a mainline change if no one else is interested, but I could sure use a patch to handle at least two results sets with identical columns. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com On Wed, Mar 18, 2020 at 3:39 PM Brett Nemeroff wrote: > You don’t want to return multiple result sets. I wouldn’t think any > support would be added for this. > > Maybe you can create a stored procedure that calls that stored procedure > and returns a single combined result set > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one
We've narrowed this down to a stored procedure that sometimes returns more than one result set, and when that happens the first result set is empty. It appears that db_mysql is setting the client flags to accept multiple result sets but the only processes the first one. Here's how my developer phrased it: > We have a store procedure that queries two tables and returns two result > sets. Something like “select * from table1 where condition=‘x’; select * > from table2 where condition=‘y’;” we need to be able to iterate through > both result sets. Since it’s a third party stored procedure we can’t modify > the way it works or make two separate queries. Currently the avp_db_query > method is returning “query returned no results” but it’s ignoring the > second result set. > What's needed to make db_mysql handle multiple result sets? It looks like they would need to be compiled into a single result set of zero or more rows before handing off to the DB API. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one
Any takers? This seems like a problem with db_mysql. It sees the column data but not the row. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com On Sun, Mar 15, 2020 at 3:40 PM Calvin Ellison wrote: > This does not happen on every query response but will happen on every > response for the same query. CLI mysql and mariadb clients show the result > row correctly, and pcaps confirm that opensips is getting the row response > (attached). > > Pcap: > > https://drive.google.com/file/d/1Un8dx8T3eFEhe8_jYIONrLVGhiQ6Xhj6/view?usp=sharing > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one
This does not happen on every query response but will happen on every
response for the same query. CLI mysql and mariadb clients show the result
row correctly, and pcaps confirm that opensips is getting the row response
(attached).
I recompiled opensips against libmariadbclient (Ubuntu
libmariadbclient-dev-compat) but that did not change the behavior. Debug
for a working and non-working query below.
Pcap:
https://drive.google.com/file/d/1Un8dx8T3eFEhe8_jYIONrLVGhiQ6Xhj6/view?usp=sharing
opensips -V
version: opensips 2.4.7 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC,
FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 9e1fcc915
main.c compiled on with gcc 7
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]:
DBG:avpops:ops_async_dbquery: query [call
lrn.fulldataz('6198077359',curdate())]
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:db_init_async:
>>1/220 transfers: (6 - 0x7fb7cc2f5ec8)
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:tm:t_handle_async:
placing async job into reactor
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:tm:io_watch_add:
[UDP_worker] io_watch_add op (6 on 12) (0x5605efdf65a0, 6, 16,
0x7fb78c103358,1), fd_no=4/104857
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]:
DBG:core:destroy_avp_list: destroying list (nil)
Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:receive_msg:
cleaning up
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:tm:t_resume_async:
resuming on fd 6, transaction 0x7fb78c1001a0
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_async_resume: mysql_read_query_result: 0, 0 - ""
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_new_result:
allocate 48 bytes for result set at 0x7fb7cc2f4ac8
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:core:db_allocate_columns: allocate 420 bytes for result columns at
0x7fb7cc2f6878
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f68f0)[0]=[number]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6900)[1]=[lrn]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6910)[2]=[port type]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6920)[3]=[state]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6930)[4]=[network]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6940)[5]=[ocn]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6950)[6]=[ratecenter]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6960)[7]=[class]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6970)[8]=[lata]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6980)[9]=[country]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6990)[10]=[reachable]
Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]:
DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type
Mar 14 20:18:58 localhost
[OpenSIPS-Users] Escape spaces in From and Contact
There is a broken client outside of my control sending From and Contact with spaces in the URI userinfo part, e.g. From: http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] cachedb_memcached multiple servers
I used the following and I see connections to both of those hosts. Maybe
libmemcached is distributing keys automatically?
modparam("cachedb_memcached","cachedb_url","memcached:lrn://lrn-a,lrn-b/")
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
+1 (213) 285-0555
---
*voxox.com <http://www.voxox.com/> *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]
On Fri, Mar 13, 2020 at 3:32 PM Brett Nemeroff wrote:
> I'm not aware of any way to specify a way to do this. You can however
> specify multiple memcache servers and perhaps use some sort of hashing alg
> to pick which one you want to use. Else you could use Jon's suggestion to
> use something a little more sophisticated than vanilla memcache.
>
> Just be sure you really know where memcache's strengths are. It's really
> super fantastic.
> -Brett
>
>
> On Fri, Mar 13, 2020 at 5:22 PM Calvin Ellison
> wrote:
>
>> Does OpenSIPS support using multiple memcached servers to distribute keys
>> for a single cachedb_url prefix? I'd like to pool the spare memory of my
>> OpenSIPS servers to make more efficient use of them.
>>
>>
>> Regards,
>>
>> *Calvin Ellison*
>> Senior Voice Operations Engineer
>> calvin.elli...@voxox.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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] cachedb_memcached multiple servers
Does OpenSIPS support using multiple memcached servers to distribute keys for a single cachedb_url prefix? I'd like to pool the spare memory of my OpenSIPS servers to make more efficient use of them. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
Thanks, Liviu! It turns out the service provider who I'm getting that "delay" value from has been watching this thread, and we both appreciate the attention and immediate response. Thanks also to Brett for his part in this. Regards, *Calvin Ellison* Senior Voice Operations Engineer On Wed, Mar 11, 2020 at 10:00 AM Liviu Chircu wrote: > On 11.03.2020 18:54, Calvin Ellison wrote: > > Then as Brett suggested, "make it [the default precision] defined in > > the header file for those who want to recompile it." > > This is already in place [1]. > > I suggest we add the modparam once someone really needs it. But feel > free to submit a PR (including documentation) and I'll happily review it! > :) > > Cheers, > > [1]: https://github.com/OpenSIPS/opensips/blob/master/ut.h#L57 > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 >www.opensips.org/events > > > ___ > 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] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
I agree with you. The immediate concern here is not performing calculations on the value, but that the string provided by avp is not necessarily what was contained in the database, which is unexpected behavior. And that's OK so long as the user is aware that the data could be truncated or padded with zeros, and the user will need to increase the precision and recompile, or use regex or transformations to get the desired substring. Clear documentation and change notes can prevent a lot of frustration. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com On Wed, Mar 11, 2020 at 10:06 AM Brett Nemeroff wrote: > Calvin, > The issue is more about what you want to do with that data in the opensips > script. Are you really wanting to do floating point math in the script? Or > are you taking those floats (like GPS coordinates) and using them as string > values in a header. If that’s all you want to do, you should cast your > values as strings before they land in the AVP IMO. No need to support that > floating point format if you arn’t looking to do real-time precision math > IN the script. > > If possible, that math really should occur in the database. Easy enough to > do in a avp_db_query. > > On Wed, Mar 11, 2020 at 11:57 AM Calvin Ellison > wrote: > >> >> What other use cases might there be for double type values? E911 or other >> things using GPS coordinates might be stored this way, but 8 digits are >> more than enough for that. >> >> ___ > 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] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
Or perhaps a direct way to tell avpops what precision to use for a given
field, as an exported parameter?
double_precision (string)
The number of decimal places to use when converting decimal, floating, and
other double type values to avp string
If no db_id reference number is given, 0 is assumed
double type fields not listed will default to 8 (6?)
this parameter is optional
modparam("avpops","double_precision","[db_id]
field=precision[;field=precision]...")
Then as Brett suggested, "make it [the default precision] defined in the
header file for those who want to recompile it."
What other use cases might there be for double type values? E911 or other
things using GPS coordinates might be stored this way, but 8 digits are
more than enough for that.
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
On Tue, Mar 10, 2020 at 10:31 AM Brett Nemeroff wrote: > Liviu, > My preference would be to default to 8, but make it defined in the header > file for those who want to recompile it. 6 is ok, it’s usually the minimum > precision that is acceptable. > My comment about significant digits was with regards to having extraneous trailing zeros, regardless of how many. Depending on the other value used in a calculation, 0.0019 versus 0.001900 might dictate rounding at a different number of decimal places. This is why I suggested grabbing the number of decimal places from the SQL response. My newbie googling of C printf/scanf indicates you can pass the number of decimal places via the ".precision" format specifier as a value or reference. There's a great answer on the topic here: https://stackoverflow.com/a/19897395 and some followup on C display precision versus mathematical precision and significant digits. It's probably a corner case. This stuff was pounded into me during high school chemistry class :) Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
The patch appears to be working as intended with regards to storing and later using the decimal value as a string: Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f8ecd2b5d68)[14]=[delay] Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]: DBG:db_mysql:db_mysql_get_columns: use DB_DOUBLE result type Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]: DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0019] However, when printed it appears as "0.001900". If that his how thing string would be passed to mathops, etc., it would cause problems for anyone interested in significant digits. E.g this could affect the precision of billing calculations. At this point, I'm just happy the Error and Warning are gone and the value is useful at all, but if someone wanted to take this a step further, they could get the precision of the value from the SQL data. Here's an example MySQL data packet with "Decimals: 4": MySQL Protocol Packet Length: 27 Packet Number: 16 Catalog: def Database: Table: Original table: Name: delay Original name: Charset number: binary COLLATE binary (63) Length: 26 Type: FIELD_TYPE_NEWDECIMAL (246) Flags: 0x0080 Decimals: 4 Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Tue, Mar 10, 2020 at 9:49 AM Brett Nemeroff wrote: > Totally agree that this is the right thing to do. I just wanted the list > to know it’s a STRING. I don’t think it’s obvious. > > Thanks again!! > > > On Tue, Mar 10, 2020 at 11:45 AM Liviu Chircu wrote: > >> On 10.03.2020 18:39, Brett Nemeroff wrote: >> > This isn’t really a problem unless you are going to math it or push it >> > into something else without casting it. >> >> I agree, but at script level, there is no support for manipulating >> "long" integers, >> let along "double" precision integers. So casting the "double" number >> to a string >> within avpops and returning it to the script seemed like a pretty good >> workaround. >> >> Additionally, this doesn't stop you from doing floating point math in >> the script using mathops [1]! >> >> [1]: https://opensips.org/docs/modules/3.1.x/mathops.html >> > ___ > 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] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
Copying Brett's reply back to the list. I deleted some of the previous
conversation to avoid "message too large".
I also noticed DB_DOUBLE is missing from /avpops/avpops_db.c but I don't
know C well enough to do the needful. Do you know what should be done to
make it a string?
Here's my updated /db_mysql/res.c. I did as you suggested and
moved MYSQL_TYPE_NEWDECIMAL along with its #if condition to just after
MYSQL_TYPE_FLOAT so it is DB_DOUBLE not DB_INT. It looks like the same
change is needed for MYSQL_TYPE_DECIMAL since this can also be non-integer,
but I didn't touch that.
switch(fields[col].type) {
case MYSQL_TYPE_TINY:
case MYSQL_TYPE_SHORT:
case MYSQL_TYPE_LONG:
case MYSQL_TYPE_INT24:
case MYSQL_TYPE_DECIMAL:
case MYSQL_TYPE_TIMESTAMP:
LM_DBG("use DB_INT result type\n");
RES_TYPES(_r)[col] = DB_INT;
break;
case MYSQL_TYPE_FLOAT:
#if MYSQL_VERSION_ID > 4
case MYSQL_TYPE_NEWDECIMAL:
#endif
case MYSQL_TYPE_DOUBLE:
LM_DBG("use DB_DOUBLE result type\n");
RES_TYPES(_r)[col] = DB_DOUBLE;
break;
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
On Mon, Mar 9, 2020 at 2:50 PM Brett Nemeroff wrote:
> Hey Calvin, my reply to you got blocked by the list auto-moderator for
> being too large. I have no idea why? Here’s my reply:
>
> Hey Calvin,
> Glad that helped. I'd need to see how you fixed res.c to know why that
> isn't working. However, most likely it's because of a lack of proper
> support of doubles. if you take a look at:
> /avpops/avpops_db.c
>
> You'll see in there that it checks the AVP type and there is no type for
> DB_DOUBLE from what I can see. I'm surprised this hasn't come up more
> often.
>
> I don't think the fix would be too hard, at least to make it more usable.
> You can see the handing in avpops_db isn't super. It's basically coheresing
> the returned values to an INT or a STRING. You could do the same by asking
> for a CAST or having the function cast the value before returning (ie: if
> your SP returned only strings and integers, you would not see this issue.)
>
>
> On Mon, Mar 9, 2020 at 2:23 PM Calvin Ellison
> wrote:
>
>> Updating the C code per Brett's suggestion resolved that specific error:
>>
>> DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0018]
>>
>> Now there is a warning when trying to print that avp:
>>
>> WARNING:avpops:db_query_avp_print_results: Unknown type 2
>>
>> I don't really care about this particular variable, but if the same issue
>> were to come up again in another context then what fix is needed to print
>> this as a string?
>>
>> Regards,
>>
>> *Calvin Ellison*
>> Senior Voice Operations Engineer
>> calvin.elli...@voxox.com
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
Updating the C code per Brett's suggestion resolved that specific error: DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0018] Now there is a warning when trying to print that avp: WARNING:avpops:db_query_avp_print_results: Unknown type 2 I don't really care about this particular variable, but if the same issue were to come up again in another context then what fix is needed to print this as a string? Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Mon, Mar 9, 2020 at 11:16 AM Ben Newlin wrote: > I’m pretty sure OpenSIPS doesn’t support floating point numbers in script > variables, so I don’t think it’s a bug. Even if you change the C code to > make it a Float the $var and $avp concepts are only string or int. There is > a MATHOPS module that offers some floating point math, but it’s based on > using string variables. > > > > Ben Newlin > > > > *From: *Users on behalf of Brett > Nemeroff > *Reply-To: *OpenSIPS users mailling list > *Date: *Monday, March 9, 2020 at 1:20 PM > *To: *Calvin Ellison , OpenSIPS users mailling > list > *Subject: *Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) > uses DB_INT result type but should use float > > > > Can you just statically put a integer in there? Like say, 0? > > > > I actually think this is a bug. You are using 2.4.7? I don’t see this > fixed in newer versions. > > > > The bug is on Line 81 of res.c. It incorrectly assumes that > MYSQL_TYPE_NEWDECIMAL is an INT. This should be easy for you to attempt to > fix and recompile. I’m not entirely sure it’ll work, but it’s worth a shot. > I’d move that data type down to the FLOAT block and give it a whirl. > > > > Good luck, > > Brett > > > > > > On Mon, Mar 9, 2020 at 12:00 PM Calvin Ellison > wrote: > > The problem, as I see it, is that the MariaDB server is indicating this > field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting > that integer (DB_INT). > > > > I don't really need the delay field but I have no way to exclude it from > the result and avp_db_query want every field mapped to an avp. > > > > Can avp_db_query force a translation on the result before storing it? > > > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:core:db_str2int: Unexpected characters: [.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_str2val: error while converting integer value from > string > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_convert_row: failed to convert value > > > > Regards, > > > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.elli...@voxox.com > +1 (213) 285-0555 > > --- > *voxox.com <http://www.voxox.com/> * > 5825 Oberlin Drive, Suite 5 > <https://www.google.com/maps/search/5825+Oberlin+Drive,+Suite+5+San+Diego,+CA+92121?entry=gmail=g> > San Diego, CA 92121 > <https://www.google.com/maps/search/5825+Oberlin+Drive,+Suite+5+San+Diego,+CA+92121?entry=gmail=g> > > [image: Image removed by sender. Voxox] > > > > > > On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff wrote: > > > > Hello Calvin, > > Looks like your coerecing a float into an integer field. I think it's your > delay field. What do you expect to happen here? I mean that seriously. If > the delay field is an integer, you can't put anything but an integer in it > if you have no access to change the database type. > > > > Alternatively, you could try to use transformations to manipulate the > numeric into something that looks like an integer (for example, multiple > those values by 1 and store that. > > > > Let us know if that helps or if you need some more help. > > -Brett > > > > > > On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison > wrote: > > It appears that OpenSIPS is assuming an incorrect integer data type on a > field that is a floating-point value. I have no access to change the field > type in the database. What can be done? > > > > Server version: 10.2.31
Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
The problem, as I see it, is that the MariaDB server is indicating this
field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting
that integer (DB_INT).
I don't really need the delay field but I have no way to exclude it from
the result and avp_db_query want every field mapped to an avp.
Can avp_db_query force a translation on the result before storing it?
Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay]
Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
DBG:db_mysql:db_mysql_str2val: converting INT [0.0012]
Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:core:db_str2int:
Unexpected characters: [.0012]
Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
ERROR:db_mysql:db_mysql_str2val: error while converting integer value from
string
Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
ERROR:db_mysql:db_mysql_convert_row: failed to convert value
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
+1 (213) 285-0555
---
*voxox.com <http://www.voxox.com/> *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]
On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff wrote:
>
> Hello Calvin,
> Looks like your coerecing a float into an integer field. I think it's your
> delay field. What do you expect to happen here? I mean that seriously. If
> the delay field is an integer, you can't put anything but an integer in it
> if you have no access to change the database type.
>
> Alternatively, you could try to use transformations to manipulate the
> numeric into something that looks like an integer (for example, multiple
> those values by 1 and store that.
>
> Let us know if that helps or if you need some more help.
> -Brett
>
>
> On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison
> wrote:
>
>> It appears that OpenSIPS is assuming an incorrect integer data type on a
>> field that is a floating-point value. I have no access to change the field
>> type in the database. What can be done?
>>
>> Server version: 10.2.31-MariaDB MariaDB Server
>>
>> Query and response attached
>>
>> async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())",
>> "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network);
>> $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country);
>> $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc);
>>
>> ERROR:core:db_str2int: Unexpected characters: [.0011]
>>
>> # opensips -V
>> version: opensips 2.4.7 (x86_64/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>> MAX_URI_SIZE 1024, BUF_SIZE 65535
>> poll method support: poll, epoll, sigio_rt, select.
>> main.c compiled on with gcc 7
>>
>>
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:core:db_allocate_columns: allocate 420 bytes for result columns at
>> 0x7f4bed66fa20
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number]
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn]
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type]
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state]
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network]
>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]:
>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
>> Mar 8 22:28:11 localhost /usr/sb
Re: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query
Thanks, Jon. Confirmed, updating $ru and not using append_to_reply solved the problem. After a moment of contemplation, I realized it makes sense that a 3xx response Contact would be based on the request URI Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Fri, Mar 6, 2020 at 5:58 PM Jon Abrams wrote: > OpenSIPs is using the contents of the RURI for the contact header in the > response. > > I seem to recall this working in 2.2 as well: > > $ru = ""; > append_to_reply( ""); > > If you set the package and/or shared memory larger you can delay the > fragmentation. In my scenario we were using the userblacklist feature and > updating several large lists multiple times an hour. This was triggering > the problem eventually. > You may never run into it with the caching depending on the volume and > allocation patterns. But if you start having response time spikes after a > long uptime, check the logs for memory related messages. > > - Jon Abrams > > On Fri, Mar 6, 2020 at 5:57 PM Calvin Ellison > wrote: > >> >> On Fri, Mar 6, 2020 at 2:56 PM Jon Abrams wrote: >> >>> Async does indeed trigger the transaction creation. You may need to >>> update the $ru variable and not use the append_to_reply. Or at least that's >>> how I solved this in the past. >>> >> >> What's the connection between the request's URI and a reply's Contact? I >> saw $ru mentioned regarding a similar issue back in 2009 but didn't >> understand how it solves the problem. >> >> >>> I would caution somewhat about using the caching (and possibly the >>> async), as memory fragmentation may become a problem after sustained usage. >>> >> >> Is there any guidance available for how to deal with this? Is this >> addressed via opensips things like hash size or linux things like shared >> memory configuration? >> ___ >> 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
[OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float
lhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [2] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [CA] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- LLC - CA] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [979E] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [L] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [730] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [US] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:core:db_str2int: Unexpected characters: [.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_str2val: error while converting integer value from string Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_convert_row: failed to convert value Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com +1 (213) 285-0555 --- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] numberdata.pcap Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query
On Fri, Mar 6, 2020 at 2:56 PM Jon Abrams wrote: > Async does indeed trigger the transaction creation. You may need to update > the $ru variable and not use the append_to_reply. Or at least that's how I > solved this in the past. > What's the connection between the request's URI and a reply's Contact? I saw $ru mentioned regarding a similar issue back in 2009 but didn't understand how it solves the problem. > I would caution somewhat about using the caching (and possibly the async), > as memory fragmentation may become a problem after sustained usage. > Is there any guidance available for how to deal with this? Is this addressed via opensips things like hash size or linux things like shared memory configuration? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query
The scenario is a SIP-MySQL proxy that performs LRN queries and replies
with 302 Redirect and Contact including npdi and optional rn parameters.
Cache_db is also used. This has worked as intended using the SL module
without async.
After refactoring to use async(avp_db_query()), there is now an additional
Contact in the 302 Redirect only if the async() happens. When the RN is
found in the cache there is only the single intended Contact.
I suspect the difference has something to do with async using the TM module
and it's probably a simple mistake. What magic is required to send only the
desired Contact after async?
Here's the cached chunk:
if($Rp != "5061" && !is_present_hf("X-LNP-Refresh") &&
cache_fetch("local", "$rU", $avp(10)))
{
$avp(lrn) = $avp(10);
$avp(resultType) = "CACHED";
update_stat("cached_results", "+1");
route(continue);
}
...
route [continue]
{
if($Rp != "5061" )
cache_store("local", "$rU", "$avp(lrn)", $avp(timeout));
$var(rn) = $(avp(lrn){csv.value,0});
$var(ct) = "";
append_to_reply("Contact: $var(ct)\r\n");
sl_send_reply("302", "Redirect");
$var(processingTime) = $Ts * 1000 + $Tsm/1000 - $avp(startTime);
}
Not-cached does this:
async(avp_db_query("call lrn.sqlrn('$var(number)')",
"$avp(11);$avp(12);$avp(13)"), resume_lnp);
...
route [resume_lnp]
{
$var(db_res) = $retcode;
if ($var(db_res) && is_avp_set("$avp(11)"))
{
update_stat("mysql_result_number", "+1");
$var(number) = $avp(11);
if ($avp(11) =~ "^[2-9][0-9]{9}$")
$var(number) = "1" + $avp(11);
$avp(lrn) = $var(number) + "," + $avp(12) + "," + $avp(13);
$avp(resultType) = "MYSQL";
}
else if ($var(db_res) == -1)
{
update_stat("mysql_result_error", "+1");
$var(ct) = "";
append_to_reply("Contact: $var(ct)\r\n");
sl_send_reply("302", "Redirect");
$var(processingTime) = $Ts * 1000 + $Tsm/1000 -
$avp(startTime);
xlog("L_ERR", "TRACE:ROUTE:MYSQL_ERROR src=$si:$sp
dst=$Ri:$Rp From=$fU To=$rU ID=$ci Time=$var(processingTime)\n");
exit();
}
else
{
update_stat("mysql_result_empty", "+1");
$avp(resultType) = "MYSQL_EMPTY";
}
route(continue);
}
Good (cached, no async):
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 10.0.2.45:5060;branch=z9hG4bK-27769-1-0
From: ;tag=27769SIPpTag001
To: 17605086443 ;tag=a1b3.ecf278993d227a99987b0bccd10b5617
Call-ID: 1-27769@10.0.2.45
CSeq: 1 INVITE
Contact:
Content-Length: 0
Bad (not cached, async):
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 10.0.2.45:5060;branch=z9hG4bK-27753-1-0
From: ;tag=27753SIPpTag001
To: 17605086443 ;tag=a1b3.fd3dd7f924d173cf165e3579c8289026
Call-ID: 1-27753@10.0.2.45
CSeq: 1 INVITE
Contact:
Contact:
Content-Length: 0
Regards,
*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
+1 (213) 285-0555
---
*voxox.com <http://www.voxox.com/> *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
