Module: kamailio
Branch: master
Commit: 94a51c887efaac2f85932922baf8e261abb8247c
URL: https://github.com/kamailio/kamailio/commit/94a51c887efaac2f85932922baf8e26…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2019-05-13T09:29:55+02:00
core: main.c - show examples for use of -A for defines with values
---
Modified: src/main.c
---
Diff: https://github.com/kamailio/kamailio/commit/94a51c887efaac2f85932922baf8e26…
Patch: https://github.com/kamailio/kamailio/commit/94a51c887efaac2f85932922baf8e26…
---
diff --git a/src/main.c b/src/main.c
index 6d6d390306..a97fb6dba0 100644
--- a/src/main.c
+++ b/src/main.c
@@ -157,7 +157,8 @@ Options:\n\
disable with no or off\n\
--alias=val Add an alias, the value has to be '[proto:]hostname[:port]'\n\
(like for 'alias' global parameter)\n\
- -A define Add config pre-processor define (e.g., -A WITH_AUTH)\n\
+ -A define Add config pre-processor define (e.g., -A WITH_AUTH,\n\
+ -A 'FLT_ACC=1', -A 'DEFVAL=\"str-val\"')\n\
-b nr Maximum receive buffer size which will not be exceeded by\n\
auto-probing procedure even if OS allows\n\
-c Check configuration file for syntax errors\n\
### Description
Hello,
Kamailio -master version couldnt relay tcp request to other sides. it gives EAGAIN error. When i test scenario on kamailio-5.2 version , it can relay.
### Troubleshooting
#### Reproduction
```
route[TCPTEST]{
remove_hf("Route");
#loose_route();
if (!is_method("INVITE")) return;
$du="sip: mykamailio1.test:5060;transport=tcp";
if(!t_newtran()){
xlog("L_WARN"," Couldnt create new transaction \r\n");
sl_send_reply("503", "Service not available");
exit;
}
if(!t_relay()){
send_reply("503", "Service not available");
exit;
}
exit;
}
```
#### Debugging Data
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
7(15781) DEBUG: <core> [core/tcp_main.c:1229]: tcpconn_new(): on port 5060, type 2
7(15781) DEBUG: <core> [core/tcp_main.c:1539]: tcpconn_add(): hashes: 507:2382:0, 2
7(15781) DEBUG: <core> [core/tcp_main.c:2873]: tcpconn_1st_send(): pending write on new connection 0x7fd15b5e7c98 (-1/1483 bytes written) (err: 11 - Resource temporarily unavailable)
7(15781) ERROR: <core> [core/tcp_main.c:2891]: tcpconn_1st_send(): [FD61:C23C:B3B6:0:0:0:0:5]:5060: EAGAIN and write queue full or failed for 0x7fd15b5e7c98
7(15781) DEBUG: <core> [core/tcp_main.c:3153]: tcpconn_chld_put(): destroying connection 0x7fd15b5e7c98 (2, -1) flags 0060
7(15781) ERROR: tm [../../core/forward.h:251]: msg_send_buffer(): tcp_send failed
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
UAC: IPv6: TCP ---> Kamailio (5.2) :IPv6 :TCP ---> Client or Server IPv6:TCP
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
```
Kamailio master from git
```
* **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`)
-->
```
NAME="CentOS Linux"
VERSION="7 (Core)"
3.10.0-957.1.3.el7.x86_64
```
--
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/1836
Hello Ivan,
this type of questions are better suited to our developer list, not the users list - adding it to CC.
I haven't looked yet that deep into your previous e-mail, but have you already looked e.g. to the dialog module? This does something similar, e.g. bridging an existing dialog. It uses uac_req_t and a TM callback. You find the implementation in dlg_transfer.c, e.g. function dlg_bridge(str *from, str *to, str *op, str *bd).
Cheers,
Henning
Am 08.05.19 um 09:26 schrieb Ivan Ribakov:
Anyone with module dev experience here who had to do something similar or used tm_load.h interface for other purposes?
On 7 May 2019, at 16:39, Ivan Ribakov <i.ribakov(a)zaleos.net<mailto:i.ribakov@zaleos.net>> wrote:
I’m working on a custom Kamailio module where I need to send new-dialog and in-dialog requests on timer (hence I’m being forced to generate new messages from C code).
So far I’ve been using modules/tm/tm_load.h defined interface to generate messages and handle callbacks. New dialog messages are sent and processed normally. To do that I’m:
1. Calling set_uac_request() to define request parameters
2. Calling tmb.t_request_outside() to send it outside any existing dialog
I was able to send in-dialog requests (or so I thought) in a similar fashion, but I soon realised that responses to those requests were dropped because they couldn’t be matched against any known existing transaction. I’m attaching log messages that I believe support this theory and I’ve also observed UDP retransmissions.
tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 50576 label 0 branch 0
tm [t_lookup.c:990]: t_reply_matching(): no matching transaction exists
tm [t_lookup.c:993]: t_reply_matching(): failure to match a transaction
tm [t_lookup.c:1088]: t_check_msg(): msg (0x5abcb50) id=1 global id=1 T end=(nil)
tm [t_reply.c:2195]: reply_received(): transaction not found - (branch -1)
The way I’m currently generating in-dialog requests is very similar to what tmb.t_request_outside() does, the main difference being that I do the dialog setup manually, based on the call-ID, cseq and from/to tags (I’m tracking transaction identifiers separately) and then pass resulting uac_req_t to tmb.t_request_within() - https://gist.github.com/IvanRibakov/3302cb286b1f4b786d109b406f2435a2
Now, the question part - does anyone know what I’m doing wrong/missing? As I mentioned, when looking at the generated message bodies, they look ok to me (left - initial request that started the dialog, right - first in-dialog request), so I’m guessing I’m missing some Kamailio internal steps needed to register new transaction.
<kamailio_indialog_req.png>
SIP flow (up to the point when first UDP retransmission happens)
<PastedGraphic-1.png>
I apologise in advance for the bulky question and will be extremely thankful for any guidance.
Regards,
Ivan
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Hello Juha,
many developers are right now at Kamailio World. The developer here is in Berlin as well. He already acknowledged the bug on the tracker.
In the end this is the git master development and should be not used in production.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
-----Ursprüngliche Nachricht-----
Von: sr-dev <sr-dev-bounces(a)lists.kamailio.org> Im Auftrag von Juha Heinanen
Gesendet: Dienstag, 7. Mai 2019 16:26
An: sr-dev(a)lists.kamailio.org
Betreff: [sr-dev] still no fix to siptrace
siptrace module is still broken. would it be high time to revert back to 5.2 level and then make a new commit when the problem is fixed and fix properly tested?
-- Juha
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev