Re: [OpenSIPS-Users] avps in onreply_route
Hi, On 2021-02-03 10:11, Liviu Chircu wrote: On 03.02.2021 11:09, Fabian Gast wrote: The second one works, but not the first one, which should be the same and i don't get why. ( Talking about Opensips 2.4.x ) Hi, Per the documentation [1], the global onreply_route is stateless (unrelated to the SIP transaction, you're just viewing a SIP message), while the other one is stateful (the SIP transaction has been matched, and your request-bound AVPs are now available as well). [1]: https://www.opensips.org/Documentation/Script-Routes-3-2#toc4 Thanks for the hint! Fabian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] avps in onreply_route
Hello @all,
maybe you could help me to understand the behaviour of avps in
onreply_routes.
I have to configs:
a)
modparam("tm", "onreply_avp_mode", 1)
route {
$avp(aa) = 1;
t_relay();
}
onreply_route {
xlog("$avp(aa)\n"); # avp NOT set!
}
b)
modparam("tm", "onreply_avp_mode", 1)
route {
t_on_reply("1");
$avp(aa) = 1;
t_relay()
}
onreply_route[1] {
xlog("$avp(aa)\n"); # avp set!
}
The second one works, but not the first one, which should be the same
and i don't get why.
( Talking about Opensips 2.4.x )
Thanks!
Fabian
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] MS teams
Hi,
first: it looks like your 'new' IF - block is outside of any route.
You close your local route before and start the main route after.. - But
the new code block has to belong to some route block.
second: on 3.1,
send_reply("200", "OK");
does not work. - change this to send_reply(200, "OK");
( see
https://opensips.org/html/docs/modules/3.1.x/signaling.html#func_send_reply
)
same for check_source_address("2") -this also has to be
check_source_address(2)
(
https://opensips.org/html/docs/modules/3.1.x/permissions#func_check_source_address)
All the best,
Fabian
On 2020-09-17 17:33, Andrew Colin wrote:
nope :(
here is the full content
### Routing Logic
# main request routing logic
# Checks from MS Teams
local_route {
$var(dst) = "pstnhub.microsoft.com [2]";
if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL))
append_hf("Contact: \r\n");
}
if (is_method("OPTIONS") && is_domain_local("$rd") &&
check_source_address("2")) {
xlog("L_INFO",
"[MS TEAMS] OPTIONS In");
send_reply("200", "OK");
exit;
}
route{
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 302 after ebr not relayed
Hi @all,
we are having trouble with 302 after a 'ebr - push' like in [1]:
The fireing the INVITE after the REGISTER works fine, but if the client
responds back with
a "302 Moved Temporarily" this is hold back by the opensips until
fr_inv_timeout is expired.
Any clues / hints on this?
The (simplified) part of the script:
route[do_push] {
$T_fr_inv_timeout = 60;
t_newtran();
setflag(PUSH);
t_on_branch("branch_tosbc");
t_on_failure("zfail");
t_wait_for_new_branches();
$avp(filter) = "aor="+$(rU{s.tolower});
notify_on_event("E_UL_CONTACT_INSERT","$avp(filter)", "fork_call",
"62");
xlog("L_INFO", "PUSH_REQUEST : INVITE : $tU : $ci\n");
exit;
}
route[fork_call] {
xlog("user $avp(aor) registered a new contact $avp(uri), injecting\n");
t_inject_branches("event");
}
Thanks,
Fabian
[1] https://opensips.org/docs/modules/2.4.x/event_routing.html#idp5579792
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Debugging memory leaks
Hi Liviu, - Ursprüngliche Mail - > Von: "Liviu Chircu" > > * what kind of traffic is hitting your server when you reach this > state? Is it just during normal operation, or are you passing through > some kind of peak hour or maybe you are performing a sipp-based stress test? This was just in normal operation. Memory goes up during daytime and does not reduce at night with much much less traffic. > * do you have (or can you create) a quiet window, with less traffic? If > yes, do these transactions get cleaned up properly within a minute, or > are we dealing with some kind of transaction referencing bug (unlikely)? This was a quiet window with ~ 700 devices registered and less than 10 running calls (if at all) at the time right before the dump. > * can you reproduce this in a lab environment? If yes, please share how! :) Never tried this outside our platform, but i might check our test environment. Thanks for your help! Fabian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] i got some error like this please help me to solve
Hi, do you have more than one instance of opensips running with the same configuration on this box? Fabian - Ursprüngliche Mail - Von: "Devang Dhandhalya" An: "OpenSIPS users mailling list" Gesendet: Donnerstag, 12. März 2020 07:32:05 Betreff: [OpenSIPS-Users] i got some error like this please help me to solve ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Advice on TLS debugging
Hi,
we do this on the application level with the siptrace [1] module:
loadmodule "proto_hep.so"
loadmodule "siptrace.so"
listen = hep_udp:127.0.0.1:60PRIMARYVIP
modparam("proto_hep", "hep_id", "[hep_dst] 127.0.0.1:50667; version=2")
modparam("siptrace", "trace_on", 0)
modparam("siptrace", "trace_id", "[tid]uri=hep:hep_dst")
## MAIN ROUTING ##
route {
sip_trace("tid");
Now you can trace the unencrypted packets on 127.0.0.1:50667 via
ngrep/tcpdump/...
Maybe this helps you a little.
Fabian
[1] https://opensips.org/html/docs/modules/2.4.x/siptrace
- Ursprüngliche Mail -
Von: "Mark Farmer"
An: "OpenSIPS users mailling list"
Gesendet: Mittwoch, 11. März 2020 17:48:06
Betreff: [OpenSIPS-Users] Advice on TLS debugging
Hi everyone
I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am
struggling to find a good way to examine SIP messages/responses due to them
being encrypted.
Normally I just sngrep but using the -k arg doesn't seem to be working.
How do others deal with this?
Many thanks
Mark.
___
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] Debugging memory leaks
Hi Liviu, - Ursprüngliche Mail - > Von: "Liviu Chircu" > > * what kind of traffic is hitting your server when you reach this > state? Is it just during normal operation, or are you passing through > some kind of peak hour or maybe you are performing a sipp-based stress test? This was just in normal operation. Memory goes up during daytime and does not reduce at night with much much less traffic. > * do you have (or can you create) a quiet window, with less traffic? If > yes, do these transactions get cleaned up properly within a minute, or > are we dealing with some kind of transaction referencing bug (unlikely)? This was a quiet window with ~ 700 devices registered and less than 10 running calls (if at all) at the time right before the dump. > * can you reproduce this in a lab environment? If yes, please share how! :) Never tried this outside our platform, but i might check our test environment. Thanks for your help! Fabian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Debugging memory leaks
ireg02 /usr/sbin/opensips[42351]: 80 : 10 x [evi/event_interface.c: evi_publish_event, line 75] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:3368 : 38 x [timer.c: new_os_timer, line 146] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 40 : 1 x [cachedb_local.c: parse_collections, line 608] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 136 : 1 x [event_route.c: fixup_scriptroute_fetch, line 564] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 74] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 984 : 1 x [core_stats.c: init_pkg_stats, line 174] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:4120 : 1 x [statistics.c: init_stats_collector, line 223] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 696 : 19 x [ucontact.c: mem_update_ucontact, line 250] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 565800 : 1 x [pt.c: init_multi_proc_support, line 70] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [timer.c: init_timer, line 83] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 400 : 1 x [evi/event_interface.c: evi_publish_event, line 61] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:8208 : 1 x [../../evi/../lock_alloc.h: lock_set_alloc, line 66] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 79464 : 826 x [urecord.c: new_urecord, line 70] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 464 : 2 x [event_routing.c: ebr_parse, line 380] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 384 : 16 x [../../rw_locking.h: lock_init_rw, line 40] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 32 : 2 x [evi/evi_transport.c: register_event_mod, line 84] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_ping_timer, line 162] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 262144 : 32 x [net/net_tcp.c: tcp_init, line 1741] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 24 : 1 x [ul_callback.c: init_ulcb_list, line 44] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 56 : 1 x [udomain.c: new_udomain, line 81] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 81792 : 1167 x [statistics.c: register_stat2, line 388] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 2253944 : 3893 x [mem/shm_mem.c: _shm_resize, line 226] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [rw_locking.h: lock_init_rw, line 45] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 16 : 1 x [daemonize.c: set_osips_state, line 576] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 40 : 1 x [t_hooks.c: insert_tmcb, line 92] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 2621448 : 1 x [h_table.c: init_hash_table, line 372] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 262144 : 32 x [net/net_tcp.c: tcp_init, line 1747] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 251864 : 3287 x [../../ut.h: shm_str_dup, line 692] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:33428816 : 3893 x [h_table.c: build_cell, line 244] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 72 : 3 x [evi/event_interface.c: evi_event_subscribe, line 334] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x [event_route.c: scriptroute_parse, line 306] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 616 : 12 x [ucontact.c: mem_update_ucontact, line 255] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [sl_funcs.c: sl_startup, line 80] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:37022512 : 3893 x [sip_msg.c: sip_msg_cloner, line 534] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:1824 : 12 x [ucontact.c: mem_update_ucontact, line 271] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 55816 : 840 x [map.c: map_get, line 139] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [daemonize.c: create_status_pipe, line 92] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:2064 : 1 x [../../lock_alloc.h: lock_set_alloc, line 66] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: - Ursprüngliche Mail - Von: "Liviu Chircu" An: "OpenSIPS users mailling list" Gesendet: Mittwoch, 11. März 2020 11:03:16 Betreff: Re: [OpenSIPS-Users] Debugging memory leaks On 11.03.2020 11:06, Fabian Gast wrote: > How can we continue from the memory status on hunting down the problems? Is > there any advice on this? Hey Fabian, When you ran the "shm_mem_dump" which produced the pasted output, what values did the "shmem:" statistics group hold? Based on the output, you were barely using 1 MB of sha
Re: [OpenSIPS-Users] Debugging memory leaks
Hi Liviu, get_statistics shmem: from a few seconds before the dump was shmem:total_size:: 4294967296 shmem:used_size:: 88427200 shmem:real_used_size:: 95189880 shmem:max_used_size:: 119231640 shmem:free_size:: 4199777416 shmem:fragments:: 66733 All the best, Fabian - Ursprüngliche Mail - Von: "Liviu Chircu" An: "OpenSIPS users mailling list" Gesendet: Mittwoch, 11. März 2020 11:03:16 Betreff: Re: [OpenSIPS-Users] Debugging memory leaks On 11.03.2020 11:06, Fabian Gast wrote: > How can we continue from the memory status on hunting down the problems? Is > there any advice on this? Hey Fabian, When you ran the "shm_mem_dump" which produced the pasted output, what values did the "shmem:" statistics group hold? Based on the output, you were barely using 1 MB of shared memory, which is a bit strange. The table head tells exactly what the numbers represent: total bytes, number of allocations and the file/func/line which allocated them. Regards, -- 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
[OpenSIPS-Users] Debugging memory leaks
Hi @all, according to our graphs [1] and some recent crashes it looks like we have some memory leaks in our opensips processes. We now have the memory status from one of our staging environments with about 2k devices. (The impact on our live machines is even more severe, but we can not enable memory debugging on these systems for $reasons.) How can we continue from the memory status on hunting down the problems? Is there any advice on this? snipped from the memory status dump - full trace available upon request... Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: Memory status (shm): Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: qm_status (0x7ff2182ea000): Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: heap size= 4294967296 Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: used= 19440, used+overhead=325640, free=4294641656 Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: max used (+overhead)= 119231640 Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: dumping summary of all alloc'ed. fragments: Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: total_bytes | num_allocations x [file: func, line] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:6040 : 366 x [statistics.c: build_stat_name, line 122] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 185] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 408 : 48 x [mi/mi.c: register_mi_cmd, line 174] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 128 : 2 x [ebr_data.c: add_ebr_event, line 79] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 168 : 14 x [map.c: map_get, line 150] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [map.c: map_create, line 79] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:5904 : 1 x [core_stats.c: init_pkg_stats, line 173] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 83] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [mem/shm_mem.c: shm_mem_init_mallocs, line 390] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 80 : 10 x [evi/event_interface.c: evi_publish_event, line 75] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:3368 : 38 x [timer.c: new_os_timer, line 146] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 40 : 1 x [cachedb_local.c: parse_collections, line 608] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 136 : 1 x [event_route.c: fixup_scriptroute_fetch, line 564] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 74] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 984 : 1 x [core_stats.c: init_pkg_stats, line 174] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [timer.c: init_timer, line 83] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 400 : 1 x [evi/event_interface.c: evi_publish_event, line 61] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 464 : 2 x [event_routing.c: ebr_parse, line 380] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 32 : 2 x [evi/evi_transport.c: register_event_mod, line 84] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 16 : 1 x [daemonize.c: set_osips_state, line 576] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 72 : 3 x [evi/event_interface.c: evi_event_subscribe, line 334] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x [event_route.c: scriptroute_parse, line 306] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 912 : 14 x [map.c: map_get, line 139] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [daemonize.c: create_status_pipe, line 92] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, QM_MALLOC, DBG_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: edef893 main.c compiled on with gcc 4.9.2 Thanks, Fabian [1] https://imgur.com/a/9drmJHR ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] change_reply_status - dropping SDP from 183?
You can use something like
loadmodule "sipmsgops.so"
onreply_route[myreply] {
if (t_check_status("183")) {
change_reply_status("180", "Ringing");
remove_body_part("application/sdp");
}
}
Fabian
- Ursprüngliche Mail -
Von: "Monideth Pen"
An: "OpenSIPS users mailling list"
Gesendet: Freitag, 18. Oktober 2019 10:06:42
Betreff: [OpenSIPS-Users] change_reply_status - dropping SDP from 183?
Hi,
I am able to map 183 to 180 using the change_reply_status() function.
However, I would also like to drop SDP if it is present in the 183. How could I
achieve this?
Thank you.
___
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] Adding custom headers when sending REFER with t_new_request function
Hi,
The ctx parameter never worked for me, i allways got a
ERROR:tm:w_t_new_request: failed to add ctx AVP, ignorring...
for this.
I use something like
t_new_request("OPTIONS","sip:ping@TODOMAIN:5061;transport=tls","sip:pong@DOMAIN","sip:ping@DOMAIN");
local_route {
if (is_method("OPTIONS") && $rd == "TODOMAIN") {
append_hf("X-MY-HEADER: asdfasdf\n\n");
}
}
maybe this helps you a little bit..
Fabian
- Ursprüngliche Mail -
> Von: "Tekin, Arda"
> An: "OpenSIPS users mailling list"
> Gesendet: Mittwoch, 9. Oktober 2019 22:46:02
> Betreff: [OpenSIPS-Users] Adding custom headers when sending REFER with
> t_new_request function
> Hello,
>
>
>
> I am trying to initiate and send a REFER message from OpenSIPS after call hold
> signaling completed.
>
>
>
> t_new_request function of tm module allows to send this message immediately,
> this is how I used the function,
>
>
>
> t_new_request("REFER", "sip:moh@172.16.30.166", "1001 sip:1001@172.16.30.164",
> "1000 sip:1000@172.16.30.164", "text/plain Hello Alice!");
>
>
>
> but I need to add some extra headers into this message before sending it. As
> far
> as I understand the last parameter (ctx) of function is used for that purpose.
> Could you please explain how I can use last parameter in order to add multiple
> headers into message.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dialplan Help
If you just want to remove the "+" at the beginning, you can use something like
$avp(normalized) = $(avp(number){re.subst,/^\+//});
Fabian
>
> On Thu, 3 Oct 2019 at 11:35, Mark Farmer < [ mailto:farm...@gmail.com |
> farm...@gmail.com ] > wrote:
>
>
>
> Hi everyone
> I'm having a problem with my rule not matching, I'm trying to remove the + at
> the beginning of the input DID using a regex rule:
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] TLS Cypher Renegotiation & WireShark or SIPTrace
- Ursprüngliche Mail -
> Von: "JamesH"
>
> Alternatively without having to build a HOMER server how do I dump all sip
> traffic that OpenSIPS sends to & fro? I'm currently trying to use
> sip_trace("$var(trace_id)", "d"); but with no output. I've also gone for
> log level 4 but that doesn't get everything and Debug mode is segfaulting on
> OpenSSL versions and I don't want the pain of rebuilding the thing.
>
There are some solutions for this, i use something like
loadmodule "proto_hep.so"
loadmodule "siptrace.so"
listen = hep_udp:127.0.0.1:60667
modparam("proto_hep", "hep_id", "[hep_dst] 127.0.0.1:50667; version=2")
modparam("siptrace", "trace_on", 0)
modparam("siptrace", "trace_id", "[tid]uri=hep:hep_dst")
...
route{
sip_trace("tid");
in my configs.
Then, to get the traces,
ngrep -W byline -d lo port 50667
To enable the traces during runtime:
opensipsctl fifo sip_trace on
opensipsctl fifo sip_trace tid on
And grab the trace with:
ngrep -W byline -d lo port 50667
(Not sure why it is needed to enable both the global and the trace-id... )
Best,
Fabian
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Clusterer without a database
Hi,
add this:
loadmodule "db_text.so"
modparam("clusterer", "db_url", "text:///etc/opensips/db/")
In the database directory add two files
- version ( found in sources at scripts/dbtext/opensips/version )
- clusterer from scripts/dbtext/opensips/clusterer
Add your cluster nodes to 'clusterer' file like
id(int,auto) cluster_id(int) node_id(int) url(string) state(int)
no_ping_retries(int) priority(int) sip_addr(string,null) flags(string,null)
description(string,null)
1:200:1:bin\:192.168.99.201\:60200:1:3:50:NULL:NULL:node-a
2:200:2:bin\:192.168.99.202\:60200:1:3:50:NULL:NULL:node-b
Cheers,
Fabian
- Ursprüngliche Mail -
Von: "Callum Guy"
An: "OpenSIPS users mailling list"
Gesendet: Mittwoch, 8. August 2018 10:25:30
Betreff: [OpenSIPS-Users] Clusterer without a database
Hi All,
For "greater good" I thought it would be interesting to add some clusterer
dialog replication to my OpenSIPs pair.
Specifically I am on 2.4, installed the appropriate clusterer module and
applied the following configuration:
+# Replication listener
+listen=bin: [ http://172.18.0.112:5566/ | 172.18.0.112:5566 ]
+loadmodule "proto_bin.so"
+loadmodule "clusterer.so"
+
+# Setup replication cluster
+modparam("clusterer", "current_id", 2)
+modparam("clusterer", "db_mode", 0)
+modparam("clusterer", "current_info", "cluster_id=1, url=bin: [
http://172.18.0.112:5566/ | 172.18.0.112:5566 ] ") # data about this node
+modparam("clusterer", "neighbor_info", "cluster_id=1,node_id=1,url=bin: [
http://172.18.0.111:5566/ | 172.18.0.111:5566 ] ") # data about other node
+modparam("dialog", "dialog_replication_cluster", 1)
+modparam("dialog", "profile_replication_cluster", 1)
Once configured I attempted to start the service only to discover that
clusterer will not load without a database module. See below:
Aug 08 08:55:10 [ http://pci-fram-proxy2.x-onsecure.net/ |
pci-fram-proxy2.x-onsecure.net ] opensips-m4cfg[30867]: Aug 8 08:55:10 [30867]
WARNING:core:solve_module_dependencies: module clusterer depends on an sqldb
module, but none was loaded!
Aug 08 08:55:10 [ http://pci-fram-proxy2.x-onsecure.net/ |
pci-fram-proxy2.x-onsecure.net ] opensips-m4cfg[30867]: Aug 8 08:55:10 [30867]
ERROR:core:main: failed to solve module dependencies
For now I have simply reverted back however I wonder if this is a user error or
a module/documentation error?
Thanks,
Callum
--
Callum Guy
Head of Information Security
X-on
0333 332 | [ http://www.x-on.co.uk/ | www.x-on.co.uk ] | [
https://www.linkedin.com/company/x-on ] [ https://www.facebook.com/XonTel ] [
https://twitter.com/xonuk ]
X-on is a trading name of Storacall Technology Ltd a limited company registered
in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the addressee(s)
only. If you are not the intended recipient, please notify X-on immediately on
+44(0)333 332 and delete the
message from your computer. If you are not a named addressee you must not use,
disclose, disseminate, distribute, copy, print or reply to this email. Views or
opinions expressed by an individual
within this email may not necessarily reflect the views of X-on or its
associated companies. Although X-on routinely screens for viruses, addressees
should scan this email and any attachments
for viruses. X-on makes no representation or warranty as to the absence of
viruses in this email or any attachments.
___
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
