Module: kamailio
Branch: master
Commit: ff004839679deb2095443c9bcb09a2795254e724
URL: https://github.com/kamailio/kamailio/commit/ff004839679deb2095443c9bcb09a27…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2016-11-21T16:01:17+01:00
modules: readme files regenerated - rtpengine ...
---
Modified: modules/rtpengine/README
---
Diff: https://github.com/kamailio/kamailio/commit/ff004839679deb2095443c9bcb09a27…
Patch: https://github.com/kamailio/kamailio/commit/ff004839679deb2095443c9bcb09a27…
---
diff --git a/modules/rtpengine/README b/modules/rtpengine/README
index cbdae9c..227db95 100644
--- a/modules/rtpengine/README
+++ b/modules/rtpengine/README
@@ -729,6 +729,10 @@ rtpengine_offer();
+ asymmetric - flags that UA from which message is received
doesn't support symmetric RTP. Disables learning of endpoint
addresses in the Sipwise rtpengine proxy.
+ + no-redis-update - this flag can be used by Kamailio in order
+ to tell rtpengine not to persist the call into Redis upon
+ receiving offer/answer() control commands. If flag is not set,
+ default action is rtpengine persists call to redis.
+ force-answer - force “answer”, that is, only rewrite SDP when
corresponding session already exists in the RTP proxy. By
default is on when the session is to be completed.
Module: kamailio
Branch: master
Commit: fcccbf7a44ddecdc155b8f951b0696ec8f257e10
URL: https://github.com/kamailio/kamailio/commit/fcccbf7a44ddecdc155b8f951b0696e…
Author: Lucian Balaceanu <lucian.balaceanu(a)1and1.ro>
Committer: Lucian Balaceanu <lucian.balaceanu(a)1and1.ro>
Date: 2016-11-21T16:51:40+02:00
rtpengine: added note about no-redis-update flag
Flag can be used by Kamailio in order to tell rtpengine not to
persist the call into Redis upon receiving offer/answer() commands.
---
Modified: modules/rtpengine/doc/rtpengine_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/fcccbf7a44ddecdc155b8f951b0696e…
Patch: https://github.com/kamailio/kamailio/commit/fcccbf7a44ddecdc155b8f951b0696e…
---
diff --git a/modules/rtpengine/doc/rtpengine_admin.xml b/modules/rtpengine/doc/rtpengine_admin.xml
index f0d0ade..726c81b 100644
--- a/modules/rtpengine/doc/rtpengine_admin.xml
+++ b/modules/rtpengine/doc/rtpengine_admin.xml
@@ -745,6 +745,12 @@ rtpengine_offer();
in the Sipwise rtpengine proxy.
</para></listitem>
<listitem><para>
+ <emphasis>no-redis-update</emphasis> - this flag can be used by Kamailio in order
+ to tell rtpengine not to persist the call into Redis upon receiving offer/answer()
+ control commands. If flag is not set, default action is rtpengine persists call
+ to redis.
+ </para></listitem>
+ <listitem><para>
<emphasis>force-answer</emphasis> - force <quote>answer</quote>, that is,
only rewrite &sdp; when corresponding session already exists
in the &rtp; proxy. By default is on when the session is to be
Hello,
following the last IRC devel meeting, I am writing the summary of the
main points being discussed there and what's planned to get to Kamailio
v5.0.
1) Freezing should be done either before Chrismas holidays or at
beginning of January 2017 to aim meeting the deadline for next Debian
stable distro
2) Restructuring the source tree
To be done in the weeks before freezing, so eventual fixes won't have
hard time to be backported to 4.4.
This means it will be done in December. Open issues:
a) anyone aware of a tool that can update include directives upon
relocation of the file?
b) who is interested to join an eventual online session to perform the
restructuring? C coding is not a must here, but more knowledge of
sed/awk/perl/python/... and Makefiles ...
3) Defining a template for generating main file of a module
The scope is to have a descriptive file for the module where one lists
exported symbols (config params, functions, kemi functions, rpc/mi
commands, etc.) which along with a template will generate the c code.
The effective implementation of the functions/commands will be done
separately, in a different file (e.g, the main file that is generated
can have references to parameter variables with extern ... and will also
generate the .h which will have only the prototypes for the functions).
The main goal here is to get a way of easily generated an index of
exported symbols that can be used to discover missing documentation.
Right now we sort of do 'gentlemen agreement' on documenting functions
and parameters, but many rpc commands are not documented (they are
extracted with some tool scanning compiled objects).
Also, same concept as with c code can be used to generate some stubs for
documentation that can be included in docbook xml files.
Few proposals of templating engines were mentioned, coming in my mind
now being jinja2 and mustache. Anyone else with more suggestions?
Or even propose alternatives of what can be used to solve this relation
between code and docs?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
```
Jun 6 14:38:43 spce lb[27903]: : tls [tls_init.c:557]: init_tls_h(): ERROR: tls: init_tls_h: installed openssl library version is too different from the library the Kamailio tls module was compiled with: installed "OpenSSL 1.0.1t 3 May 2016" (0x1000114f), compiled "OpenSSL 1.0.1k 8 Jan 2015" (0x100010bf).#012 Please make sure a compatible version is used (tls_force_run in kamailio.cfg will override this check)
Jun 6 14:38:43 spce lb[27903]: CRITICAL: <core> [main.c:2577]: main(): could not initialize tls, exiting...
```
openssl was upgraded from 1.0.1k-3+deb8u5 to 1.0.1t-1+deb8u2
This seems not to work properly
https://github.com/kamailio/kamailio/blob/master/modules/tls/tls_init.c#L54…
```
#if OPENSSL_VERSION_NUMBER < 0x00907000L
WARN("You are using an old version of OpenSSL (< 0.9.7). Upgrade!\n");
#endif
ssl_version=SSLeay();
/* check if version have the same major minor and fix level
* (e.g. 0.9.8a & 0.9.8c are ok, but 0.9.8 and 0.9.9x are not) */
if ((ssl_version>>8)!=(OPENSSL_VERSION_NUMBER>>8)){
LOG(L_CRIT, "ERROR: tls: init_tls_h: installed openssl library "
"version is too different from the library the Kamailio tls module "
"was compiled with: installed \"%s\" (0x%08lx), compiled "
"\"%s\" (0x%08lx).\n"
" Please make sure a compatible version is used"
" (tls_force_run in kamailio.cfg will override this check)\n",
SSLeay_version(SSLEAY_VERSION), ssl_version,
OPENSSL_VERSION_TEXT, (long)OPENSSL_VERSION_NUMBER);
if (cfg_get(tls, tls_cfg, force_run))
LOG(L_WARN, "tls: init_tls_h: tls_force_run turned on, ignoring "
" openssl version mismatch\n");
else
return -1; /* safer to exit */
}
```
---
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/662
Module: kamailio
Branch: master
Commit: 650087d6e352ab5e299c3dabe8ab2ea307840a83
URL: https://github.com/kamailio/kamailio/commit/650087d6e352ab5e299c3dabe8ab2ea…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2016-11-21T12:31:38+01:00
modules: readme files regenerated - rtpengine ...
---
Modified: modules/rtpengine/README
Modified: modules/rtpproxy/README
---
Diff: https://github.com/kamailio/kamailio/commit/650087d6e352ab5e299c3dabe8ab2ea…
Patch: https://github.com/kamailio/kamailio/commit/650087d6e352ab5e299c3dabe8ab2ea…
---
diff --git a/modules/rtpengine/README b/modules/rtpengine/README
index fcea3ca..cbdae9c 100644
--- a/modules/rtpengine/README
+++ b/modules/rtpengine/README
@@ -974,8 +974,12 @@ rtpengine_delete();
with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
rtpengine_answer()
* If ACK with SDP, then do rtpengine_answer()
- * If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do
- rtpengine_delete()
+ * If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call
+ rtpengine_delete(). Be careful with calling this function after
+ resuming a suspended transaction (e.g., after t_continue()),
+ because the context of executed route is FAILURE ROUTE (in other
+ words, rtpengine_manage() in the route block of t_continue() does
+ the same as in failure_route).
* If reply to INVITE with code >= 300 do rtpengine_delete()
* If reply with SDP to INVITE having code 1xx and 2xx, then do
rtpengine_answer() if the request had SDP or tm is not loaded,
diff --git a/modules/rtpproxy/README b/modules/rtpproxy/README
index eb90232..9af7f23 100644
--- a/modules/rtpproxy/README
+++ b/modules/rtpproxy/README
@@ -640,8 +640,12 @@ rtpproxy_destroy();
with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
rtpproxy_answer()
* If ACK with SDP, then do rtpproxy_answer()
- * If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do
- unforce_rtpproxy()
+ * If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call
+ unforce_rtpproxy(). Be careful with calling this function after
+ resuming a suspended transaction (e.g., after t_continue()),
+ because the context of executed route is FAILURE ROUTE (in other
+ words, rtpproxy_manage() in the route block of t_continue() does
+ the same as in failure_route).
* If reply to INVITE with code >= 300 do unforce_rtpproxy()
* If reply with SDP to INVITE having code 1xx and 2xx, then do
rtpproxy_answer() if the request had SDP or tm is not loaded,
Hi,
- using latest rtpengine master from github .
- using kamailio configuration with rtpengine to process incoming WebRTC calls and forward as SIP/RTP calls, using rtpengine to process SRTP one side and RTP on the other side
- using the same kamailio configuration file between kamailio revisions
- using kamailio 4.4.0 or kamailio 4.4.1 everything works fine, but starting with kamailio 4.4.2 and newer this one does not send the same commands to rtpengine, there is no difference/error in kamailio log files
Starting with kamailio 4.4.2 the following elements are seen on socket between kamailio and rtpengine
> tcpdump -i any -n -p -s0 -A port 2223
> ...
> 14:46:48.050895 IP 127.0.0.1.47294 > 127.0.0.1.rockwell-csp2: UDP, length 194
> E...p,..@...................2_12168_1 d3:ICE6:remove18:transport-protocol7:RTP/AVP7:call-id36:68c3bb30-> > e7a8-11ab-3f61-04969aef87e413:received-froml3:IP415:192.168.160.127e8:from-tag20:AKlSUpLNnHZUFwLTPDxz7:command6:deletee
> 14:46:48.051038 IP 127.0.0.1.rockwell-csp2 > 127.0.0.1.47294: UDP, length 74
E..f..@.@.<..............R.e2_12168_1 d7:warning38:Call-ID not found or tags didn't match6:result2:oke
> 14:46:48.064394 IP 127.0.0.1.36712 > 127.0.0.1.rockwell-csp2: UDP, length 194
E...p:..@............h......2_12154_1 d3:ICE6:remove18:transport-protocol7:RTP/AVP7:call-id36:68c3bb30-e7a8-11ab-3f61-04969aef87e413:received-froml3:IP415:192.168.160.127e8:from-tag20:AKlSUpLNnHZUFwLTPDxz7:command6:deletee
> 14:46:48.064804 IP 127.0.0.1.rockwell-csp2 > 127.0.0.1.36712: UDP, length 74
E..f..@.@.<............h.R.e2_12154_1 d7:warning38:Call-ID not found or tags didn't match6:result2:oke
> ...
>
With older kamailio 4.4.1 or 4.4.0 the kamailio sent commands including received SDP
> 15:03:49.229974 IP 127.0.0.1.60102 > 127.0.0.1.rockwell-csp2: UDP, length 1938
E...r...@.. ................13292_3 d3:sdp1639:v=0
o=- 6640213216577907000 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS 9yLYCKgUvouNO6bYmskX60S0VD3SCy7KRuf6
m=audio 52254 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 192.168.160.127
a=rtcp:52255 IN IP4 192.168.160.127
a=candidate:143086084 1 udp 2122260223 192.168.160.127 52254 typ host generation 0 network-id 1
a=candidate:143086084 2 udp 2122260222 192.168.160.127 52255 typ host generation 0 network-id 1
a=candidate:1174712052 1 tcp 1518280447 192.168.160.127 9 typ host tcptype active generation 0 network-id 1
a=candidate:1174712052 2 tcp 1518280446 192.168.160.127 9 typ host tcptype active generation 0 network-id 1
...
Starting with kamailio 4.4.2 is there any recommended rtpengine revision to use or new configuration parameters to set ?
Thanks.
Regards.
--
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/855
Module: kamailio
Branch: master
Commit: e128d46e6a675b8cf5f8b584850c08cd16328af4
URL: https://github.com/kamailio/kamailio/commit/e128d46e6a675b8cf5f8b584850c08c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2016-11-21T12:15:54+01:00
rtpproxy: added note about rtpproxy_manage() afte t_continue()
- or after any other function that does suspend/resume of the
transaction
- it behaves as used in failure_route
---
Modified: modules/rtpproxy/doc/rtpproxy_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/e128d46e6a675b8cf5f8b584850c08c…
Patch: https://github.com/kamailio/kamailio/commit/e128d46e6a675b8cf5f8b584850c08c…
---
diff --git a/modules/rtpproxy/doc/rtpproxy_admin.xml b/modules/rtpproxy/doc/rtpproxy_admin.xml
index 49edff7..fcbab3a 100644
--- a/modules/rtpproxy/doc/rtpproxy_admin.xml
+++ b/modules/rtpproxy/doc/rtpproxy_admin.xml
@@ -680,7 +680,12 @@ rtpproxy_destroy();
</listitem>
<listitem>
<para>
- If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do <function>unforce_rtpproxy()</function>
+ If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call
+ <function>unforce_rtpproxy()</function>. Be careful with calling
+ this function after resuming a suspended transaction (e.g., after
+ t_continue()), because the context of executed route is FAILURE
+ ROUTE (in other words, rtpproxy_manage() in the route block of
+ t_continue() does the same as in failure_route).
</para>
</listitem>
<listitem>
Module: kamailio
Branch: master
Commit: 63f3e24ba2c0b9749f5c5d3268c633c629e20f89
URL: https://github.com/kamailio/kamailio/commit/63f3e24ba2c0b9749f5c5d3268c633c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2016-11-21T12:12:10+01:00
rtpengine: added note about rtpproxy_manage() afte t_continue()
- or after any other function that does suspend/resume of the
transaction
- it behaves as used in failure_route
- related to GH #855
---
Modified: modules/rtpengine/doc/rtpengine_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/63f3e24ba2c0b9749f5c5d3268c633c…
Patch: https://github.com/kamailio/kamailio/commit/63f3e24ba2c0b9749f5c5d3268c633c…
---
diff --git a/modules/rtpengine/doc/rtpengine_admin.xml b/modules/rtpengine/doc/rtpengine_admin.xml
index 515e5ae..f0d0ade 100644
--- a/modules/rtpengine/doc/rtpengine_admin.xml
+++ b/modules/rtpengine/doc/rtpengine_admin.xml
@@ -1091,7 +1091,12 @@ rtpengine_delete();
</listitem>
<listitem>
<para>
- If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do <function>rtpengine_delete()</function>
+ If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call
+ <function>rtpengine_delete()</function>. Be careful with calling
+ this function after resuming a suspended transaction (e.g., after
+ t_continue()), because the context of executed route is FAILURE
+ ROUTE (in other words, rtpengine_manage() in the route block of
+ t_continue() does the same as in failure_route).
</para>
</listitem>
<listitem>
Dear all, my name is Ancuta Corici (Onofrei) and am working at Fraunhofer FOKUS. We might have met or you might have seen some code from me in OpenSER and OpenIMSCore (e-cscf, support for offline charging).
We have now @ngvoice and many others to carry on the work on IMS and we send our greetings.
We are working now in the EU project reTHINK and would like to use kamailio ims for interop between webrtc clients and ims world.
For the moment, we are evaluating the status of IMS components and WebRTC support. Thus, we would like to know:
- if there is a more updated version on the installation info than http://www.kamailio.org/wiki/tutorials/ims/installation-howto?s[]=ims
- info on the configuration example file
- if there is a know-how on kamailio IMS and WebRTC support or intent to support it, as described on page 29 in http://www.etsi.org/deliver/etsi_ts/124300_124399/124371/13.04.00_60/ts_124…
@ngvoice : might be the best to answer, but if somebody else is having the info, we are open.
--
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/860
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. Exists a way to define this? or it is a bug? or should be a new feature?
--
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/864