Module: kamailio
Branch: master
Commit: d07b6c0d70795317920a6a0544bd83aca1fd0da3
URL: https://github.com/kamailio/kamailio/commit/d07b6c0d70795317920a6a0544bd83a…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2020-10-06T12:01:18+02:00
modules: readme files regenerated - nathelper ... [skip ci]
---
Modified: src/modules/nathelper/README
---
Diff: https://github.com/kamailio/kamailio/commit/d07b6c0d70795317920a6a0544bd83a…
Patch: https://github.com/kamailio/kamailio/commit/d07b6c0d70795317920a6a0544bd83a…
---
diff --git a/src/modules/nathelper/README b/src/modules/nathelper/README
index 7398c702a5..79e43b73a7 100644
--- a/src/modules/nathelper/README
+++ b/src/modules/nathelper/README
@@ -525,16 +525,19 @@ if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();};
* flags - the value may be a bitwise OR of the following flags:
+ 0x01 - adds “a=direction:active” SDP line;
+ 0x02 - rewrite media IP address (c=) with source address of
- the message or the provided IP address (the provide IP address
- take precedence over the source address).
+ the message or the provided IP address. (a=rtpc) param will be
+ rewritten if exists. (the provided IP address take precedence
+ over the source address).
+ 0x04 - adds “a=nortpproxy:yes” SDP line;
+ 0x08 - rewrite IP from origin description (o=) with source
- address of the message or the provided IP address (the provide
- IP address take precedence over the source address).
+ address of the message or the provided IP address. (a=rtpc)
+ param will be rewritten if exists. (the provided IP address
+ take precedence over the source address).
* ip_address - IP to be used for rewriting SDP. If not specified, the
received signalling IP will be used. The parameter allows
pseudo-variables usage. NOTE: For the IP to be used, you need to
- use 0x02 or 0x08 flags, otherwise it will have no effect.
+ use 0x02 or 0x08 flags, otherwise it will have no effect. Must be
+ IPv4 address family.
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
FAILURE_ROUTE, BRANCH_ROUTE.
- GH #2459
#### Pre-Submission Checklist
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] 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
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [x] Related to issue #2459
#### Description
fix_nated_sdp() function with flags 0x02 and 0x08 and an IP address as argument (or without one) does modify the media line and the connection line. In addition it will modify IP address in "a=rtcp" parameter (rfc3605) in case if there is one. If a=rtcp param is not found the function doesn't return -1, but prints a DBG message and continues to execute (changing c= or o= lines)
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2497
-- Commit Summary --
* nathelper: fix_nated_sdp added support for a=rtcp param RFC3605
-- File Changes --
M src/modules/nathelper/nathelper.c (49)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2497.patchhttps://github.com/kamailio/kamailio/pull/2497.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/2497
Module: kamailio
Branch: master
Commit: 64579fee33d0a82a583b75184f78fcb7c9df2d82
URL: https://github.com/kamailio/kamailio/commit/64579fee33d0a82a583b75184f78fcb…
Author: Arsen Semenov <arsperger(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2020-10-06T11:51:24+02:00
nathelper: docs - updated notes for fix_nated_sdp. few typos fixed [skip ci]
---
Modified: src/modules/nathelper/doc/nathelper_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/64579fee33d0a82a583b75184f78fcb…
Patch: https://github.com/kamailio/kamailio/commit/64579fee33d0a82a583b75184f78fcb…
---
diff --git a/src/modules/nathelper/doc/nathelper_admin.xml b/src/modules/nathelper/doc/nathelper_admin.xml
index c73baf21a4..6bf4783337 100644
--- a/src/modules/nathelper/doc/nathelper_admin.xml
+++ b/src/modules/nathelper/doc/nathelper_admin.xml
@@ -562,7 +562,7 @@ if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();};
<listitem>
<para><emphasis>0x02</emphasis> - rewrite media
&ip; address (c=) with source address of the message
- or the provided IP address (the provide IP address take
+ or the provided IP address. (a=rtpc) param will be rewritten if exists. (the provided IP address take
precedence over the source address).</para>
</listitem>
<listitem>
@@ -572,7 +572,7 @@ if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();};
<listitem>
<para><emphasis>0x08</emphasis> - rewrite IP from
origin description (o=) with source address of the message
- or the provided IP address (the provide IP address take
+ or the provided IP address. (a=rtpc) param will be rewritten if exists. (the provided IP address take
precedence over the source address).</para>
</listitem>
</itemizedlist>
@@ -582,7 +582,7 @@ if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();};
If not specified, the received signalling IP will be used. The
parameter allows pseudo-variables usage. NOTE: For the IP to be
used, you need to use 0x02 or 0x08 flags, otherwise it will have
- no effect.
+ no effect. Must be IPv4 address family.
</para>
</listitem>
</itemizedlist>
Hello,
one question about a planned extension in the DMQ module. Right now the module supports only one server in the notification_address parameter. It is possible to set multi_notify to 1, and then the module will resolve the one sip URI over DNS to multiple servers, thought.
There is interest in extending the module to support multiple notification_address servers natively without using DNS. I see two options right now:
1. Separate the multiple servers, with ";", e.g. modparam("dmq", "notification_address", "sip:server1;sip:server2"). If only one server in the param, use the existing logic.
2. Use multiple notification_servers parameter calls, e.g. modparam("dmq", "notification_address") - modparam("dmq", "notification_address", "sip:server2<sip:server1;sip:server2>"). If only one param statement, use the existing logic.
As the module already has support to use a notification server list internally, the change should be small in both cases.
I think option 1) is the better way, as its already done in other modules like this to support multiple server scenarios.
Any comments or objections about this extension?
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Hi gang,
As of today, rtpengine adds support for HTTP and WebSocket interfaces
(as well as HTTPS and WSS). Currently supported operations are accessing
the CLI commands provided by the `rtpengine-ctl` CLI tool, and accessing
the "NG" control protocol. These are both 1-to-1 mappings on top of the
existing interfaces, just with a different transport protocol on top,
which doesn't make for a pretty RESTful interface, but should otherwise
be perfectly usable. It can also be further extended if necessary, with
some additional operations already planned. There's a bit more detail at
https://github.com/sipwise/rtpengine#httpwebsocket-support
The "NG" protocol support in particular should be interesting to those
who keep having problems with the UDP transport of the existing
protocol, due to packet loss or MTU issues or otherwise. This makes it
possible to switch the transport protocol to HTTP or WS while retaining
full compatibility with the existing control protocol. This isn't
currently implemented in the Kamailio module for rtpengine, but if
someone feels like giving it a shot, then by all means feel free. It may
also be of interest to those who want to control rtpengine from JS etc
for example.
Cheers
Richard
K master has recently crashed several times on Debian 10. Could this have
something to do with openssl libs?
-- Juha
Oct 5 08:32:21 lohi systemd[1]: Stopping LSB: Start/stop OpenSIPg SIP Proxy...
Oct 5 08:32:21 lohi sip-proxy[19922]: Stopping sip-proxy
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30820]: NOTICE: <core> [main.c:735]: handle_sigs(): Thank you for flying sip-proxy!!!
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30860]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30859]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30858]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30857]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30853]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30856]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30850]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30854]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30834]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30847]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30852]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30849]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30851]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30841]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30830]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30848]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30846]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30836]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30827]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30844]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30845]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30833]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30842]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30839]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30829]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30822]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30840]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30838]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30826]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30837]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30824]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30835]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30823]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30832]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30831]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30828]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30843]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30825]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30821]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30855]: INFO: <core> [main.c:857]: sig_usr(): signal 15 received
Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30820]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Oct 5 08:32:21 lohi kernel: [176646.851504] sip-proxy[30820]: segfault at 7f84196c7730 ip 00007f8421adce26 sp 00007ffde899c0f0 error 4 in libcrypto.so.1.1[7f84219d8000+19e000]
Oct 5 08:32:21 lohi kernel: [176646.851513] Code: 1f 44 00 00 c7 05 9a d9 15 00 01 00 00 00 c7 05 8c d9 15 00 01 00 00 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 85 ff 74 5b 53 <8b> 0f 48 89 fb 85 c9 75 29 8b 53 04 85 d2 75 2e 8b 43 08 85 c0 75
(gdb) where
#0 0x00007f8421adce26 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#1 0x00007f8421add12f in OPENSSL_cleanup () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
#2 0x00007f8423a87d8c in __run_exit_handlers (status=0, listp=0x7f8423c09718 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#3 0x00007f8423a87eba in __GI_exit (status=<optimized out>) at exit.c:139
#4 0x000055d40be7bb61 in handle_sigs () at main.c:738
#5 0x000055d40be88966 in main_loop () at main.c:1817
#6 0x000055d40be91e32 in main (argc=17, argv=0x7ffde899c948) at main.c:2861