Re: [SR-Users] Releasing Kamailio v5.5.2
Just found some small sip_trace table definition issues this morning: https://github.com/kamailio/kamailio/issues/2831 On Friday, August 20, 2021 3:18:46 AM CDT Daniel-Constantin Mierla wrote: > Hello, > > I am considering to release Kamailio v5.5.2 sometime next week, likely > on Wednesday (August 25, 2021). This is the usual heads up > notification to see if anyone is aware of issues not yet reported to bug > tracker and if yes, do it as soon as possible to give them a chance to > be fixed. > > Cheers, > Daniel signature.asc Description: This is a digitally signed message part. __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Guidance tracking down "qm_free(): BUG: freeing already freed pointer"
Correct--that it when I see the "qm_free(): BUG: freeing already freed
pointer" error. -A
On Tuesday, July 27, 2021 9:05:45 AM CDT Daniel-Constantin Mierla wrote:
> Hello,
>
> to be clear for me: the error messages pop up only when outbound module
> is used and only for branches that are routed using outbound-specific
> connections?
>
> Cheers,
> Daniel
>
> On 25.07.21 04:55, Anthony Joseph Messina wrote:
> > I've come a bit further to find how to reproduce...
> >
> > I have a single proxy/registrar mhomed setup and am trying to use outbound
> > (rather than nathelper) to test a few UACs that seem to maintain their
> > connection better with outbound. (I am also using the dialog module).
> >
> > Everything else seems to work properly in light testing, except for the
> > "qm_free(): BUG" issue, which only pops up when an "outbound" UAC is one
> > of
> > the branches (the other branches are not using outbound and are always
> > directly connected on the "internal" side of the mhomed network.
> >
> > !define WITH_NAT -- disabled for outbound
> > #!define WITH_OUTBOUND
> >
> > #!ifdef WITH_OUTBOUND
> > modparam("registrar", "outbound_mode", 1)
> > modparam("registrar", "flow_timer", 25)
> > #!endif
> >
> > Snippet of the WITHINDLG route:
> >
> > # Handle requests within SIP dialogs
> > route[WITHINDLG] {
> >
> > if(!has_totag()) return;
> >
> > # sequential request withing a dialog should
> > # take the path determined by record-routing
> > if(loose_route()) {
> >
> > # dlg_manage() with dlg_match_mode=2
> > dlg_manage();
> >
> > #route(DLGURI); -- NAT disabled
> >
> > On Friday, July 23, 2021 9:08:37 AM CDT Anthony Joseph Messina wrote:
> >> It's built upon the standard branch_route, but is customized to add
> >> rtpengine and dialog storage.
> >>
> >> I've attached the related routes. Thanks. -A
> >>
> >> On Friday, July 23, 2021 2:43:04 AM CDT Daniel-Constantin Mierla wrote:
> >>> Hello,
> >>>
> >>> is it a custom configuration file or simply the default kamailio.cfg
> >>> with parts of branch_route enabled/disabled? If it is custom, can you
> >>> paste here the content of the branch route that you disable/enable parts
> >>> of it and get the error messages?
> >>>
> >>> Overall, seem like trying to (re-)use a terminated transaction or
> >>> branch.
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>> On 23.07.21 00:19, Anthony Joseph Messina wrote:
> >>>> I'm seeking guidance on how to track down "qm_free(): BUG: freeing
> >>>> already
> >>>> freed pointer" which occurs only on branched calls. These errors don't
> >>>> crash so I don't get any core dumps. The different log entries below
> >>>> are
> >>>> the result of me selectively disabling sections of the script that
> >>>> apply
> >>>> in branch route, all to no avail. I'm running Kamailio on the current
> >>>> tip of the 5.5 branch (1f9f6fff6e). I'm reviewing
> >>>> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory in the
> >>>> meantime as a place to start.
> >>>>
> >>>>
> >>>> version: kamailio 5.5.1-5.git1f9f6fff6e.fc34 (x86_64/linux) 7abebb
> >>>> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> >>>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> >>>> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
> >>>> FAST_LOCK-ADAPTIVE_WAIT,
> >>>> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
> >>>> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024,
> >>>> MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT
> >>>> PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt,
> >>>> select.
> >>>>
> >>>> CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing
> >>>> already freed pointer (0x7f04b8f47e90), called from core:
> >>>> core/data_lump.c: free_lump(470), first free textops: textops.c:
> >>>&
Re: [SR-Users] Guidance tracking down "qm_free(): BUG: freeing already freed pointer"
I've come a bit further to find how to reproduce...
I have a single proxy/registrar mhomed setup and am trying to use outbound
(rather than nathelper) to test a few UACs that seem to maintain their
connection better with outbound. (I am also using the dialog module).
Everything else seems to work properly in light testing, except for the
"qm_free(): BUG" issue, which only pops up when an "outbound" UAC is one of
the branches (the other branches are not using outbound and are always
directly connected on the "internal" side of the mhomed network.
!define WITH_NAT -- disabled for outbound
#!define WITH_OUTBOUND
#!ifdef WITH_OUTBOUND
modparam("registrar", "outbound_mode", 1)
modparam("registrar", "flow_timer", 25)
#!endif
Snippet of the WITHINDLG route:
# Handle requests within SIP dialogs
route[WITHINDLG] {
if(!has_totag()) return;
# sequential request withing a dialog should
# take the path determined by record-routing
if(loose_route()) {
# dlg_manage() with dlg_match_mode=2
dlg_manage();
#route(DLGURI); -- NAT disabled
On Friday, July 23, 2021 9:08:37 AM CDT Anthony Joseph Messina wrote:
> It's built upon the standard branch_route, but is customized to add
> rtpengine and dialog storage.
>
> I've attached the related routes. Thanks. -A
>
> On Friday, July 23, 2021 2:43:04 AM CDT Daniel-Constantin Mierla wrote:
> > Hello,
> >
> > is it a custom configuration file or simply the default kamailio.cfg
> > with parts of branch_route enabled/disabled? If it is custom, can you
> > paste here the content of the branch route that you disable/enable parts
> > of it and get the error messages?
> >
> > Overall, seem like trying to (re-)use a terminated transaction or branch.
> >
> > Cheers,
> > Daniel
> >
> > On 23.07.21 00:19, Anthony Joseph Messina wrote:
> > > I'm seeking guidance on how to track down "qm_free(): BUG: freeing
> > > already
> > > freed pointer" which occurs only on branched calls. These errors don't
> > > crash so I don't get any core dumps. The different log entries below
> > > are
> > > the result of me selectively disabling sections of the script that apply
> > > in branch route, all to no avail. I'm running Kamailio on the current
> > > tip of the 5.5 branch (1f9f6fff6e). I'm reviewing
> > > https://www.kamailio.org/wiki/tutorials/troubleshooting/memory in the
> > > meantime as a place to start.
> > >
> > >
> > > version: kamailio 5.5.1-5.git1f9f6fff6e.fc34 (x86_64/linux) 7abebb
> > > flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> > > DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> > > F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
> > > FAST_LOCK-ADAPTIVE_WAIT,
> > > USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
> > > HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024,
> > > MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT
> > > PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt,
> > > select.
> > >
> > > CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing
> > > already freed pointer (0x7f04b8f47e90), called from core:
> > > core/data_lump.c: free_lump(470), first free textops: textops.c:
> > > add_hf_helper(3474) - ignoring CRITICAL:
> > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer
> > > (0x7f04b8f06c70), called from core: core/data_lump.c: free_lump(470),
> > > first free textops: textops.c: add_hf_helper(3474) - ignoring CRITICAL:
> > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
> > > pointer (0x7f08e8f9cf80), called from core: core/data_lump.c:
> > > free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994)
> > > - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG:
> > > freeing already freed pointer (0x7f2afafa60d8), called from core:
> > > core/parser/sdp/sdp.c: free_sdp(825), first free core:
> > > core/parser/sdp/sdp.c: init_p_payload_attr(183) - ignoring CRITICAL:
> > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed
> > > pointer (0x7f2afae2a018), called from core: core/data_lump.c:
> > > free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994)
> > > - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG:
> > > freeing already freed pointer (0
Re: [SR-Users] Guidance tracking down "qm_free(): BUG: freeing already freed pointer"
It's built upon the standard branch_route, but is customized to add rtpengine and dialog storage. I've attached the related routes. Thanks. -A On Friday, July 23, 2021 2:43:04 AM CDT Daniel-Constantin Mierla wrote: > Hello, > > is it a custom configuration file or simply the default kamailio.cfg > with parts of branch_route enabled/disabled? If it is custom, can you > paste here the content of the branch route that you disable/enable parts > of it and get the error messages? > > Overall, seem like trying to (re-)use a terminated transaction or branch. > > Cheers, > Daniel > > On 23.07.21 00:19, Anthony Joseph Messina wrote: > > I'm seeking guidance on how to track down "qm_free(): BUG: freeing already > > freed pointer" which occurs only on branched calls. These errors don't > > crash so I don't get any core dumps. The different log entries below are > > the result of me selectively disabling sections of the script that apply > > in branch route, all to no avail. I'm running Kamailio on the current > > tip of the 5.5 branch (1f9f6fff6e). I'm reviewing > > https://www.kamailio.org/wiki/tutorials/troubleshooting/memory in the > > meantime as a place to start. > > > > > > version: kamailio 5.5.1-5.git1f9f6fff6e.fc34 (x86_64/linux) 7abebb > > flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, > > DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, > > F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, > > USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, > > HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, > > MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT > > PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, > > select. > > > > CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing > > already freed pointer (0x7f04b8f47e90), called from core: > > core/data_lump.c: free_lump(470), first free textops: textops.c: > > add_hf_helper(3474) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer > > (0x7f04b8f06c70), called from core: core/data_lump.c: free_lump(470), > > first free textops: textops.c: add_hf_helper(3474) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed > > pointer (0x7f08e8f9cf80), called from core: core/data_lump.c: > > free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) > > - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: > > freeing already freed pointer (0x7f2afafa60d8), called from core: > > core/parser/sdp/sdp.c: free_sdp(825), first free core: > > core/parser/sdp/sdp.c: init_p_payload_attr(183) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed > > pointer (0x7f2afae2a018), called from core: core/data_lump.c: > > free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) > > - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: > > freeing already freed pointer (0x7f2afae431e8), called from core: > > core/data_lump.c: free_lump(470), first free core: > > core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer > > (0x7f2afafa3900), called from core: core/data_lump.c: free_lump(470), > > first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring > > CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing > > already freed pointer (0x7f5fd4044ef0), called from core: > > core/data_lump.c: free_lump(470), first free core: > > core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer > > (0x7ffbb2d2e2f0), called from core: core/data_lump.c: free_lump(470), > > first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring > > CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing > > already freed pointer (0x7f6d1a50b1d8), called from core: > > core/data_lump.c: free_lump(470), first free core: > > core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer > > (0x7fc19c165c70), called from core: core/parser/msg_parser.c: > > reset_instance(916), first free core: core/parser/parse_addr_spec.c: > > free_to_params(895) - ignoring CRITICAL: > > [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer > > (0x7fc19c17adb8), called from core: c
[SR-Users] Guidance tracking down "qm_free(): BUG: freeing already freed pointer"
I'm seeking guidance on how to track down "qm_free(): BUG: freeing already freed pointer" which occurs only on branched calls. These errors don't crash so I don't get any core dumps. The different log entries below are the result of me selectively disabling sections of the script that apply in branch route, all to no avail. I'm running Kamailio on the current tip of the 5.5 branch (1f9f6fff6e). I'm reviewing https://www.kamailio.org/wiki/tutorials/troubleshooting/memory in the meantime as a place to start. version: kamailio 5.5.1-5.git1f9f6fff6e.fc34 (x86_64/linux) 7abebb flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f04b8f47e90), called from core: core/data_lump.c: free_lump(470), first free textops: textops.c: add_hf_helper(3474) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f04b8f06c70), called from core: core/data_lump.c: free_lump(470), first free textops: textops.c: add_hf_helper(3474) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f08e8f9cf80), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f2afafa60d8), called from core: core/parser/sdp/sdp.c: free_sdp(825), first free core: core/parser/sdp/sdp.c: init_p_payload_attr(183) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f2afae2a018), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f2afae431e8), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f2afafa3900), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f5fd4044ef0), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7ffbb2d2e2f0), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f6d1a50b1d8), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7fc19c165c70), called from core: core/parser/msg_parser.c: reset_instance(916), first free core: core/parser/parse_addr_spec.c: free_to_params(895) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7fc19c17adb8), called from core: core/parser/msg_parser.c: reset_instance(916), first free core: core/parser/parse_addr_spec.c: free_to_params(895) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7fc19c125790), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f4d969c9d48), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7fc29bdca3d0), called from core: core/data_lump.c: free_lump(470), first free textops: textops.c: add_hf_helper(3474) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7fc2c2eccc80), called from core: core/data_lump.c: free_lump(470), first free textops: textops.c: add_hf_helper(3474) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7fc2c2ec52c0), called from core: core/data_lump.c: free_lump(470), first free core: core/parser/msg_parser.c: reset_ua(994) - ignoring CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: fre
Re: [SR-Users] Kamailio/rtpengine not populating mos avp stats?
It does indeed. Thank you! -A On Thursday, July 22, 2021 11:19:56 AM CDT Richard Fuchs wrote: > This should be fixed now. > > Cheers > > On 20/07/2021 20.23, [ EXT ] Anthony Joseph Messina wrote: > > Yep. No problem -- that's why I wanted to ask first. Thanks again. I'll > > keep an eye out. -A > > > > On Tuesday, July 20, 2021 6:46:40 PM CDT Richard Fuchs wrote: > >> I haven't had a chance to look at it yet. There's been a lot of > >> construction going on in current master (and some more to come) so it's > >> quite possible that this is fallout from that. > >> > >> Cheers > >> > >> > >> On 20/07/2021 19.15, [ EXT ] Anthony Joseph Messina wrote: > >> Thanks, Henning. I rebuilt with that commit reverted and it didn't make > >> a > >> difference. I wasn't sure if there were rtpengine-side changes or > >> kamailio- side changes that might be necessary. I've seen @rfuchs chime > >> in on this list from time-to-time so I'll gather up some more > >> information before filing a ticket. -A > >> > >> On Tuesday, July 20, 2021 9:00:38 AM CDT Henning Westerholt wrote: > >> Hello, > >> > >> one month ago was a fix in this area (4399fe5243), but not much changes > >> since then. > >> > >> If no reply from somebody else that observe a similar issue, just create > >> an > >> issue on our github tracker with more details. > >> > >> Cheers, > >> > >> Henning > >> > >> -- > >> Henning Westerholt - https://skalatan.de/blog/ > >> Kamailio services - https://gilawa.com > >> > >> -Original Message- > >> From: sr-users On Behalf Of Anthony > >> Joseph Messina Sent: Saturday, July 17, 2021 7:06 AM > >> To: Kamailio Users Mailing List > >> Subject: [SR-Users] Kamailio/rtpengine not populating mos avp stats? > >> > >> I'm using Kamailio compiled from the current 5.5 tip (1f9f6fff6e), and > >> rtpengine compiled from the current master (6e160da4). > >> > >> While rtpengine is working quite well, within the past month or so, I've > >> noticed that Kamailio isn't populating the mos* related AVPs. I see > >> continued upstream rtpengine work stream handling, etc. -- should I wait > >> or > >> try to debug? > >> > >> Thanks -A signature.asc Description: This is a digitally signed message part. __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio/rtpengine not populating mos avp stats?
Yep. No problem -- that's why I wanted to ask first. Thanks again. I'll keep an eye out. -A On Tuesday, July 20, 2021 6:46:40 PM CDT Richard Fuchs wrote: > I haven't had a chance to look at it yet. There's been a lot of construction > going on in current master (and some more to come) so it's quite possible > that this is fallout from that. > > Cheers > > > On 20/07/2021 19.15, [ EXT ] Anthony Joseph Messina wrote: > Thanks, Henning. I rebuilt with that commit reverted and it didn't make a > difference. I wasn't sure if there were rtpengine-side changes or kamailio- > side changes that might be necessary. I've seen @rfuchs chime in on this > list from time-to-time so I'll gather up some more information before > filing a ticket. -A > > On Tuesday, July 20, 2021 9:00:38 AM CDT Henning Westerholt wrote: > Hello, > > one month ago was a fix in this area (4399fe5243), but not much changes > since then. > > If no reply from somebody else that observe a similar issue, just create an > issue on our github tracker with more details. > > Cheers, > > Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio services - https://gilawa.com > > -Original Message- > From: sr-users On Behalf Of Anthony > Joseph Messina Sent: Saturday, July 17, 2021 7:06 AM > To: Kamailio Users Mailing List > Subject: [SR-Users] Kamailio/rtpengine not populating mos avp stats? > > I'm using Kamailio compiled from the current 5.5 tip (1f9f6fff6e), and > rtpengine compiled from the current master (6e160da4). > > While rtpengine is working quite well, within the past month or so, I've > noticed that Kamailio isn't populating the mos* related AVPs. I see > continued upstream rtpengine work stream handling, etc. -- should I wait or > try to debug? > > Thanks -A signature.asc Description: This is a digitally signed message part. __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio/rtpengine not populating mos avp stats?
Thanks, Henning. I rebuilt with that commit reverted and it didn't make a difference. I wasn't sure if there were rtpengine-side changes or kamailio- side changes that might be necessary. I've seen @rfuchs chime in on this list from time-to-time so I'll gather up some more information before filing a ticket. -A On Tuesday, July 20, 2021 9:00:38 AM CDT Henning Westerholt wrote: > Hello, > > one month ago was a fix in this area (4399fe5243), but not much changes > since then. > > If no reply from somebody else that observe a similar issue, just create an > issue on our github tracker with more details. > > Cheers, > > Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio services - https://gilawa.com > > -----Original Message- > From: sr-users On Behalf Of Anthony > Joseph Messina Sent: Saturday, July 17, 2021 7:06 AM > To: Kamailio Users Mailing List > Subject: [SR-Users] Kamailio/rtpengine not populating mos avp stats? > > I'm using Kamailio compiled from the current 5.5 tip (1f9f6fff6e), and > rtpengine compiled from the current master (6e160da4). > > While rtpengine is working quite well, within the past month or so, I've > noticed that Kamailio isn't populating the mos* related AVPs. I see > continued upstream rtpengine work stream handling, etc. -- should I wait or > try to debug? > > Thanks -A signature.asc Description: This is a digitally signed message part. __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio/rtpengine not populating mos avp stats?
I'm using Kamailio compiled from the current 5.5 tip (1f9f6fff6e), and rtpengine compiled from the current master (6e160da4). While rtpengine is working quite well, within the past month or so, I've noticed that Kamailio isn't populating the mos* related AVPs. I see continued upstream rtpengine work stream handling, etc. -- should I wait or try to debug? Thanks -A -- Anthony - https://messinet.com CCED 8BFB 88D9 18F6 9F68 93DC 45C4 A8CE A64E 88E3 signature.asc Description: This is a digitally signed message part. __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] http_client/http_connect in request_route: INFO: [main.c:857]: sig_usr(): signal 13 received
With the following config
# - http_client params -
modparam("http_client", "httpredirect", 0)
modparam("http_client", "connection_timeout", 2)
modparam("http_client", "keep_connections", 1)
modparam("http_client", "query_result", 0)
modparam("http_client", "httpcon", "api=>https://api.example.com";);
and after calling the following from request_route,
$xavu(http=>rs)=http_connect("api",
"/kamailio/message",
"application/json", "$var(message_api)",
"$xavu(http=>rb)");
if($xavu(http=>rs)==200) {
jansson_get("result.code", $xavu(http=>rb), "$xavu(http=>code)");
jansson_get("result.message", $xavu(http=>rb), "$xavu(http=>message)");
sd_journal_print("LOG_DEBUG", "[$cfg(route)] Result: $xavu(http=>code),
$xavu(http=>message)");
sl_send_reply("202", "Accepted");
exit;
}
I see the following in the log:
INFO: [main.c:857]: sig_usr(): signal 13 received
It doesn't seem to have any negative effect, but I am wondering if it's
something I should look into. If so, any pointers on where/how to begin?
--
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] http_async_client expected result in $http_rr
After a bit more research, it seems that since my connection is using HTTP/2,
there is no Reason-Phrase... So I'll need to parse the json in the body.
https://tools.ietf.org/html/rfc7540#section-8.1.2.4
DEBUG: http_async_client [async_http.c:162]: async_http_cb(): query result =
HTTP/2 202
date: Wed, 10 Feb 2021 18:59:10 GMT
server: Apache/2.4.46
strict-transport-security: max-age=15552000; includeSubDomains
content-length: 46
vary: User-Agent
content-type: application/json; charset=utf-8
{"result": {"code": 202, "title": "Accepted"}} [270]
On Wednesday, February 10, 2021 1:24:09 AM CST Federico Cabiddu wrote:
> Hi,
> just tested on latest 5.4 (ubuntu 20.04, curl 7.68.0) and http_rr works as
> expected, returning the reason phrase.
> Can you give some more detail and maybe run a test with increased debug
> level?
>
> Regards,
>
> Federico
>
>
> On Wed, Feb 10, 2021 at 4:14 AM Anthony Joseph Messina <
>
> amess...@messinet.com> wrote:
> > https://www.kamailio.org/docs/modules/stable/modules/http_async_client
> > says
> > $http_rr will be the HTTP reason phrase. I'm understanding this to mean:
> >
> > Code: Reason:
> > 200 OK
> > 404 Not Found
> >
> > In my current 5.4 build, $http_rr returns empty (not or anything
> > else)
> > regardless of what the server sends in the headers.
> >
> > Am I misunderstanding this? I'm writing an API and was hoping to do
> >
> > send_reply("$http_rs", "$http_rr");
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] http_async_client expected result in $http_rr
https://www.kamailio.org/docs/modules/stable/modules/http_async_client says
$http_rr will be the HTTP reason phrase. I'm understanding this to mean:
Code: Reason:
200 OK
404 Not Found
In my current 5.4 build, $http_rr returns empty (not or anything else)
regardless of what the server sends in the headers.
Am I misunderstanding this? I'm writing an API and was hoping to do
send_reply("$http_rs", "$http_rr");
--
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Releasing Kamailio v5.4.4
I'd like to see the fix for --atexit=yes|no https://github.com/kamailio/ kamailio/issues/2616 implemented in master (https://github.com/kamailio/ kamailio/issues/2616#issuecomment-772512372) be backported, perhaps with a quick look into https://github.com/kamailio/kamailio/issues/2632 I realize part of --atexit=yes|no is a new feature, but it also enables http_async_query to work with TLS in 5.4, so also a bug fix (I'm hoping you think so too). Thank you. On Tuesday, February 9, 2021 7:40:52 AM CST Daniel-Constantin Mierla wrote: > Hello, > > I am considering to release Kamailio v5.4.4 sometime next week, likely > on Monday, February 15, 2020. This is the usual heads up notification to > see if anyone is aware of issues not yet reported to bug tracker and if > yes, do it as soon as possible to give them a chance to be fixed. > > Cheers, > Daniel signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Releasing Kamailio v5.4.1
It does happen every time. I'll see if I can get a full trace, though unfortunately it may not be until later this week. -A On Tuesday, September 1, 2020 1:21:40 AM CDT Daniel-Constantin Mierla wrote: > That's indeed on shutdown, depending on what the server is doing at that > time, some races may still happen. Do you get it every time? Anyhow, a > full trace would be good to have, the crash is anyhow inside libssl, but > can be because of shared memory being released... > > Cheers, > Daniel > > On 01.09.20 01:24, Anthony Joseph Messina wrote: > > On Monday, August 31, 2020 9:52:06 AM CDT Daniel-Constantin Mierla wrote: > >> Hello, > >> > >> quick reminder for the plans to release v5.4.1 tomorrow, just in case > >> someone has encountered any (potential) issue in the 5.4 branch and it > >> is not reported, do it so we can have a look and maybe it can be fixed > >> in time for the patch release. > >> > >> Cheers, > >> Daniel > > > > I've run into the following crash on exit using Kamailio built using the > > 5.4 branch up to e9baba91c6. > > > > I haven't had time to do a full trace or investigate more deeply as we're > > quite busy at work.> > > Stack trace of thread 191257: > > #0 0x7f3203393056 ossl_init_thread_stop > > (libcrypto.so.1.1 + 0x186056) > > #1 0x7f320339335f OPENSSL_cleanup (libcrypto.so.1.1 + > > 0x18635f) > > #2 0x7f32041013a7 __run_exit_handlers (libc.so.6 + > > 0x3f3a7) > > #3 0x7f3204101550 exit (libc.so.6 + 0x3f550) > > #4 0x0041f61a handle_sigs (kamailio + 0x1f61a) > > #5 0x0042c61c main_loop (kamailio + 0x2c61c) > > #6 0x00434cbd main (kamailio + 0x34cbd) > > #7 0x7f32040e9042 __libc_start_main (libc.so.6 + > > 0x27042) > > #8 0x0041bbde _start (kamailio + 0x1bbde) signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Releasing Kamailio v5.4.1
On Monday, August 31, 2020 9:52:06 AM CDT Daniel-Constantin Mierla wrote: > Hello, > > quick reminder for the plans to release v5.4.1 tomorrow, just in case > someone has encountered any (potential) issue in the 5.4 branch and it > is not reported, do it so we can have a look and maybe it can be fixed > in time for the patch release. > > Cheers, > Daniel I've run into the following crash on exit using Kamailio built using the 5.4 branch up to e9baba91c6. I haven't had time to do a full trace or investigate more deeply as we're quite busy at work. Stack trace of thread 191257: #0 0x7f3203393056 ossl_init_thread_stop (libcrypto.so.1.1 + 0x186056) #1 0x7f320339335f OPENSSL_cleanup (libcrypto.so.1.1 + 0x18635f) #2 0x7f32041013a7 __run_exit_handlers (libc.so.6 + 0x3f3a7) #3 0x7f3204101550 exit (libc.so.6 + 0x3f550) #4 0x0041f61a handle_sigs (kamailio + 0x1f61a) #5 0x0042c61c main_loop (kamailio + 0x2c61c) #6 0x00434cbd main (kamailio + 0x34cbd) #7 0x7f32040e9042 __libc_start_main (libc.so.6 + 0x27042) #8 0x0041bbde _start (kamailio + 0x1bbde) -- Anthony - https://messinet.com F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway
Ok, Daniel. You were correct in pointing out my improper placement of the
set_forward_no_connect().
I was trying to find a way to insert the command in the most efficient place.
I have been testing with various nat/no-nat situations and think the following
will do what it should and avoid the additional calls to "if(is_request())"
and "if(has_totag())":
route[NATMANAGE] {
#!ifdef WITH_NAT
if(is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
##->INSERT HERE: no connect message in a dialog involving NAT traversal
if(isbflagset(FLB_NATB)) {
set_forward_no_connect();
}
}
}
if(!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
# We are sending everything to route(RTPENGINE_MANAGE) separately
# for more specific handling and bridging, not only based on NAT
# route(RTPENGINE_MANAGE);
if(is_request()) {
if(!has_totag()) {
if(t_is_branch_route()) {
add_rr_param(";nat=yes");
}
}
}
if(is_reply()) {
if(isbflagset(FLB_NATB)) {
if(is_first_hop()) {
# Skip for GRUU
if(@contact.uri!="" && !is_gruu(@contact.uri))
set_contact_alias();
}
}
}
# if(isbflagset(FLB_NATB)) {
# if(is_request()) {
# if(has_totag()) {
# set_forward_no_connect();
# }
# }
# }
#!endif
return;
}
On Wednesday, September 18, 2019 1:50:46 AM CDT Daniel-Constantin Mierla
wrote:
> On 15.09.19 03:34, Anthony Joseph Messina wrote:
> > I'm going to keep testing against the issue I originally reported, and
> > probably wait until after 5.3 is released. My issue may also be related
> > to a combination of TCPOPS keepalive not keeping the proper connection
> > open for
> >
> > UAC -> Kamailio/LCR -> TLS Gateway
> >
> > The connection that's kept open to the TLS Gateway is the original forward
> > of the INVITE
> >
> > : -> :
> >
> > The subsequent in-dialog connections (such as BYE from the UAC to the TLS
> > Gateway) don't use the original TLS connection so they are prevented from
> > re- connecting to the TLS Gateway.
> >
> > Again, I have to do more testing to clear up the root issue on my end.
> >
> > Also, for a more compact config, would the following achieve the same
> > thing...
> >
> >
> > route[NATMANAGE] {
> > #!ifdef WITH_NAT
> >
> > if(is_request()) {
> >
> > if(has_totag()) {
> >
> > if(check_route_param("nat=yes")) {
> >
> > setbflag(FLB_NATB);
> >
> > ### Add the command here
> >
> > set_forward_no_connect();
> >
> > }
> >
> > }
> >
> > }
> >
> > ...
>
> You have to differentiate between calls with one side behind nat and the
> other one on a pubic IP that is like a server/gateway and can accept new
> connections, even for requests within dialog.
>
> My initial change to the default config file was done in the perspective
> that the respective configuration is routing between local users, where
> is not common for a user device to register, then close the connection,
> because it was using a ephemeral port anyhow.
>
> Cheers,
> Daniel
>
> > On Wednesday, September 11, 2019 1:21:34 AM CDT Daniel-Constantin Mierla
> >
> > wrote:
> >> It no longer looks like an issue related to set_reply_no_connect() or
> >> set_forward_no_connect() added by the commit you referenced. Those were
> >> added to prevent attempting to connect to devices behind the nat (in
> >> that case the device has to maintain the connection, otherwise nobody
> >> can connect back to it) as well as prevent someone in the wild sending a
> >> request then closing the connection, without waiting for the reply,
> >> which is typically routed back to via, commonly with an ephemeral port.
> >&
Re: [SR-Users] TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway
I'm going to keep testing against the issue I originally reported, and
probably wait until after 5.3 is released. My issue may also be related to a
combination of TCPOPS keepalive not keeping the proper connection open for
UAC -> Kamailio/LCR -> TLS Gateway
The connection that's kept open to the TLS Gateway is the original forward of
the INVITE
: -> :
The subsequent in-dialog connections (such as BYE from the UAC to the TLS
Gateway) don't use the original TLS connection so they are prevented from re-
connecting to the TLS Gateway.
Again, I have to do more testing to clear up the root issue on my end.
Also, for a more compact config, would the following achieve the same thing...
route[NATMANAGE] {
#!ifdef WITH_NAT
if(is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
### Add the command here
set_forward_no_connect();
}
}
}
...
On Wednesday, September 11, 2019 1:21:34 AM CDT Daniel-Constantin Mierla
wrote:
> It no longer looks like an issue related to set_reply_no_connect() or
> set_forward_no_connect() added by the commit you referenced. Those were
> added to prevent attempting to connect to devices behind the nat (in
> that case the device has to maintain the connection, otherwise nobody
> can connect back to it) as well as prevent someone in the wild sending a
> request then closing the connection, without waiting for the reply,
> which is typically routed back to via, commonly with an ephemeral port.
>
> The follow up commit I did it in master recently is no longer setting
> the flag for requests within dialog, but I understand you have
> connection problems for requests within dialog, am I right?
>
> Cheers,
> Daniel
>
> On 10.09.19 01:08, Anthony Joseph Messina wrote:
> > I still ran into some trouble when one side was NAT'd.
> >
> > Am I correct in thinking that it would be undesirable to maintain a
> > TCP/TLS
> > connection to an upstream TLS gateway that is using the well-known port
> > 5061?
> >
> > I was thinking this may be a case for TCP_REUSEPORT and force_send_socket,
> > but that seems a little complex seeing as I can just let Kamailio
> > reconnect (when necessary) rather than preventing the outbound TLS from
> > connecting when it would otherwise succeed.
> >
> > I'll try and work through more detailed configuration scenarios. -A
> >
> > On Monday, September 9, 2019 2:12:07 AM CDT Daniel-Constantin Mierla
wrote:
> >> Hello,
> >>
> >> I relaxed that condition to not connect on forwarding only for initial
> >> requests going though nat. Can you test with latest master and see how
> >> is going for your use case?
> >>
> >> Cheers,
> >> Daniel
> >>
> >> On 09.09.19 02:00, Anthony Joseph Messina wrote:
> >>> In preparation for the 5.3 release, I've been testing the following
> >>> configuration change for TCP/TLS connections:
> >>>
> >>> https://github.com/kamailio/kamailio/commit/
> >>> 8bba208fe6ae7ccb4c92362b8c33f1530b9f56da
> >>>
> >>> route[REQINIT] {
> >>>
> >>> # no connect for sending replies
> >>> set_reply_no_connect();
> >>> if(has_totag()) {
> >>>
> >>> # no connect for requests within dialog
> >>> set_forward_no_connect();
> >>>
> >>> }
> >>>
> >>> This change creates issues when a UAC TLS INVITE routes to an upstream
> >>> gateway using TLS to port 5061 (via the LCR module). Kamailio sends the
> >>> initial outbound TLS connection from a local ephemeral port. The TCPOPS
> >>> tcp_keepalive_enable function issues keepalives from the local ephemeral
> >>> port to the gateway port 5061:
> >>>
> >>> https://kamailio.org/docs/modules/stable/modules/
> >>> tcpops#tcpops.f.tcp_keepalive_enable
> >>>
> >>> Even so, the TLS connection eventually times out, after which in-dialog
> >>> requests from the UAC are no longer able to reach the upstream gateway.
> >>>
> >>> ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed
> >>> WARNING: tm [t_fwd.c:1570]: t_send_branch(): sending request on branch 0
> >>> failed
> >>> ERROR: sl [sl_funcs.c:372]: sl_reply_error(): stateless error reply
> >>> used:
> >>> Unfortunately error on sending to next hop occurred (477/SL)
> >>>
> >>> I figure I must be doing something wrong with my TCPOPS here. Is a TLS
> >>> connection to an upstream gateway supposed to be maintained throughout
> >>> the
> >>> duration of a call?
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway
I still ran into some trouble when one side was NAT'd.
Am I correct in thinking that it would be undesirable to maintain a TCP/TLS
connection to an upstream TLS gateway that is using the well-known port 5061?
I was thinking this may be a case for TCP_REUSEPORT and force_send_socket, but
that seems a little complex seeing as I can just let Kamailio reconnect (when
necessary) rather than preventing the outbound TLS from connecting when it
would otherwise succeed.
I'll try and work through more detailed configuration scenarios. -A
On Monday, September 9, 2019 2:12:07 AM CDT Daniel-Constantin Mierla wrote:
> Hello,
>
> I relaxed that condition to not connect on forwarding only for initial
> requests going though nat. Can you test with latest master and see how
> is going for your use case?
>
> Cheers,
> Daniel
>
> On 09.09.19 02:00, Anthony Joseph Messina wrote:
> > In preparation for the 5.3 release, I've been testing the following
> > configuration change for TCP/TLS connections:
> >
> > https://github.com/kamailio/kamailio/commit/
> > 8bba208fe6ae7ccb4c92362b8c33f1530b9f56da
> >
> > route[REQINIT] {
> >
> > # no connect for sending replies
> > set_reply_no_connect();
> > if(has_totag()) {
> >
> > # no connect for requests within dialog
> > set_forward_no_connect();
> >
> > }
> >
> > This change creates issues when a UAC TLS INVITE routes to an upstream
> > gateway using TLS to port 5061 (via the LCR module). Kamailio sends the
> > initial outbound TLS connection from a local ephemeral port. The TCPOPS
> > tcp_keepalive_enable function issues keepalives from the local ephemeral
> > port to the gateway port 5061:
> >
> > https://kamailio.org/docs/modules/stable/modules/
> > tcpops#tcpops.f.tcp_keepalive_enable
> >
> > Even so, the TLS connection eventually times out, after which in-dialog
> > requests from the UAC are no longer able to reach the upstream gateway.
> >
> > ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed
> > WARNING: tm [t_fwd.c:1570]: t_send_branch(): sending request on branch 0
> > failed
> > ERROR: sl [sl_funcs.c:372]: sl_reply_error(): stateless error reply used:
> > Unfortunately error on sending to next hop occurred (477/SL)
> >
> > I figure I must be doing something wrong with my TCPOPS here. Is a TLS
> > connection to an upstream gateway supposed to be maintained throughout the
> > duration of a call?
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway
In preparation for the 5.3 release, I've been testing the following
configuration change for TCP/TLS connections:
https://github.com/kamailio/kamailio/commit/
8bba208fe6ae7ccb4c92362b8c33f1530b9f56da
route[REQINIT] {
# no connect for sending replies
set_reply_no_connect();
if(has_totag()) {
# no connect for requests within dialog
set_forward_no_connect();
}
This change creates issues when a UAC TLS INVITE routes to an upstream gateway
using TLS to port 5061 (via the LCR module). Kamailio sends the initial
outbound TLS connection from a local ephemeral port. The TCPOPS
tcp_keepalive_enable function issues keepalives from the local ephemeral port
to the gateway port 5061:
https://kamailio.org/docs/modules/stable/modules/
tcpops#tcpops.f.tcp_keepalive_enable
Even so, the TLS connection eventually times out, after which in-dialog
requests from the UAC are no longer able to reach the upstream gateway.
ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed
WARNING: tm [t_fwd.c:1570]: t_send_branch(): sending request on branch 0
failed
ERROR: sl [sl_funcs.c:372]: sl_reply_error(): stateless error reply used:
Unfortunately error on sending to next hop occurred (477/SL)
I figure I must be doing something wrong with my TCPOPS here. Is a TLS
connection to an upstream gateway supposed to be maintained throughout the
duration of a call?
--
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio+asterisk VoiceMail implementation
On Wednesday, August 28, 2019 6:37:43 AM CDT Zhan Bazarov wrote: > Hello, > > what's best practice for VoiceMail implementation in Kamailio+Asterisk's > scheme? > > should I forward register into asterisk? Or I can keep register on > kamailio? > Could you, please, shed any lights on this I register users in Kamailio, forwarding INVITEs to Voicemail in Asterisk as necessary. Asterisk doesn't natively PUBLISH mwi to Kamailio, so I use the script as detailed here [1] and Asterisk's externnotify capability to generate the PUBLISH in Kamailio. I don't know if that's "best practice" but I don't want Asterisk involved in every call so I don't have every endpoint registered through to Asterisk. [1]: https://lists.kamailio.org/pipermail/sr-users/2019-February/104699.html -- Anthony - https://messinet.com F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Releasing Kamailio v5.2.2
Thank you for the reply, Daniel. I'll check the IRC logs after work today and cherry-pick in the meantime. -A On Monday, March 11, 2019 2:21:24 AM CDT Daniel-Constantin Mierla wrote: > Hello, > > they look like new features, which we do not backport to stable branches. > Only fixes, improvements to docs and tools (e.g., kamctl) or missing > compatibility to kemi scripting (when no major impact) are eligible for > backporting. > > Later today we will have the IRC devel meeting and decide when the next > major release should be planned to be out, then you can have an estimation > when 5.3.0 will be released. > > Meanwhile, you can cherry pick the commits you want in your local git clone. > > Cheers, > Daniel > On 09.03.19 18:29, Anthony Joseph Messina wrote: > Daniel would it be possible to backport the rtpengine start/stop forwarding > and play/stop media features into 5.2.2? I realize they are not technically > "fixes"--not sure how obtrusive these changes would be. Either way, thank > you. -A signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Releasing Kamailio v5.2.2
Daniel would it be possible to backport the rtpengine start/stop forwarding and play/stop media features into 5.2.2? I realize they are not technically "fixes"--not sure how obtrusive these changes would be. Either way, thank you. -A -- Anthony - https://messinet.com F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Presence module with external MWI
On Monday, February 18, 2019 3:06:32 PM CST Trevor Peirce wrote:
> Hello,
>
> Looking for pointers as to what I'm missing here.
>
> I'm using the presence module to allow UAs to subscribe to
> message-summary events. I can see the entries appearing in the
> active_watchers table and I see subscription renewals increment the cseq
> columns so I'm satisfied this part is working well.
>
> I'm having trouble finding out how to tell Kamailio about a change to
> the message-summary so that it can notify the watchers.
>
> The pua module seems to provide a way but it doesn't seem to work with
> the subscriptions set up by the presence module. The presence module
> itself does not seem to offer any RPCs capable of doing this.
>
> Appreciate any pointers!
I use the following Python3 script with Asterisk 16 since it won't publish MWI
natively to Kamailio (yet)
### voicemail.conf
externnotify=/usr/bin/asterisk-kamailio-publish-mwi
### asterisk-kamailio-publish-mwi
#!/usr/bin/python3
# -*- coding: utf-8 -*-
import argparse
import requests
# http://kamailio.org/docs/modules/stable/modules/jsonrpcs
KAMAILIO_RPC_URL = 'http://:5060/RPC'
SIP_NEXTHOP = 'sip:127.0.0.1:5060'
SIP_DOMAIN = 'example.com'
class ExternNotifyHandler:
def __init__(self, context, exten, new, old, urgent):
"""
Parse context, extension, and new, old, and urgent message counts
"""
self.context = context
if context == 'default':
self.context = SIP_DOMAIN
self.exten = exten
self.recipient = ("sip:{}@{}").format(self.exten, self.context)
self.waiting = 'no'
if new > 0:
self.waiting = 'yes'
self.body = ("Messages-Waiting: {}\r\n"
"Message-Account: {}\r\n"
"Voice-Message: {:d}/{:d} ({:d}/0)\r\n").format(
self.waiting, self.recipient, new, old, urgent)
def kamailio_rpc_sip_publish(self):
"""
Generate a SIP PUBLISH MWI via Kamailio's jsonrpcs module
"""
headers = ("From: <{0}>\r\n"
"To: <{0}>\r\n"
"Max-Forwards: 1\r\n"
"Event: message-summary\r\n"
"Content-Type: application/simple-message-summary; "
"charset=utf-8\r\n").format(self.recipient)
content = {
'id': 1,
'jsonrpc': '2.0',
'method': 'tm.t_uac_start',
'params': [
'PUBLISH',
self.recipient,
SIP_NEXTHOP,
'.',
headers,
self.body
]
}
# http://docs.python-requests.org/en/latest/user/quickstart/
try:
r = requests.post(KAMAILIO_RPC_URL, allow_redirects=False,
json=content, timeout=5)
r.raise_for_status()
except requests.exceptions.ConnectionError as e:
print(e)
pass
except requests.exceptions.RequestException as e:
print(e)
pass
# Main processing
if __name__ == "__main__":
"""
Parse Asterisk VoiceMail externnotify positional command line arguments
context, extension, new voicemails, old voicemails, urgent voicemails
"""
parser = argparse.ArgumentParser()
parser.add_argument('context', help='Voicemail context')
parser.add_argument('exten', help='Voicemail extension')
parser.add_argument('new', type=int, help='New voicemail count')
parser.add_argument('old', type=int, help='Old voicemail count')
parser.add_argument('urgent', type=int, help='Urgent voicemail count')
args = parser.parse_args()
p = ExternNotifyHandler(args.context, args.exten,
args.new, args.old, args.urgent)
p.kamailio_rpc_sip_publish()
--
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Help me!
On Saturday, April 14, 2018 10:47:43 AM CDT Do Quang Trung wrote: > I use kamailio 5.1.1 with openssl-1.0.2n. I built openssl with gost engine > supported and the result when i list cipher list as follow: > > GOST2001-GOST89-GOST89:GOST94-GOST89-GOST89:ECDH-RSA-AES256-GCM-SHA384:ECDH- > ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH > -RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256 > -SHA::GOST94-GOST89-GOST89:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM- > SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:E > CDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA: > > i must use exactly GOST2001-GOST89-GOST89 in kamailio to protect sip > protocol. > > Please help me to resolve my problem. > > Best regards, > Trung. See http://kamailio.org/docs/modules/5.1.x/modules/tls#tls.p.cipher_list -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] phonenum module erratic behaviour with 5.1.2
George, I do see the same problem, though I haven't had time to investigate
yet. -A
On Monday, March 19, 2018 1:16:17 PM CDT George Diamantopoulos wrote:
> Hello all,
>
> It seems that the phonenum module in at least 5.1.2 (haven't tried previous
> versions) is behaving somewhat erratically. More specifically, if there are
> any references to any phn PVs with the key other than "number":
>
> if ( phonenum_match("1-484-555-", "src") ) {
> xlog("number norm: $phn(src=>number)\n");
> xlog("number country: $phn(src=>country)\n");
> dbg_pv_dump(30, "L_ERR");
> }
>
> kamailio will not start:
>
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]: 0(5044) DEBUG:
> [core/pvapi.c:494]: pv_spec_lookup(): PV <$phn(src=>country)> is not in
> cache
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]: 0(5044) DEBUG: phonenum
> [phonenum_pv.c:160]: pv_parse_phonenum_name(): phonenum [src] - key
> [country]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]: 0(5044) ERROR: phonenum
> [phonenum_pv.c:205]: pv_parse_phonenum_name(): error at PV phonenum name:
> src=>country
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]: 0(5044) ERROR:
> [core/pvapi.c:951]: pv_parse_spec2(): pvar "phn" has an invalid name param
> [src=>country]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]: 0(5044) ERROR:
> [core/pvapi.c:1106]: pv_parse_spec2(): wrong char [)/41] in
> [$phn(src=>country)] at [17 (5)]
> Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]: 0(5044) ERROR: xlog
> [xlog.c:513]: xdbg_fixup_helper(): wrong format[number country:
> $phn(src=>country)
>
> If I comment the offending line, all is well, but when dumping PVs with
> dbg_pv_dump(30, "L_ERR");, only $phn(src=>number) is listed, not the other
> keys (country, operator, region according to the docs)
>
> However, what is more disturbing is that phn(src=>number) always contains
> the string provided to phonenum_match() function, even if invalid
> characters are included, with no normalization. For example:
>
> phonenum_match("14~8%^88", "src")
>
> will result in dbg_pv_dump reporting:
>
> "$phn(src=>number)": "14~8%^88"
>
> Please note that I'm using sipwise's debian repository for stretch for
> kamailio, and debian's stable stretch repository for libphonenumnber
> (currently at 7.1.0-5+b1). I have also tried building current
> libphonenumber myself (version v8.9.2), but the result is the same.
>
> Is this a bug? Or am I missing something? Thanks!
>
> BR,
> George
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Partial/regex match on hash table key?
Ok, thank you Dmitri.
I'll need to use iteration then, which is ok too. I have a set of known
contacts in Horde Groupware (https://www.horde.org/) that I would like to set
the identity for when the callerid number matches. That way when someone
calls, instead of getting "WIRELESS CALLER" for the callerid, I would get
"John Q Public"
Since the DB query for every incoming call is rather costly, I wanted to use
something like http://acalustra.com/kamailio-from-tables-to-htables.html but
store the hashtable like:
key: 1234567
value: John Q Public
Though the $fU might be any of +1234567, 1234567, or 234567 (differing
prefixes)
I might play with something like:
sht_iterator_start("i1", "h1");
while(sht_iterator_next("i1")) {
if(h1[$shtitkey(i1)]=~$fU) {
xlog("CallerID is: $shtitval(i1)\n");
append_hf("P-Asserted-Identity: tel:$shtitval(i1)\r\n");
}
break;
}
sht_iterator_end("i1");
On Wednesday, January 31, 2018 4:52:02 PM CST Dmitri Savolainen wrote:
> Hi, Anthony
> Masks are not possible for getting values. But sometimes "array" approach
> may be usefull
>
> $var(i) = 0;
> $var(cache_mask) = "slice_a";
> $var(cache_size) = $sht(mycache=>$var(cache_mask)::size);
> while( $var(i) < $var(cache_size) ){
> # do smth with $sht(mycache=>$var(cache_mask)[$var(i)])
> $var(i) = $var(i) + 1;
> }
>
>
> 2018-01-31 21:36 GMT+03:00 Anthony Joseph Messina :
> Is is possible (without iterating through all entries in a hash table) to
> return the value based on a partial or regex match to the key?
>
> Something like...
> $var(one)=$sht(a=>*$var(two))
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Partial/regex match on hash table key?
Is is possible (without iterating through all entries in a hash table) to return the value based on a partial or regex match to the key? Something like... $var(one)=$sht(a=>*$var(two)) -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] is_audio_on_hold() doesn't support rfc3264
On Tuesday, October 24, 2017 8:52:28 AM CDT Julia Boudniatsky wrote: > FYI, > > After some tests found, that function "*is_audio_on_hold()*" (textops) > *supports > only rfc 254*3, > where "hold" is indicated by setting the "c" destination addresses for > the media streams to zero (0.0.0.0). > The newest *rfc3264*, where "hold" is indicated by a=sendonly/inactive, *is > not supported*. > Kamailio version 4.4.6. > > Best regards, > Julia You may want to add a feature request ticket at https://github.com/kamailio/kamailio/issues so it can be tracked. -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR dont_strip_or_prefix_flag
On Friday, August 25, 2017 2:33:30 AM CDT Juha Heinanen wrote: > Patrick Wakano writes: > > It doesn't matter if I set or reset the flag it never prefix the ReqUR if > > the declaration is present. I have to remove the declaration to make the > > module prefix it correctly. But then the whole purpose of the flag is > > lostAnyone aware of this behaviour? > > This should not be fixed in 5.0 and master. > > -- Juha Should *now* be fixed. Thanks Juha. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR dont_strip_or_prefix_flag
On Wednesday, August 23, 2017 6:14:04 PM CDT Patrick Wakano wrote:
> Hello list,
>
> I am using Kamailio 5.0.2 on centos7 and I am trying to use the
> dont_strip_or_prefix_flag (
> https://www.kamailio.org/docs/modules/5.0.x/modules/lcr.html#idp49131644)
> for LCR routing but I discovered that just by declaring the flag like this
> the module won't prefix my calls:
> #!define LCR_DONT_STRIP_OR_TAG 7
> modparam("lcr", "dont_strip_or_prefix_flag", LCR_DONT_STRIP_OR_TAG)
>
> It doesn't matter if I set or reset the flag it never prefix the ReqUR if
> the declaration is present. I have to remove the declaration to make the
> module prefix it correctly. But then the whole purpose of the flag is
> lostAnyone aware of this behaviour?
>
> Regards,
> Patrick Wakano
In my setup, I haven't needed this feature, so didn't notice it before, but
I've just tested and can confirm your result. -A
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Issue in Dialplan Module
You missed what Daniel said: IN a regexp ^ matches the beginning of the line/string, and $ matches the end. So "^000$" only matches exactly "000" and not "000" Remove the $ to match strings begining with 000. -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 On Friday, August 4, 2017 11:18:04 PM CDT Logeshwaran G wrote: > Yes I have Tried, please find below the Rules I have applied and the Result: > > Rules: > == > dpid: 1 > pr: 1 > match_op: 1 > match_exp: ^000$ > match_len: 0 > subst_exp: ^$ > repl_exp: > attrs: > > > I am Calling to the number 00091xx , But its saying as Too many > Hops. > > Its only looking for 000, Its not taking the 91xx numbers, If I > call 000 only its replacing with the given number in the Rule table. > > I need to Remove only the first 3 digits, and the other numbers should go > to the call. > > For Example If I am calling 00091x, It should remove the first 3 > digits 000 and 91x call should be place. > > Please Guide me for removing the first three digits alone and other numbers > should takes place. > > On Fri, Aug 4, 2017 at 6:43 PM, Joel Serrano wrote: > > Have you tried what Daniel suggested? > > > > Share the results of the tests and we can go from there. > > > > On Thu, Aug 3, 2017 at 21:34 Logeshwaran G > > > > wrote: > >> Input Please!! > >> > >> On Thu, Aug 3, 2017 at 5:08 PM, Logeshwaran G > >> > >> wrote: > >>> Thanks a lot! > >>> > >>> But for my scenario, > >>> > >>> If I am Dialling 0009199, need to remove the first three digits > >>> 000, so the call should go to 9199. > >>> > >>> I am stucked to create the rule for the above scenario, Kindly help me > >>> for the same. > >>> > >>> Kind Regards, > >>> Logeshwaran > >>> > >>> On Thu, Aug 3, 2017 at 4:48 PM, Daniel Tryba wrote: > On Thu, Aug 03, 2017 at 04:00:45PM +0530, Logeshwaran G wrote: > > ++--++--+---+---+--- > > +--+---+ > > > | id | dpid | pr | match_op | match_exp | match_len | subst_exp | > > repl_exp > > > | attrs | > > > > ++--++--+---+---+--- > > +--+---+ > > > | 1 |1 | 1 |1 | ^000$ | 0 | ^000$ | > > | > > | | 111 > > > > ++--++--+---+---+--- > > +--+---+ > > > The above rule replacing only the 000, If we Dial 000 its > > omitting, > > > While Dialing 000 its replacing that with 111. > > IN a regexp ^ matches the beginning of the line/string, and $ matches > the end. > > So "^000$" only matches exactly "000" and not "000" > Remove the $ to match strings begining with 000. signature.asc Description: This is a digitally signed message part. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] placing LCR Parameters in kamailio.cfg
You typically only need to include the modparam configuration entries that
either don't have a default value, or where you want to override the default.
-A
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
On Wednesday, July 26, 2017 6:21:29 AM CDT Logeshwaran G wrote:
> Hi All,
>
> I have created an lcr_gw, lcr_rule and lcr_rule_target tables according to
> my convenient .
>
> I have doubt on kamailio.cfg, whether I need to add the below params in cfg
> file??
>
> # - lcr params -
> #modparam("lcr","db_url","DBURL")
> #modparam("lcr", "lcr_gw_table","gw")
> #modparam("lcr", "id_column", "row_id")
> #modparam("lcr", "lcr_id_column", "lcr_identifier")
> #modparam("lcr", "gw_name_column", "name")
> #modparam("lcr", "ip_addr_column", "ip")
> #modparam("lcr", "hostname_column", "host")
> #modparam("lcr", "port_column", "port")
> #modparam("lcr", "params_column", "parameters")
> #modparam("lcr", "uri_scheme_column", "uri_scheme")
> #modparam("lcr", "transport_column", "trans")
> #modparam("lcr", "strip_column", "strip_count")
> #modparam("lcr", "prefix_column", "number_prefix")
> #modparam("lcr", "tag_column", "gw_tag")
> #modparam("lcr", "flags_column", "gw_flags")
> #modparam("lcr", "defunct_column", "defunct_until")
> #modparam("lcr", "lcr_rule_table", "rules")
> #modparam("lcr", "prefix_column", "number_prefix")
> #modparam("lcr", "from_uri_column", "caller_uri")
> #modparam("lcr", "request_uri_column", "callee_uri")
> #modparam("lcr", "stopper_column", "stop")
> #modparam("lcr", "enabled_column", "in_use")
> #modparam("lcr", "lcr_rule_target_table", "rules")
> #modparam("lcr", "rule_id_column", "rule")
> #modparam("lcr", "gw_id_column", "gw")
> #modparam("lcr", "priority_column", "priority")
> #modparam("lcr","weight_column", "target_weight")
> #modparam("lcr", "gw_uri_avp", "$avp(i:709)")
> #modparam("lcr", "ruri_user_avp", "$avp(i:500)")
>
> Please guide me.
>
> Thanks in Advance,
> Logeshwaran G
signature.asc
Description: This is a digitally signed message part.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
