Re: [OpenSIPS-Users] Username in DB URL
Hi Olle,
Could you give a try to this fix:
https://github.com/OpenSIPS/opensips/commit/5b0bc1e30ebfc1e67f4967c3e66cfa7577ee5b58
Currently this is available only on trunk version (still you can use the
nightly builds from the official repos). If your tests are positive, I
will do a backport ;)
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 02/13/2018 04:11 PM, Olle Frimanson wrote:
Hi, thanks for the reply. We try to avoid installing from source and
rather use RPM’s. We are also looking into using a SQL proxy and have
that locally on the opensips server. But the very best solution would
be to escape somehow.
I think there was a similar problem with the TLS crypto suite that was
fixed in a nice way.
And I don’t think we can get Microsoft to change the usernames for MySQL J
BR / Olle
*Från:*Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
*Skickat:* den 6 februari 2018 18:20
*Till:* OpenSIPS users mailling list ; Olle
Frimanson
*Ämne:* Re: [OpenSIPS-Users] Username in DB URL
Hi Olle,
As Alex said there is no work around for this for now. Still the
problem can be addressed by coding and it is not so hard to do. The
question is what is the best/proper type of escaping to be supported
into the URL - I guess the %xy is the proper one for an URL, as per
RFC 1738 ).
Have you installed opensips form sources ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 02/05/2018 08:08 PM, Olle Frimanson wrote:
Hi, we are experiencing an issue with a roleout in Microsoft
Azure, where the DB username contains a ”@” sign. This seems to
be the default in MySQL in Azure. Is there anyway to escape this
the URL for the clusterer module?
If you use mysql client it’s typical something like
Mysql -h host.mysql.azure.com -u opensips@host -popensips
opensips, which works fine
In clustererar where we use this this translates to:
modparam("clusterer",
"db_url","mysql://opensips@host:opens...@host.mysql.azure.com/opensips"
)
which fails
Any ideas on a workaround on this?
BR / Olle
___
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] dialog replication
Hi Vlad, Thanks for your response. I think I'll have to wait until 2.4 transaction replication come in to action if I am to go with anycast ip. I didn't understand how it would solve with 2 moveable ips. how do i make sure dialog will tie to a particular ip ? On Wednesday, 28 February 2018, 17:04, Vlad Patrascu wrote: Hi, Yes, you are correct, this is currently a limitation. But it could also work in an "active/active" sort of setup if you have 2 movable IPs and each dialog is tied to one of the IPs. Full anycast support though is coming up in OpenSIPS 2.4. Regards, Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 28.02.2018 04:46, Pasan Meemaduma via Users wrote: Hi Vlad, On a second thought its how anycast should work, packets could get to the closest node so basically with 2.3.3 we can't replicate transactions across mulitple opensips servers ? dialog replication would only work for an active/passive setup doesn't it ? On Wednesday, 28 February 2018, 7:36, Pasan Meemaduma via Users wrote: Hi Vlad, That explains the issue then, my sip listener ip is an anycast one, and for some weired reason replies for INVITE that leaves node2 receive by node1 hence it can't create the dialog. I checked with node2 being down and recovered and calls init via node1 always received final reply hence dialog replication works. So it means my anycast configuration is broken right ? Thanks for you time to look in to it. On Tuesday, 27 February 2018, 21:42, Vlad Patrascu wrote: Hi Pasan, I don't see anything in the logs or your cluster configuration which could indicate that the dialogs don't replicate. Are you sure that the problem is consistently reproducible and that the INVITE for the call in question receives a final reply? Dialogs are replicated when they get to the confirmed state, and judging from the logs, this doesn't appear to be happening for that call. Regards, Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 27.02.2018 04:15, Pasan Meemaduma via Users wrote: Hi Vlad, I have sent you the full debug logs as requested. Also clusterer_list mi command gives following output when dialog replication stopped working. node1>>opensipsctl fifo clusterer_list Cluster:: 1 Node:: 2 DB_ID=5 URL=bin:10.3.1.137:5566 Enabled=1 Link_state=Up Next_hop=2 Description=Node 2 node2>> opensipsctl fifo clusterer_list Cluster:: 1 Node:: 1 DB_ID=4 URL=bin:10.3.1.136:5566 Enabled=1 Link_state=Up Next_hop=1 Description=Node 1 1 On Monday, 26 February 2018, 18:02, Vlad Patrascu wrote: Hi, Can you send the full logs for both nodes from the time that node1 restarts onwards? Also, what is the output of 'clusterer_list' mi command on the instances? Regards, Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 26.02.2018 08:38, Pasan Meemaduma via Users wrote: Hi Guys, Its me again :). I'm using dialog replication in opensips 2.3.3 and it appears it doesn't work after a node goes down and come back online. The recovered node doesn't seems to receiving dialog info via binary interface. I have node1 and node2 with dialog replication on. everything works fine and if I shutdown node1 and bring it back online after a while node2 doesn't send new call dialog info via binary interface. I have attach the debug trace from both nodes, if you need anything else let me know. I'm also using an anycast ip as the service ip. on node2 for new call Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:build_new_dlg: new dialog 0x7f188afd3bf8(c=ktQ0Pkdwz50qGYjED6Brpw..,f=sip:X@somedomain;transport=UDP,t=sip:+YYY@somedomain;transport=UDP,ft=2b161508) on hash 2317 Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:init_leg_info: route_set , contact sip:X@192.168.27.11:56419;transport=UDP, cseq 2 and bind_addr udp:10.3.3.1:5060 Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:dlg_add_leg_info: set leg 0 for 0x7f188afd3bf8: tag=<2b161508>rcseq=<0> Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:link_dlg: ref dlg 0x7f188afd3bf8 with 3 -> 3 in h_entry 0x7f188afc3828 - 2317 Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:new_dlg_val: inserting =<45ad4c76-1abe-11e8-9410-831894b67d0c> Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:dlg_onreq: t hash_index = 47425, t label = 2069082013 Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:dlg_update_contact: Updated dialog 0x7f188afd3bf8 contact to Feb 26 17:28:35 voip2-sip23b /usr/sbin/opensips[4703]:DBG:dialog:unref_dlg: unref dlg 0x7f188afd3bf8 with 1 -> 2 in entry 0x7f188afc3828 Feb 26 17:28:52 voip2-sip23b /usr/sbin/opensips[4702]:DBG:dialog:ref_dlg: ref dlg 0x7f188afd3bf8 w
Re: [OpenSIPS-Users] Dispatcher not probing
Hi Pete,
That is weird - If I do a patch for extra logging, would you be able to
run it ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 03/01/2018 04:31 PM, Pete Kelly wrote:
Hi Bogdan
Yes this issue seems to still persist.
I have a gw which is initially active, and is then set to probing with
ds_mark_dst("p")... The output of ds_list confirms it is in probing also.
The module parameter ds_probing_mode is not defined at all (so it
should be 0 as per default).
However the gateway is not being probed!
This is with 2.3.3 now.
Pete
On 31 January 2018 at 11:53, Bogdan-Andrei Iancu > wrote:
Pete,
There may be a bit of a confusion here. I was talking about the
ds_probing_list parameter (which is default UNSET). The
ds_probing_mode is indeed 0 as default, meaning to ping only
destinations in state PROBING.
Again, do you have this pinging issue for all the destinations in
your set ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 01/30/2018 03:41 PM, Pete Kelly wrote:
Bogdan
The docs say the default is "0" so actually the default is UNSET?
Which I think means I need to set it to 0 in order to make the
Probing gw's be probed?
On 26 January 2018 at 15:55, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:
Pete, yes, you are right - if not set at all (which is
different than setting it to "0") it means probing for all.
And default is "unset"/
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 01/26/2018 05:37 PM, Pete Kelly wrote:
Hi Bogdan
ds_probing_mode is set to the default (0).
The docs say this "If set to 0, only the gateways with state
PROBING are tested"
So I would assume this means that anything in PROBING should
be pinged?
On 26 January 2018 at 14:15, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:
Hi Pete,
The primary storage (during runtime) is memory (the
in-mem status is only flushed to DB, not read).
Now, do you use "ds_probing_list" parameter ? Also, are
you sure "ds_probing_mode" parameter is set to 1 ?
More questions - this issue happens only for a
particular destination ? or none of the "probing"
destinations is pinged ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 01/26/2018 11:58 AM, Pete Kelly wrote:
The gw should be being probed (this is the desired
behaviour!).
Is OpenSIPS using the DB column instead of the
in-memory state?
On 22 January 2018 at 16:33, Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:
Hi Pete,
The DB schema is documented here:
http://www.opensips.org/Documentation/Install-DBSchema-2-3#AEN4379
State "1" means disabled and this explains the
no-probing behavior. Still, you claim that the
in-memory state is Probing, according to the MI
ds_list commandSo, which is the right state of
the GW ?? :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 01/18/2018 12:53 PM, Pete Kelly wrote:
Hi
I am using OpenSIPS 2.3.2 and have the dispatcher
module configured thusly:
# - dispatcher params -
modparam("dispatcher", "db_url",
"
Re: [OpenSIPS-Users] Postgres and virtual DB errors during restart
Hi, Well, when you restart OpenSIPSall the DB connections will be terminated (killed by OpenSIPS) - and the effect you get on the server side are the logs you see. I agree that OpenSIPS should do a graceful DB conn termination, but this is asimple beautification at this point. Still, we have it on the plan. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit 2018 http://www.opensips.org/events/Summit-2018Amsterdam On 03/01/2018 05:52 PM, xaled wrote: Hi, I’m using postgres with virtual_db module and after opensips restarts I’m getting “Connection reset by peer” errors in postgres logs. The errors don’t not seem to influence the DB connection after restart, but still kind of annoying. Is there something I could do about it? 2018-03-01 15:41:47.599 CET [14600] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.603 CET [14604] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.603 CET [14590] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.605 CET [14603] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.605 CET [14588] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.606 CET [14607] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.607 CET [14601] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.609 CET [14592] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.610 CET [14606] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.611 CET [14597] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.611 CET [14591] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.612 CET [14595] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.614 CET [14605] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.614 CET [14576] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.616 CET [14585] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.617 CET [14580] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.617 CET [14596] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.619 CET [14594] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.619 CET [14598] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.620 CET [14567] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.620 CET [14593] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.621 CET [14608] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.622 CET [14587] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.623 CET [14574] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.625 CET [14599] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.625 CET [14568] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.626 CET [14602] user@sipapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.627 CET [14566] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.629 CET [14589] user@webapp LOG: could not receive data from client: Connection reset by peer 2018-03-01 15:41:47.630 CET [14565] user@webapp LOG: could not receive data from client: Connection reset by peer 14260 ?Ss 0:00 postgres: 10/main: checkpointer process 14261 ?Ss 0:00 postgres: 10/main: writer process 14262 ?Ss 0:00 postgres: 10/main: wal writer process 14263 ?Ss 0:00 postgres: 10/main: autovacuum launcher process 14264 ?Ss 0:00 postgres: 10/main: stats collector process 14265 ?Ss 0:00 postgres: 10/main: bgworker: logical replication launcher 14647 ?Ss 0:00 postgres: 10/main: user webapp 127.0.0.1(40684) idle 14648 ?Ss 0:00 postgres: 10/main: user webapp 127.0.0.1(40686) idle 14649 ?Ss 0:00 postgres: 10/main: us
Re: [OpenSIPS-Users] RTP Proxy Port not updating on T38 reinvite
Hi, Pat!
Can you send over the logs from rtpproxy? Perhaps I can figure out why
rtpproxy is not sending RTP to the new port.
Best regards,
Răzvan
On 03/01/2018 05:01 AM, Pat Burke wrote:
We have a situation where a fax comes in, all of the negotiation looks
good (ports are translated like they are supposed to be), and the
interface with RTP Proxy looks correct (at least to me). But what
happens is that after the Re-INVITE for T38, the RTP Proxy continues to
sent the RTP to the customer's old port. In the example below, RTP
Proxy sends the RTP to the customer on port 7186 AFTER the Re-INVITE
with the new port.
SIP trace is located at https://www.4shared.com/file/wIVrkOtnei/SIP.html
From the SIP responses, it appears that the code is performing
correctly. Not certain what to try next.
Also, the RTP Proxy server was rebooted.
Any suggestions?
Thanks in advance,
Pat
Configuration:
OpenSIPS 2.2.3 on Ubuntu 16.04
RTP Proxy 2.2.alpha.20160822 on Ubuntu 16.04
***
*** OpenSIPS re-Invite code.
if (has_totag()) {
if (is_method("BYE")) {
if ($avp(call_end_seconds) == NULL) {
$avp(bye_src_ip) := $si;
$avp(bye_time) := $Ts;
get_timestamp($avp(call_end_seconds),$avp(call_end_useconds));
$json(end_recording_details) := "{}";
$json(end_recording_details/endsec) = $avp(call_end_seconds);
$json(end_recording_details/endusec) = $avp(call_end_useconds);
xlog("L_INFO", "$dlg_val(rU) SCRIPT:RTPPROXY:DEBUG: End call recording
callid=$ci ; ft= $ft data = $json(end_recording_details) \n");
#async(avp_db_query("UPDATE recordings SET end_recording_details =
'$json(end_recording_details)' WHERE call_id = '$ci'", ""), resume_totag);
avp_db_query("UPDATE recordings SET end_recording_details =
'$json(end_recording_details)' WHERE call_id = '$ci'", "");
} else {
xlog("L_INFO", "$dlg_val(rU) SCRIPT:BILLING:DEBUG: Extra BYE received.\n");
}
}
if (loose_route() || match_dialog()) {
if ( $DLG_status==NULL ) {
if (is_method("ACK") && t_check_trans() ) {
t_relay();
exit;
}
xlog("L_WARN", "$rU SCRIPT:TRAFFIC:WARNING: - $rm is not in-dialog (
callid=$ci ; ruri=$ru ; route=$(hdr(Route)[*]) )\n");
exit;
} else {
if (is_method("INVITE")) {
record_route();
if (stream_exists("image") && $dlg_val(t38) == "0") {
xlog("L_WARN", "$rU SCRIPT:FAX:DEBUG: Received RE-INVITE containing FAX,
but carrier doesn't support it - rejecting $ci \n");
send_reply("488","Not Acceptable");
exit;
}
xlog("L_INFO", "$dlg_val(rU) SCRIPT:RTPPROXY:DEBUG: -
$dlg_val(proxy_media) - $dlg_val(rtpproxy_group) -
$dlg_val(customer_record)\n");
# Setup proxy media
if ($dlg_val(proxy_media) != NULL && $dlg_val(proxy_media) == "1") {
if (nat_uac_test("8")) {
rtpproxy_offer("co",,"$dlg_val(rtpproxy_group)", "$avp(rtpprpoxy_server)");
} else {
rtpproxy_offer("cor",,"$dlg_val(rtpproxy_group)", "$avp(rtpprpoxy_server)");
}
$avp(rtpprpoxy_server) := $(avp(rtpprpoxy_server){s.select,1,:});
if ($dlg_val(customer_record) == "1") {
rtpproxy_start_recording("$dlg_val(rtpproxy_group)");
}
xlog("L_INFO", "$dlg_val(rU) PHB - D - media = $(rb{sdp.line,c}) rtp =
$avp(rtpprpoxy_server) \n");
}
t_on_reply("media");
}
t_relay();
exit;
}
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else
exit;
}
sl_send_reply("404","Not here");
exit;
}
***
*** RTP Ports in the call flow
Carrier OpenSIPS
Customer
Audio 61616 < 18986 <<
>> 16930 >>
7186 (intial INVITE / 200 OK)
Image >> 16930 >> 7192
(Re-INVITE / 200 OK - T38)
61616 < 18986 <<
***
*** RTP Proxy Command TRACE
#
U 216.147.191.162:41657 -> 216.147.191.232:9992
1422_78032 Uc0,18,101 1917630487_62491918@208.93.41.184 208.93.41.140
61616 gK0c00bce5;1
#
U 216.147.191.232:9992 -> 216.147.191.162:41657
1422_78032 18986 216.147.191.232
#
U 216.147.191.162:41657 -> 216.147.191.232:9992
1422_78033 Lc0,101 1917630487_62491918@208.93.41.184 216.147.191.171
7186 gK0c00bce5;1 5a142640;1
#
U 216.147.191.232:9992 -> 216.147.191.162:41657
1422_78033 16930 216.147.191.232
#
U 216.147.191.162:41657 -> 216.147.191.232:9992
1422_78034 U 1917630487_62491918@208.93.41.184 216.147.191.171 7192
5a142640;1 gK0c00bce5;1
#
U 216.147.191.232:9992 -> 216.147.191.162:41657
1422_78034 16930 216.147.191.232
#
U 216.147.191.162:41657 -> 216.147.191.232:9992
1422_78035 L 1917630487_62491918@208.93.41.184 208.93.41.140 61616
5a142640;1 gK0c00bce5;1
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Răzvan Crainea
OpenSIPS Core
