### Description
When using the t_reuse_branch() function after a branch failure, Kamailio doesn't send out the call again if $du was filled and differed from $ru. Instead, Kamailio tries to send the call directly to $ru.
I would expect that the call gets sent out the same way as the original call.
### Troubleshooting
#### Reproduction
You need a setup like this:
UAC1 K(LB) <=> K(Proxy/Registrar) <=> K(LB) => UAC2
When a UAC registers, the Path module is used to save the LB (Loadbalancer) for outbound calls. When UAC1 calls UAC2, the original call gets sent through K(LB) to UAC2. However, if the first call gets rejected and the call gets retried through branch failure route, K(Proxy/Registrar) tries to send the call directly to the request URI.
In your branch_route add a reference to a branch failure route:
```t_on_branch_failure("samplename");```
Then add a branch failure route like this:
```event_route[tm:branch-failure:handle_tls_branch] {
if(t_check_status("488")) {
if (isbflagset(0) && !isbflagset(1)) {
t_reuse_branch();
setbflag(1);
t_relay();
}
}
}```
When filling $du manually before sending out the call again, everything works.
### Possible Solutions
The original destination URI should be copied to the reused branch.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 4.4.5 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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: unknown
compiled with gcc 4.7.2
```
But from what I see in source code, the devel version still copies the same value.
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
Debian Wheezy
```
--
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/1264
Regarding the issue 1274 (https://github.com/kamailio/kamailio/issues/1274) there's a problem in highly scalable environments to avoid conflicts in storing dialogs in the same DB.
As @miconda pointed out:
> The internal id is made from two integers, hash entry and hash id (h_entry, h_id). h_entry is the index of the slot in the hash table used to store the dialog structure, computed by hashing over call id. h_id is an incremented integer specific for each hash table slot.
>
> So, when loading a new record from database, if its h_id is not conflicting with an existing dialog on the same hash table slot, all is ok, otherwise the module is not going to work properly with two dialogs having same h_id.
>
> So, when loading a new record from database, if its h_id is not conflicting with an existing dialog on the same hash table slot, all is ok, otherwise the module is not going to work properly with two dialogs having same h_id.
>
> Among solutions I thought of:
>
> 1. have the servers generating non conflicting h_id, by having a start value different per server and an increment step larger than the number of servers. Iirc, here was at some point a similar attempt, but somehow didn't make it. Let's say one has two servers, first server starts allocating h_id from 1 and increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2 and increments with 2 (2, 4, 6, ...). Those values can be set via mod params, eventually with an option to rely on server_id.
> This should be the least intrusive in the other modules built on top of dialog. But it is rather rigid, with the example above, if one adds an extra server, it needs to reconfigure the old ones, so each server starts from either 1, 2 or 3 and increment by 3. Of course, one can set increment step to a larger value, like 100, and then has flexibility to deploy up to 1 hundred servers before having to reconfigure in case there is need for more server.
>
> 2. add server_id as the third field in the dialog id. It will require review of other modules using dialog and eventual code updates in those modules. One column to store the server_id needs to be added to dialog db tables.
>
> 3. switch from this conflicting id system to something like string unique ids, similar to what we have in usrloc records. This will require coding in other modules, changes to database schema, etc., so more work comparing with the above two, but could be the best in long term.
It would be great to have the option 3 developed if possible but we would also be satisfied with the option 2 to have a third field, server_id, in the dialog id.
Thank You!
--
Alex
--
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/1500
When K connects to another SIP proxy over TCP or TLS, the connection is shared for all requests to that destination. If the receiving SIP proxy is K, it means that only one worker process is handling all those requests. This may become a bottleneck if processing of requests is time consuming, e.g., because of DB operations.
It should therefore be possible one way or another to establish more than one parallel TCP or TLS connections to the same destination. One solution could be based on a function call, such as t_forward_connect(number), to be called before t_relay specifying the desired number of parallel connections shared randomly by outgoing requests.
--
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/1107
There are lots of module parameters that are not documented in the README file:
"amqp_timmer_process_interval"
"amqp_consumer_ack_timeout_micro"
"amqp_consumer_ack_timeout_sec"
"amqp_interprocess_timeout_micro"
"amqp_interprocess_timeout_sec"
"amqp_waitframe_timeout_micro"
"amqp_waitframe_timeout_sec"
"amqp_consumer_workers"
"amqp_query_timeout_micro"
"amqp_query_timeout_sec"
"pua_include_entity"
"json_escape_char"
"app_name"
"use_federated_exchange"
"federated_exchange"
"amqp_heartbeats"
"amqp_primary_zone"
"amqp_command_hashtable_size"
"amqp_result_avp"
"amqps_ca_cert"
"amqps_cert"
"amqps_key"
"amqps_verify_peer"
"amqps_verify_hostname"
Also, the follwing functions are not documented:
"kazoo_json_keys"
"kazoo_async_query"
--
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/976
Hello,
I'm testing kamailio with a SIP client with presence support, when I get a connection drop from a client (i.e when the client lost the access to the Internet connection) I do not receive the change in the status to offline immediately, I just received when the timeout from the presentity database finishes.
I know that I'm able to change the expiry parameter from the presentity table, but that increases my battery consumption and the data exchange, the same happens if I reduce the publish interval on the client side.
The connection with the server are connected with the TLS or TCP.
@miconda Suggested that a solution could be:
"For TCP/TLS, what can work, it's to use tcpops module which can execute an event route when a tcp/tls connection is dropped. If you track the association of connection id with the call-id of the presence publish, then you may be able to do some tricks and lower the expires of the published presence state. I haven't had the time to see what's possible there, but could worth investing.
An alternative would be to enhance presence module to behave as registrar/usrloc (which can delete contact records on connection drop) to expire documents when tcp/tls connection is closed (not sure if anyone already added it)."
--
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/915
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843477
> From: Ondřej Surý <ondrej(a)debian.org>
> To: Debian Bug Tracking System <submit(a)bugs.debian.org>
> Subject: src:kamailio: stop using libval-dev for DNSSEC validation
>
> Package: src:kamailio
> Version: 4.4.3-2
> Severity: serious
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Dear maintainer,
>
> please stop using libdnsval-dev for DNSSEC validation. src:dnsval
> is very poorly upstream maintained (SVN repository, issue tracker,
> mailing list are non-functional) and I am going to schedule it for
> removal for stretch.
>
> In a long term you should migrated to better and maintained library
> (preferrably getdns or just libunbound), but now please just drop
> it.
>
> Cheers,
> Ondrej
>
> - -- System Information:
> Debian Release: 8.6
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.2.0-41-generic (SMP w/24 CPU cores)
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -----BEGIN PGP SIGNATURE-----
So I'm going to remove **dnssec** module from the official Debian package
--
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/851
Hi,
When using dialog module and track_cseq_updates when needing to update CSeq for authenticated invites, if early media is present the CSeq in the Rack header is not also incremented.
Kamailio version:
version: kamailio 4.4.2 (x86_64/linux) 892ad6
flags: STATS: Off, 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: 892ad6
compiled on 11:18:36 Sep 28 2016 with gcc 5.4.0
--
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/801
Sipwise hat ON:
We have more than one server and we need to keep things in db in order to share sca subscription/appearance between servers
--
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/781
### Description
Newer rtpengine versions support manipulating SDP "a=" lines directly. Although kamailio is quite versatile when it comes to editing SIP message body, this functionality is often rather frail, especially when forking and having to use msg_apply_changes several times. I believe it would be beneficial to be able to offload such functionality to rtpengine, especially if one wants to apply different manipulations per outgoing branch.
### Expected behavior
There should be a way to issue rtpengine ng-control protocol commands compatible with the sdp-attr dictionary syntax.
#### Actual observed behavior
Currently sdp-attr tokens are not properly evaluated. For example, **doing**:
> rtpengine_manage("ICE=remove rtcp-mux-demux trust-address replace-origin replace-session-connection replace-SDP-version direction=internal direction=external sdp-attr-audio-substitute=$avp(fmtp_line) sdp-attr-audio-substitute=fmtp:101 0-15");
_[NOTE: $avp(fmtp_line) seems to expand in empty string here, which is a config error, but it doesn't affect the syntax demonstration in this example IMO]_
**results in**:
```
{
"supports": [ "load limit" ],
"sdp": "...",
"ICE": "remove",
"sdp-attr-audio-substitute": "",
"sdp-attr-audio-substitute": "fmtp:101",
"direction": [ "internal", "external" ],
"flags": [ "trust-address", "0-15" ],
"replace": [ "origin", "session-connection", "SDP-version" ],
"rtcp-mux": [ "demux" ],
"call-id": "...",
"received-from": [ "IP4", "..." ],
"from-tag": "...",
"to-tag": "...",
"command": "answer"
}
```
### Possible Solutions
Support the special syntax of sdp-attr as documented here: https://github.com/sipwise/rtpengine/blob/master/docs/ng_control_protocol.md
Here's one way to do it (I guess).
In order to get this:
```
"sdp-attr" :
{
"audio" :
{
"add" : [ "ptime:20", "sendrecv" ],
"substitute": [["fmtp:101 0-15" , "fmtp:126 0-16" ]]
},
"video":
{
"remove" : [ "rtpmap:101 telephone-event/8000" ]
},
"none" :
{
"substitute": [[ "sendrecv" , "sendonly" ], [ "ptime:20" , "ptime:40" ]]
}
}
```
Use a syntax similar to the following:
> rtpengine_manage("... sdp-attr-audio-add=ptime:20 sdp-attr-audio-add=sendrecv sdp-attr-audio-substitute=fmtp:101 0-15 sdp-attr-audio-substitute=fmtp:101 0-16 sdp-attr-video-remove=rtpmap:101 telephone-event/8000 sdp-attr-none-substitute=sendrecv sdp-attr-none-substitute=sendonly sdp-attr-none-substitute=ptime:20 sdp-attr-none-substitute=ptime:40 ...");
It's not very pretty, but it could work. Caveats:
* How to handle whitespace (e.g. there's a space in "fmtp:101 0-15" and in "rtpmap:101 telephone-event/8000" )
* substitute commands must always be in pairs, data type is a list of lists containing exactly two items as value in "substitute" key
Unfortunately my C skills are not up to this task, but if I can provide any other kind of help please let me know. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3509
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3509(a)github.com>