sr-dev May 2016

sr-dev@lists.kamailio.org

28 participants
348 discussions

[kamailio/kamailio] Wishlist #234: URI transformation to pick up URI scheme (#592)

by Olle E. Johansson

I would like the URI transformations to be more generic so one can pick up the URI scheme, like HTTP: or TEL: Just an idea --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/592

7 years, 4 months

[kamailio] PID file permissions (#231)

by Arsen

ENV: Debian 8 So on most Linux systems the /var/run folder is a tmpfs and after which clears after each reboot As I try to start up kamailio after a reboot through kamctl I get the following error. "ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed" Because kamailio does not have the permission to write to the /var/run folder as the kamailio user. Would it be possible to add in the "kamctl" code a section where the SPECIFIED PID LOCATION (/var/run/kamailio) is checked and if it does not exist create it as the root user and chown it to the SPECIFIED USER (kamailio)? The way I have patched it for now is to create a init script that creates a /var/run/kamailio folder and chmods it to kamailio:kamailio Thanks everyone! --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/231

7 years, 4 months

[kamailio] consistency on name of main c file for a module (#82)

by Victor Seva

main file should be modulename.c or modulename_mod.c --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/82

7 years, 10 months

[kamailio] permissions: RPC AddressDump doesn't include mask size (#250)

by Olle E. Johansson

The new RPC command doesn't output the mask, only the IP. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/250

7 years, 11 months

Outbound flow failure handling merged to master

by Hugh Waite

Hello, As you will see I have merged my branch back into master. These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry. The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } } Any bugs, memory leaks etc. let me know! Hugh -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd.

8 years

[kamailio] pua: E_Tag miss match due to race between consecutive PUBLISH requests (#21)

by Ovidiu Sas

If a PUBLISH request is sent before a 200 OK for the previous PUBLISH request is received, the E-Tag is reset which leads to inconsistent presentity data in the presence server. This is happening because the second PUBLISH is sent with the same E-Tag as the previous one, but the presence server has an updated the E-Tag (generated while handling the first PUBLISH). The pua module should implement a queuing mechanism for subsequent PUBLISH request while a previous PUBLISH transaction is in progress. No new PUBLISH requests should be sent before a response to the previous PUBLISH request was received and the E-Tag updated. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/21

8 years, 2 months

[kamailio] Presence module should support a 32bit unsigned expire value (#521)

by foucse

Hello, ``` kamailio -v version: kamailio 4.4.0-pre0 (i386/linux) f39d14-dirty flags: STATS: Off, EXTRA_DEBUG, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: f39d14 -dirty compiled on 17:01:22 Feb 12 2016 with gcc 4.9.3 ``` If I read well the RFC 3261 section 20.19 [https://tools.ietf.org/html/rfc3261#section-20.19] a SUBSCRIBE or a PUBLISH may have an Expires value of 2**32-1 = (4294967295). But it appears to me that this value is not supported in Kamailio even if I allow it as a max_expires option in configuration (modparam("presence", "max_expires", 4294967295)). Kamailio answers with the following: ``` 2016/02/29 09:02:59.343750 192.168.100.1:5060 -> 192.168.2.2:5062 SIP/2.0 423 Interval Too Brief via: SIP/2.0/UDP 192.168.2.2:5062;branch=z9hG4bK-11535-1-9;rport=5062 From: "User1" <sip:user1@example.com>;tag=11535-1 To: "User1" <sip:user1@example.com>;tag=dfba6eee28f067076993264b7e466d4e.151a Call-ID: 1-11545(a)192.168.1.1-user1 CSeq: 3 PUBLISH Expires: -2147483648 SIP-ETag: a.1456732971.11285.1.0 Server: kamailio (4.4.0-pre0 (i386/linux)) Content-Length: 0 ``` Which is not compliant with the RFC, the Expires value should not be signed. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/521

8 years, 2 months

[kamailio/kamailio] sca module (#580)

by Olle E. Johansson

The README needs to be up to date with the source code. I noted that the "Outbound proxy" modparam is not documented. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/580

8 years, 2 months

[kamailio/kamailio] dispatcher: use avl-tree for ds_set indexing (#578)

by Alekzander Spiridonov

1. Get set by id uses loop instead of recursion 2. All other routines that used to iterate over the list are re-factored to trace the tree recursively. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/578 -- Commit Summary -- * dispatcher: use avl-tree for ds_set indexing -- File Changes -- M modules/dispatcher/dispatch.c (873) M modules/dispatcher/dispatch.h (13) M modules/dispatcher/dispatcher.c (215) -- Patch Links -- https://github.com/kamailio/kamailio/pull/578.patch https://github.com/kamailio/kamailio/pull/578.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/578

8 years, 3 months

[kamailio/kamailio] siptrace: HEPv2 destination port is sent as the wrong port (#581)

by Erik Davidson

I've been trying to track this issue down myself for the last two days but it appears the value is coming from somewhere in the tm module or somewhere else lower than that, which I haven't worked with at all. I have siptrace turned on and I'm using the destination port from the HEPv2 header but it seems to always come to me as 5060 even if the packet is actually sent to a different port (such as 51000). I'm able to reproduce this with my Polycom phone by having two registrations (one UDP and one TCP) going through a Kamailio server from the same phone. It looks like the first request comes from 5060 and is responded to on 5060, but the second connection comes from a random port on the phone (let's say 35000). When the reply (such as a 200) comes back from the server sitting behind the Kamailio proxy, the siptrace HEP header says the packet is going back to 5060 when it's actually being sent to 35000. I'm not even sure where the 5060 value is coming from in the first place . I've tracked the '5060' value to `t.uas.response.dst.to.sin.sin_port` in `t_reply.c:reply_received()` but the value of `t` is retrieved from `get_t()` and I'm not sure where that's added to the hash table in the first place. I can see the actual value of the destination port with `t.uas.request.rcv.src_port` within that same `t_reply.c:reply_received()` but I can't figure out how to get that value into the destination port at the source. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/581

8 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2016