sr-dev July 2014

sr-dev@lists.kamailio.org

25 participants
140 discussions

git:master: usrloc: refresh call-id value in case of update of location record
by Daniel-Constantin Mierla 17 Jul '14

17 Jul '14

Module: sip-router Branch: master Commit: c2b334bf41cbe6fa7b7e15d825dca1fa36c33770 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c2b334b… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Jul 17 19:13:42 2014 +0200 usrloc: refresh call-id value in case of update of location record - related to FS#448 --- modules/usrloc/ucontact.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/modules/usrloc/ucontact.c b/modules/usrloc/ucontact.c index c0c48f2..ead8e40 100644 --- a/modules/usrloc/ucontact.c +++ b/modules/usrloc/ucontact.c @@ -270,12 +270,14 @@ int mem_update_ucontact(ucontact_t* _c, ucontact_info_t* _ci) if(_ci->instance.s!=NULL && _ci->instance.len>0) { - /* when we have instance set, update contact address and call-id */ + /* when we have instance set, update contact address */ if(_ci->c!=NULL && _ci->c->s!=NULL && _ci->c->len>0) update_str( &_c->c, _ci->c); - if(_ci->callid!=NULL && _ci->callid->s!=NULL && _ci->callid->len>0) - update_str( &_c->callid, _ci->callid); } + + /* refresh call-id */ + if(_ci->callid!=NULL && _ci->callid->s!=NULL && _ci->callid->len>0) + update_str( &_c->callid, _ci->callid); update_str( &_c->user_agent, _ci->user_agent); if (_ci->received.s && _ci->received.len) {

1 0

[tracker] Comment added: rtpproxy_manage with "l" option returns wrong ports
by sip-router 17 Jul '14

17 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#451 - rtpproxy_manage with "l" option returns wrong ports User who did this - Daniel-Constantin Mierla (miconda) ---------- I haven't checked yet the purpose of l command for rtpproxy, but it is not clear for me why you need it for re-INVITE? I use always the same options for rtpproxy_manage() for initial invite as well as re-invites. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=451#comment1549 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

git:master: registrar: README regenerated after fixing typo and xacp_cfg socket option
by Daniel-Constantin Mierla 17 Jul '14

17 Jul '14

Module: sip-router Branch: master Commit: d19c9fc484dc9eaf9ecc5d7855fec4f90a8d4a1f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d19c9fc… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Jul 17 17:27:03 2014 +0200 registrar: README regenerated after fixing typo and xacp_cfg socket option --- modules/registrar/README | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/modules/registrar/README b/modules/registrar/README index fe52651..99202e8 100644 --- a/modules/registrar/README +++ b/modules/registrar/README @@ -108,7 +108,7 @@ Bogdan-Andre Iancu 1.12. Set max_contacts parameter 1.13. Set retry_after parameter 1.14. Set sock_flag parameter - 1.15. Set sock_hdr_namer parameter + 1.15. Set sock_hdr_name parameter 1.16. Set method_filtering parameter 1.17. Set use_path parameter 1.18. Set path_mode parameter @@ -533,7 +533,7 @@ modparam("registrar", "sock_flag", 18) Default value is NULL. - Example 1.15. Set sock_hdr_namer parameter + Example 1.15. Set sock_hdr_name parameter ... modparam("registrar", "sock_hdr_name", "Sock-Info") ... @@ -621,6 +621,8 @@ modparam("registrar", "reg_callid_avp", "$avp(s:avp)") * max_contacts - the number of maximum contacts to be stored for current registration AoR. It overwrites the 'max_contacts' module parameter value. + * socket - the string representing the socket on which the register + rquest was received, as alternative to using the sock_hdr. For example. if this parameter is set to 'reg', then the number of maximum contacts can be set in $xavp(reg=>max_contacts).

1 0

git:master: registrar: documented the option to take socket value via xavp
by Daniel-Constantin Mierla 17 Jul '14

17 Jul '14

Module: sip-router Branch: master Commit: 6c569e1a759c70398cac0375b0da9dad41928713 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6c569e1… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Jul 17 17:26:37 2014 +0200 registrar: documented the option to take socket value via xavp --- modules/registrar/doc/registrar_admin.xml | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/modules/registrar/doc/registrar_admin.xml b/modules/registrar/doc/registrar_admin.xml index 90d889c..4cd2053 100644 --- a/modules/registrar/doc/registrar_admin.xml +++ b/modules/registrar/doc/registrar_admin.xml @@ -498,7 +498,7 @@ modparam("registrar", "sock_flag", 18) </emphasis> </para> <example> - <title>Set <varname>sock_hdr_namer</varname> parameter</title> + <title>Set <varname>sock_hdr_name</varname> parameter</title> <programlisting format="linespecific"> ... modparam("registrar", "sock_hdr_name", "Sock-Info") @@ -662,6 +662,13 @@ modparam("registrar", "reg_callid_avp", "$avp(s:avp)") overwrites the 'max_contacts' module parameter value. </para> </listitem> + <listitem> + <para> + <emphasis>socket</emphasis> - the string representing the + socket on which the register rquest was received, as alternative + to using the sock_hdr. + </para> + </listitem> </itemizedlist> <para> For example. if this parameter is set to 'reg', then the number

1 0

[tracker] Comment added: CNXCC: add \n at end of each log outputs (LM_XXX functions)
by sip-router 16 Jul '14

16 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#452 - CNXCC: add \n at end of each log outputs (LM_XXX functions) User who did this - Carlos Ruiz Diaz (caruizdiaz) ---------- Will do this after patching the module with the new contribution. ETA is this week, with hard deadline set to weekend. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=452#comment1548 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] User took ownership: CNXCC: add \n at end of each log outputs (LM_XXX functions)
by sip-router 16 Jul '14

