### Description
I use TCP transport to relay SIP messages.
When Kamailio cannot connect to another server then Kamailio generates response `408 Request Timeout`.
inside `event_route[dialog:failed]` route block I check error code `$rs` but this value is `null`.
This happens because Kamailio does not able to relay SIP messages and is not able to receive responses.
But `tm` module generates a response `408 Request Timeout` and will be fine to init `$rs` pseudo-variable using tm module response.
### Expected behavior
`$rs` pseudo-variable contains `tm` module response when kamailio does not receive a response from another server.
#### Actual observed behavior
`$rs` pseudo-variable contains `null` value when kamailio does not receive a response from another server.
To check you can use
```
event_route[dialog:failed]
{
$var(code_xxx) = $(rs{re.subst,/([0-9])[0-9]{2}/\1xx/});
xlog("L_INFO", "websocket|log|dialog failed $rs; $var(code_xxx)\n");
}
```
And relay SIP message to host that reachable.
--
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/2867
### Description
Larger SIP frames get dropped when sent over UDP and IPv6. The sending side has MTU 1500 and the receiving side has MTU 1492. This is an IPv6-only setup, so this is problematic. Also, pulling down the MTU of a general server for a tunneled peer would smear like an oil stain. The suggestion to fallback on TCP feels like a hack.
### Troubleshooting
#### Reproduction
Send a SIP message to a network interface with a lower MTU than the submitted frame size.
#### Debugging Data
None, transmission works fine.
#### Log Messages
None, transmission works fine.
#### SIP Traffic
Irrelevant.
#### Code Investigation
I explored the Kamailio source code for MTU handling.
https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a…
* This defaults to switching off the Don't Fragment bit on IPv4 frames, to allow them to be broken up downstream.
* This should check for an IPv4 socket, because (at least) Linux has a separate symbolic value `IPV6_MTU_DISCOVER`
* Note that IPv6 is never broken up by routers; they always return ICMPv6 message Packet Too Big
* Note that IPv6 Path MTU discovery by the kernel is automatic only for connected UDP sockets
* Since Kamailio uses unconnected UDP sockets, Path MTU issues cause packets to be dropped
* Note that such packet drops depend on a somewhat dynamic SIP message size, causing random behaviour
* I therefore suggest that Kamailio is lacking in some of its IPv6 logic
https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a…
* This enables the reporting of ICMP errors, including Path MTU but also other useful things like Host Not Found
* This should check for an IPv4 socket, because (at least) Linux has a separate symbolic value `IPV6_RECVERR`
* Note that the same behaviour is available on BSD, so it need not be specific to Linux
* Note that handling errors is done with `recvmsg()` with a flag `MSG_ERRQUEUE`, which is not used in Kamailio
* Note that the ancillary data from `recvmsg()` holds data to cleverly handle ICMP or ICMPv6 responses
* I therefore suggest that Kamailio is lacking a fair chunk of its ICMP and ICMPv6 logic
* I expect that this may bring efficiency gains due to faster closing of transactions
### Possible Solutions
I have been thinking about ways to lower MTU values only for some peers.
1. Using connected sockets might work, possibly as an alternative when Path MTU problems arise. It might not scale however.
2. Every socket could have an extra sending socket set to a lower MTU. The use of `SO_REUSEADDR` seems to allow for that.
3. Before falling back on an extra socket, the desired MTU could be set. Alternatively, as for IPv6, an MTU of 1280 might be considered in many cases:
- *If you can carry 6 out of 8 coffee mugs from the kitchen, you need to walk twice, and 4+4 is easier than 6+2*
- Anything over the MTU splits into at least 2 frames
- The headers added are 40 bytes IPv6 header and 8 bytes Fragment Extension Header
- 2 frames can hold a single frame of 2*1280-40-8 = 2512 bytes
- Up to 2512 bytes original MTU, breakup in 1280 byte frames will be fine
- 3 frames are going to be useful for larger frames, then a similar style can be used
- This might help to decide whether 1280 or a higher MTU is most desirable
### Additional Information
```
Kamailio 5.2.1 from Debian stable
```
* **Operating System**:
```
Linux Debian stable on kernel 4.19.0
```
(I don't suppose it matters, this code has been around for ages. I used permalinks for stable reference).
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3119
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3119(a)github.com>
### Description
I use TCP sockets to relay calls to backend servers.
Also, I have enabled `tcp_reuse_port` and enabled `socket` attribute in dispatcher settings.
INVITE messages to backend servers are now properly send from port 5060.
### Expected behavior
For all messages are used the same TCP socket and same source port for all messages (including OPTIONS).
#### Actual observed behavior
But initial OPTIONS (before the first call send) uses a random source port.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
used current c503d2bd31a580138a67f1d4a265ccde5791d271 with small customization.
* **Operating System**:
aarch64
```
[root@sbc-a0 ~]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
```
--
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/2853
set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules, libs, utils, ...)
- [ ] Each component has a single commit (if not, squash them into one commit)
- [ ] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [x] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
Using kamailio 5.4 version, we have seen that dlg_isflagset is not detecting a dialog flag set in the request route for the initial INVITE, when a CANCEL request arrives.
We have applied this change to set the dialog context unique ide for this request. Since it's done on dlg_onreply, dlg_onroute and dlg_ontimeout functions. This way, dlg_get_by_iuid(&dctx->iuid) in the function ki_dlg_isflagset is not NULL and dialog flags are detected.
Is this change correct? Or can it generate any kind of issues?
thanks a lot and regards
David
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3096
-- Commit Summary --
* dialog: set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call
-- File Changes --
M src/modules/dialog/dlg_handlers.c (3)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3096.patchhttps://github.com/kamailio/kamailio/pull/3096.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3096
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3096(a)github.com>
Module: kamailio
Branch: master
Commit: 654f22a03e874f86c4b2b2d29eb969a1be3bb25e
URL: https://github.com/kamailio/kamailio/commit/654f22a03e874f86c4b2b2d29eb969a…
Author: David Escartin <descartin(a)sonoc.io>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2022-08-26T09:49:42+02:00
dialog: set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call
---
Modified: src/modules/dialog/dlg_handlers.c
---
Diff: https://github.com/kamailio/kamailio/commit/654f22a03e874f86c4b2b2d29eb969a…
Patch: https://github.com/kamailio/kamailio/commit/654f22a03e874f86c4b2b2d29eb969a…
---
diff --git a/src/modules/dialog/dlg_handlers.c b/src/modules/dialog/dlg_handlers.c
index 39f1f83dd7..794aa7c7d2 100644
--- a/src/modules/dialog/dlg_handlers.c
+++ b/src/modules/dialog/dlg_handlers.c
@@ -1258,6 +1258,9 @@ dlg_cell_t *dlg_lookup_msg_dialog(sip_msg_t *msg, unsigned int *dir)
msg->callid->body.len, msg->callid->body.s);
return NULL;
}
+ if(msg->first_line.u.request.method_value == METHOD_CANCEL) {
+ dlg_set_ctx_iuid(dlg);
+ }
if(dir) *dir = vdir;
return dlg;
}