16 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Carlos Ruiz Diaz has taken ownership of the following task: FS#452 - CNXCC: add \n at end of each log outputs (LM_XXX functions) More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=452 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Task opened: CNXCC: add \n at end of each log outputs (LM_XXX functions)
by sip-router 16 Jul '14

16 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Guillaume Bour (gbour) Attached to Project - sip-router Summary - CNXCC: add \n at end of each log outputs (LM_XXX functions) Task Type - Improvement Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=452 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

app_python: call_function "append_hf" with more than 1 param crashes kamailio
by Örn Arnarson 16 Jul '14

16 Jul '14

Resent after signing up, due to original message being held for review for a week: Kamailio terminates (Signal 15) after app_python crashes (signal 7) when using call_function("append_hf") with more than 1 parameter. Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: ALERT: <core> [main.c:788]: handle_sigs(): child process 2707 exited by a signal 7 Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: ALERT: <core> [main.c:791]: handle_sigs(): core was generated Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: INFO: <core> [main.c:803]: handle_sigs(): INFO: terminating due to SIGCHLD Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2706]: INFO: <core> [main.c:854]: sig_usr(): INFO: signal 15 received Actually, calling "remove_hf" with call_function seems to do exactly the same thing, though that is just with 1 param. My problem is that I need to manipulate the Diversion headers (or rather, add a new Diversion header in the correct place (i.e. above the other Diversion header), as append_hf will always add it at the bottom.) I've identified what part of the code makes it crash (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio: if (fexport->fixup != NULL) { if (i >= 3) { rval = fexport->fixup(&(act->val[3].u.data), 2); if (rval < 0) { PyErr_SetString(PyExc_RuntimeError, "Error in fixup (2)"); Py_INCREF(Py_None); return Py_None; } act->val[3].type = MODFIXUP_ST; } if (i >= 2) { rval = fexport->fixup(&(act->val[2].u.data), 1); if (rval < 0) { PyErr_SetString(PyExc_RuntimeError, "Error in fixup (1)"); Py_INCREF(Py_None); return Py_None; } act->val[2].type = MODFIXUP_ST; } if (i == 1) { rval = fexport->fixup(0, 0); if (rval < 0) { PyErr_SetString(PyExc_RuntimeError, "Error in fixup (0)"); Py_INCREF(Py_None); return Py_None; } } } I have very little experience with programming in C, and even less debugging with gdb or something similar, but from comparing this code with the way the Perl module does this, I couldn't see any obvious problems. I'm hoping someone with familiarity with the kamailio functions, such as fixup, might be able to identify the problem. Judging from the exit code of app_python, my (uninformed) guess would be that there's an attempt to access or manipulate something in an out-of-scope memory address. Any suggestions would be greatly appreciated. I've written a quite large routing function in python and I'd like to avoid rewriting it in a different scripting language if possible. The kamailio version I'm running is 4.0.4 Regards, Örn

2 4

[tracker] Task opened: rtpproxy_manage with "l" option returns wrong ports
by sip-router 16 Jul '14

16 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Sebastian Damm (sdamm) Attached to Project - sip-router Summary - rtpproxy_manage with "l" option returns wrong ports Task Type - Bug Report Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Normal Reported Version - 4.1 Due in Version - Undecided Due Date - Undecided Details - When using the rtpproxy_manage (or rtpproxy_offer) function with the lookup option, it returns wrong ports. Example: When initializing a call, we use rtpproxy_manage without options, the same is for replies. We do this only if one of the phones is behind NAT. INVITE -> rtpproxy_manage -> Port 40000 200 OK -> rtpproxy_manage -> Port 50000 Now, when a reINVITE comes in, we want to issue rtpproxy_manage with the lookup option. If we don't add the l option and we didn't force the call through the RTP proxy at call setup time, the media will still be forced through the RTP proxy after the reINVITE. And since we can't identify the NAT situation of both parties in all cases when getting a reINVITE, we can't issue rtpproxy_manage conditionally. This is what happens: reINVITE -> rtpproxy_manage(l) -> Port 50000 200 OK -> rtpproxy_manage -> Port 50000 If I check the control traffic to the RTP proxy, I can see the following: INVITE: -> 20284_8 Uc8,101 1741c653ffce-tg2yumkozs63 192.168.1.5 53428 10wk7ltl70;1 <- 20284_8 40000 1.2.3.4 200 OK: -> 20272_8 Lc8,101 1741c653ffce-tg2yumkozs63 10.0.0.5 20290 10wk7ltl70;1 as276b8fe2;1 <- 20272_8 50000 1.2.3.4 reINVITE: -> 20270_8 Lc8,101 1741c653ffce-tg2yumkozs63 192.168.1.5 53428 10wk7ltl70;1 as276b8fe2;1 <- 20270_8 50000 1.2.3.4 200 OK: -> 20285_8 Lc8,101 1741c653ffce-tg2yumkozs63 10.0.0.5 20290 10wk7ltl70;1 as276b8fe2;1 <- 20285_8 50000 1.2.3.4 As you can see, the call for the reINVITE and 200 OK are identical (except for the IP and port). What actually should happen is, that for the reINVITE the tags should be swapped, so the RTP proxy returns the correct port for the request. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=451 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: sca_call_info_update() function for 180 responses
by sip-router 15 Jul '14

15 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#446 - sca_call_info_update() function for 180 responses User who did this - Joao Vitor Arruda (jarruda) ---------- The Jorj proposed patch removing lines 1075-1077 of sca_call_info.c looks fine for me. If someone have write access to make this change to the repository we would appreciate. ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=446#comment1547 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2014