sr-dev April 2010

sr-dev@lists.kamailio.org

27 participants
495 discussions

git:master: doc: Removed hardoded kamctl value and replaced it with an XML entity
by Marius Zbihlei 22 Apr '10

22 Apr '10

Module: sip-router Branch: master Commit: 93eb30d67bdb2be3d5ff2ab563af75a5958c26e1 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=93eb30d… Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Date: Thu Apr 22 13:19:58 2010 +0300 doc: Removed hardoded kamctl value and replaced it with an XML entity This will allow for faster documentation changes regarding the ser-kamailio ctl tools unification proposal --- docbook/entities.xml | 3 ++ modules/carrierroute/doc/carrierroute_admin.xml | 10 +++--- modules/db_berkeley/doc/db_berkeley_admin.xml | 10 +++--- modules/db_berkeley/km_doc/db_berkeley_admin.xml | 10 +++--- modules/db_flatstore/km_doc/db_flatstore_admin.xml | 2 +- modules/pdb/doc/pdb_admin.xml | 6 ++-- modules/utils/doc/utils_admin.xml | 8 ++-- modules_k/benchmark/doc/benchmark_admin.xml | 2 +- modules_k/cfgutils/doc/cfgutils_admin.xml | 36 ++++++++++---------- modules_k/db_oracle/doc/db_oracle_admin.xml | 2 +- modules_k/drouting/doc/drouting_admin.xml | 2 +- modules_k/nathelper/doc/nathelper_admin.xml | 6 ++-- modules_k/pv/doc/pv_admin.xml | 6 ++-- modules_k/siptrace/doc/siptrace_admin.xml | 4 +- modules_k/snmpstats/doc/snmpstats_faq.xml | 2 +- .../userblacklist/doc/userblacklist_admin.xml | 2 +- 16 files changed, 57 insertions(+), 54 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=93e…

1 0

git:master: dialog(k): populate bind addr before any error
by Daniel-Constantin Mierla 22 Apr '10

22 Apr '10

Module: sip-router Branch: master Commit: fd68980dc6f3de03a432f478c124852c23a1d1b2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=fd68980… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Apr 22 10:35:33 2010 +0200 dialog(k): populate bind addr before any error - setting bind addr attribute in populate_leg_info() takes place before any parsing error may occur, to be sure it is set, avoiding extra check for null value when updating db - reported by Kelvin Chua - credits to Timo Reimann for troubleshooting --- modules_k/dialog/dlg_handlers.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/modules_k/dialog/dlg_handlers.c b/modules_k/dialog/dlg_handlers.c index 1091777..3b671ab 100644 --- a/modules_k/dialog/dlg_handlers.c +++ b/modules_k/dialog/dlg_handlers.c @@ -200,6 +200,8 @@ int populate_leg_info( struct dlg_cell *dlg, struct sip_msg *msg, str contact; str rr_set; + dlg->bind_addr[leg] = msg->rcv.bind_address; + /* extract the cseq number as string */ if (leg==DLG_CALLER_LEG) { if((!msg->cseq && (parse_headers(msg,HDR_CSEQ_F,0)<0 || !msg->cseq)) @@ -269,7 +271,6 @@ int populate_leg_info( struct dlg_cell *dlg, struct sip_msg *msg, goto error0; } - dlg->bind_addr[leg] = msg->rcv.bind_address; if (rr_set.s) pkg_free(rr_set.s); return 0;

1 0

html body parts in mailing list messages
by jh＠tutpro.com 21 Apr '10

21 Apr '10

would it be possible to install a filter in the list server that would reject any message sent to sip-router mailing lists that have html body parts? in my opinion, only text/plain should be allowed. -- juha

2 1

Solutions to missing BYEs, accounting for them
by Alex Balashov 21 Apr '10

21 Apr '10

[Sorry for cross-posting this from sr-users; after some reflection upon posting, I got the impression this question may be more developer-centric than I initially imagined.] Hi all, Please forgive the slightly long post, but if you have anything to contribute on this topic, please consider giving it a read as I could really use your input. :-) As I'm sure many others of you running proxy-based service delivery platforms of some description also, I am faced with the problem of trying to account for calls with missing BYEs in a realistic way. There is no shortage of mailing list posts over the years on this topic. Inevitably, in a platform with sufficient call volume, with some NAT'd and/or endpoint diversity and other technical causes, there will be some calls that are never officially terminated from the point of view of a proxy. The ability of the 'dialog' module to spoof bidirectional BYEs on timeout[1] goes a long way toward addressing this problem theoretically. However, there are practical obstacles to relying on it solely as a solution, mainly because there is not an acceptable timeout value to use as a trade-off. If the timeout period is set to a very low value, users will obviously complain, and in any case, depending on the destination, the worst-case scenario for maximum call billing may still be far too high. If the timeout period is set high--perhaps something like 5-8 hours--then all calls that fail to end in the normal way will be billed some excessively large amount that certainly will not sit well with users either. If either the core delivery element of the platform or the user agent is tightly controlled by the operator of the proxy from an administrative point of view, it is indeed probably possible to rely on RTP timeouts or SIP Session Timers (SSTs) on one of the endpoints. That doesn't create a satisfying resolution for those of us dealing with indeterminate call completion scenarios with a great deal of user and vendor diversity, though. For instance, I route to about 15 ITSPs and carriers; I think maybe one of them does 15-minute SSTs, and the rest are certainly not going to turn them on just for me, even if their SBCs/switches/things have the capability. The user endpoints are mostly Asterisk and do RTP timeout, of course, and in most cases I do get the resulting BYE. However, this discussion is about the minute but nontrivial percentage of cases in which I do not get the BYE, whether because of NAT statekeeping problems or network reachability or whatever underlying causes--in truth, I cannot accurately characterise these. So, it seems to me that from a theoretical point of view, there are basically two directions someone in this position can go from here: 1) Inline B2BUA in the signaling path of all calls; 1a) Make it do SSTs; or 1b) Make it relay media, too, and hang up the call (bidirectional BYE) on RTP receive timeout; 2) Couple the proxy to an RTP relay and provide some mechanism by which the proxy can be made aware, in an asynchronous fashion, that an RTP timeout was detected by the relay. It seems to me from a brief and informal survey of prior mailing list literature that #1 is the usually recommended option here. If #1 is pursued, what is the best tool to use in the Kamailio/SIP-Router-oriented ecosystem? My default instinct would say SEMS; I really like SEMS, and use it a lot for various related chores. The problem is that the pre-built modules and examples for SEMS mostly center on application-level functionality, while low-level documentation of its powerful C++ API is a bit impoverished, so this would take a lot of work. Needless to say, I am interested in the option that requires the least work but still solves the problem in an elegant way from a technical and--dare I say--aesthetic perspective. For instance, it seems clear from looking at the SEMS-1.1.1 sources that SSTs are supported in principle in core/plug-in/session_timer. But unless I am missing something, I cannot find anywhere in the sources or examples where it is actually used. So, I suppose one option is to figure out how to make this stuff work in SEMS, and make it work. But for some reason who is not attune to the universe of its C++ API, it is a rather formidable chore. I think the same would hold true of making it observe bidirectional RTP timeout. Turning attention to option #2, I have looked at rtpproxy (my preferred default), iptrtpproxy, and mediaproxy modules but have not found any evidence that the control protocols Kamailio/SR uses to engage them support any notion of backward asynchronous feedback in case of RTP timeout. It would be really nice if one of these stream control protocols was augmented to kick back a packet to Kamailio that can be caught in a special event_route, like event_route[nathelper:rtp-stream-timeout], but that is clearly not the case today. To be honest, I would not use MediaProxy even if it had this feature, because, well, let's be bluntly honest and acknowledge what the more politically aware presumably already conjecture: in light of AG Projects' zealous OpenSIPS partnership, it's difficult to muster confidence in future compatibility of MediaProxy with Kamailio. The module is there, it works, and I'm sure its maintainers are dedicated to doing whatever it takes to reverse engineer and keep it working, lift patches from OpenSIPS as necessary, etc., but who wants to be on the wrong side of the project ecosystem fence? Not I. That leaves iptrtpproxy, whose 'switchboard' concept I do not fully comprehend due to lack of experience with it, but which holds a potentially viable, if slightly kludgy/Rube Goldbergian answer. Of the three RTP proxies, it is the only one that provides a ready means of exporting a list of media streams it is currently tracking, together with statistics on how many packets have been received, etc. It is not inconceivable to cook up an external process that will frequently check this 'switchboard', as it were, and incite Kamailio/SR to do dlg_bye() via MI if it appears that the media stream has disappeared from either side; the dialog module helpfully exports the MI command dlg_end_dlg. Still, this does not seem nearly as parsimonious and reliable a solution as simply building some kind of RTP stream leg timeout notification into the control socket. After all, the control socket is open persistently, right, not on-demand? The various RTP proxies all seem to have some kind of dead peer detection internally in order to have some means of gracefully expiring resources allocated to media streams that have gone away, so it would just be a matter of passing a control frame up the socket to Kamailio/SR and wiring that to a custom event_route or a more static callback in the code. By the way, I should mention that I am aware of and historically very sympathetic to the perspective that this kind of call control is alien to the nature of a proxy, and an appropriate job for UAs and not proxies at all. However, we all have to make pragmatic concessions to the realities of real-world operation, which I assume is the motivation for dialog timeouts, dlg_bye(), and other perversions from the point of view of a purist. :-) I welcome your thoughts and suggestions about the easiest and most technically meritorious approach. Thanks, -- Alex [1] Enabled via $dlg_ctx(timeout_bye) = 1 -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

2 1

Re: [sr-dev] Solutions to missing BYEs, accounting for them
by Andrade Ricardo (CI/ISE) 21 Apr '10

21 Apr '10

Hello Alex, I echo with your thought that one must allow some "real-world" exceptions, specially when you are faced with problems that haven't being addressed in the original concept. I am not a SIP purist, but after thinking about some similar workarounds as you are suggesting, I believe that the SIP Session Timers you mention (RFC 4028) is the only answer which is worth to work on, even though you say it is not satisfying. Actually it does solve some problems I have, when the timeout detection is necessary. I was forced to disable it completely in my environment because of some interoperability problems, but I really plan to turn it on again soon. Perhaps I am more comfortable to say that because I don't have such a diverse environment as yours, but we deal with 10 thousand clients from 5 different vendors. I've seen very diverse behaviors and many times we had to push them to implement some feature we needed, and nothing was better than bringing a RFC instead of implementing workarounds. This is the philosophy I am still trying to keep, bringing the manufactures to go in conformance with the RFCs and then I'll try to turn the timers on again. But I am afraid that may be different in your case. May I politely ask why the carriers would not switch on the Session Timers "for you"? I don't mean you haven't tried it already, I actually believe that you have probably heard a lot of "no", but before we go on with the discussion, I'd really be interested to know their argumentation. Mit freundlichen Grüßen / Best regards Ricardo Keigo de Sales Andrade Robert Bosch GmbH (CI/AFU) Postfach 30 02 20 70442 Stuttgart GERMANY www.bosch.com Tel. +49(711)811-3607004 Mobil +49(172)1081152 ricardo.andrade(a)br.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Hermann Scholl; Geschäftsführung: Franz Fehrenbach, Siegfried Dais; Bernd Bohr, Rudolf Colm, Volkmar Denner, Gerhard Kümmel, Wolfgang Malchow, Peter Marks, Peter Tyroller; Uwe Raschke -----Ursprüngliche Nachricht----- Date: Wed, 21 Apr 2010 05:40:03 -0400 From: Alex Balashov <abalashov(a)evaristesys.com> Subject: [sr-dev] Solutions to missing BYEs, accounting for them To: sr-dev <sr-dev(a)lists.sip-router.org> Message-ID: <4BCEC7F3.5070506(a)evaristesys.com> Content-Type: text/plain; charset=UTF-8; format=flowed [Sorry for cross-posting this from sr-users; after some reflection upon posting, I got the impression this question may be more developer-centric than I initially imagined.] Hi all, Please forgive the slightly long post, but if you have anything to contribute on this topic, please consider giving it a read as I could really use your input. :-) As I'm sure many others of you running proxy-based service delivery platforms of some description also, I am faced with the problem of trying to account for calls with missing BYEs in a realistic way. There is no shortage of mailing list posts over the years on this topic. Inevitably, in a platform with sufficient call volume, with some NAT'd and/or endpoint diversity and other technical causes, there will be some calls that are never officially terminated from the point of view of a proxy. The ability of the 'dialog' module to spoof bidirectional BYEs on timeout[1] goes a long way toward addressing this problem theoretically. However, there are practical obstacles to relying on it solely as a solution, mainly because there is not an acceptable timeout value to use as a trade-off. If the timeout period is set to a very low value, users will obviously complain, and in any case, depending on the destination, the worst-case scenario for maximum call billing may still be far too high. If the timeout period is set high--perhaps something like 5-8 hours--then all calls that fail to end in the normal way will be billed some excessively large amount that certainly will not sit well with users either. If either the core delivery element of the platform or the user agent is tightly controlled by the operator of the proxy from an administrative point of view, it is indeed probably possible to rely on RTP timeouts or SIP Session Timers (SSTs) on one of the endpoints. That doesn't create a satisfying resolution for those of us dealing with indeterminate call completion scenarios with a great deal of user and vendor diversity, though. For instance, I route to about 15 ITSPs and carriers; I think maybe one of them does 15-minute SSTs, and the rest are certainly not going to turn them on just for me, even if their SBCs/switches/things have the capability. The user endpoints are mostly Asterisk and do RTP timeout, of course, and in most cases I do get the resulting BYE. However, this discussion is about the minute but nontrivial percentage of cases in which I do not get the BYE, whether because of NAT statekeeping problems or network reachability or whatever underlying causes--in truth, I cannot accurately characterise these. So, it seems to me that from a theoretical point of view, there are basically two directions someone in this position can go from here: 1) Inline B2BUA in the signaling path of all calls; 1a) Make it do SSTs; or 1b) Make it relay media, too, and hang up the call (bidirectional BYE) on RTP receive timeout; 2) Couple the proxy to an RTP relay and provide some mechanism by which the proxy can be made aware, in an asynchronous fashion, that an RTP timeout was detected by the relay. It seems to me from a brief and informal survey of prior mailing list literature that #1 is the usually recommended option here. If #1 is pursued, what is the best tool to use in the Kamailio/SIP-Router-oriented ecosystem? My default instinct would say SEMS; I really like SEMS, and use it a lot for various related chores. The problem is that the pre-built modules and examples for SEMS mostly center on application-level functionality, while low-level documentation of its powerful C++ API is a bit impoverished, so this would take a lot of work. Needless to say, I am interested in the option that requires the least work but still solves the problem in an elegant way from a technical and--dare I say--aesthetic perspective. For instance, it seems clear from looking at the SEMS-1.1.1 sources that SSTs are supported in principle in core/plug-in/session_timer. But unless I am missing something, I cannot find anywhere in the sources or examples where it is actually used. So, I suppose one option is to figure out how to make this stuff work in SEMS, and make it work. But for some reason who is not attune to the universe of its C++ API, it is a rather formidable chore. I think the same would hold true of making it observe bidirectional RTP timeout. Turning attention to option #2, I have looked at rtpproxy (my preferred default), iptrtpproxy, and mediaproxy modules but have not found any evidence that the control protocols Kamailio/SR uses to engage them support any notion of backward asynchronous feedback in case of RTP timeout. It would be really nice if one of these stream control protocols was augmented to kick back a packet to Kamailio that can be caught in a special event_route, like event_route[nathelper:rtp-stream-timeout], but that is clearly not the case today. To be honest, I would not use MediaProxy even if it had this feature, because, well, let's be bluntly honest and acknowledge what the more politically aware presumably already conjecture: in light of AG Projects' zealous OpenSIPS partnership, it's difficult to muster confidence in future compatibility of MediaProxy with Kamailio. The module is there, it works, and I'm sure its maintainers are dedicated to doing whatever it takes to reverse engineer and keep it working, lift patches from OpenSIPS as necessary, etc., but who wants to be on the wrong side of the project ecosystem fence? Not I. That leaves iptrtpproxy, whose 'switchboard' concept I do not fully comprehend due to lack of experience with it, but which holds a potentially viable, if slightly kludgy/Rube Goldbergian answer. Of the three RTP proxies, it is the only one that provides a ready means of exporting a list of media streams it is currently tracking, together with statistics on how many packets have been received, etc. It is not inconceivable to cook up an external process that will frequently check this 'switchboard', as it were, and incite Kamailio/SR to do dlg_bye() via MI if it appears that the media stream has disappeared from either side; the dialog module helpfully exports the MI command dlg_end_dlg. Still, this does not seem nearly as parsimonious and reliable a solution as simply building some kind of RTP stream leg timeout notification into the control socket. After all, the control socket is open persistently, right, not on-demand? The various RTP proxies all seem to have some kind of dead peer detection internally in order to have some means of gracefully expiring resources allocated to media streams that have gone away, so it would just be a matter of passing a control frame up the socket to Kamailio/SR and wiring that to a custom event_route or a more static callback in the code. By the way, I should mention that I am aware of and historically very sympathetic to the perspective that this kind of call control is alien to the nature of a proxy, and an appropriate job for UAs and not proxies at all. However, we all have to make pragmatic concessions to the realities of real-world operation, which I assume is the motivation for dialog timeouts, dlg_bye(), and other perversions from the point of view of a purist. :-) I welcome your thoughts and suggestions about the easiest and most technically meritorious approach. Thanks, -- Alex [1] Enabled via $dlg_ctx(timeout_bye) = 1 -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

1 0

git:master: core: #!def aliased to #!define
by Daniel-Constantin Mierla 21 Apr '10

21 Apr '10

Module: sip-router Branch: master Commit: 4a9f0a3d1106a38db034668ebf127ca515d5b362 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4a9f0a3… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Apr 21 15:59:26 2010 +0200 core: #!def aliased to #!define - alternative to avoid conflicts with some text preprocessors --- cfg.lex | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cfg.lex b/cfg.lex index ffc8e1f..5b05b4f 100644 --- a/cfg.lex +++ b/cfg.lex @@ -530,7 +530,7 @@ COM_LINE # COM_START "/\*" COM_END "\*/" -DEFINE define +DEFINE "define"|"def" IFDEF ifdef IFNDEF ifndef ENDIF endif

1 0

git:master: pv: fixed pv class names in log messages
by Daniel-Constantin Mierla 21 Apr '10

21 Apr '10

Module: sip-router Branch: master Commit: 9b6c7de606acc48b5876fa13159e9bb3e63d8c09 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b6c7de… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Apr 21 15:11:05 2010 +0200 pv: fixed pv class names in log messages --- modules_k/pv/pv_branch.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules_k/pv/pv_branch.c b/modules_k/pv/pv_branch.c index e162104..28b15e8 100644 --- a/modules_k/pv/pv_branch.c +++ b/modules_k/pv/pv_branch.c @@ -323,7 +323,7 @@ int pv_parse_branchx_name(pv_spec_p sp, str *in) return 0; error: - LM_ERR("unknown PV time name %.*s\n", in->len, in->s); + LM_ERR("unknown PV branch name %.*s\n", in->len, in->s); return -1; } @@ -404,7 +404,7 @@ int pv_parse_snd_name(pv_spec_p sp, str *in) return 0; error: - LM_ERR("unknown PV time name %.*s\n", in->len, in->s); + LM_ERR("unknown PV snd name %.*s\n", in->len, in->s); return -1; }

1 0

git:master: dialplan: safety check for fetch rows before data init
by Daniel-Constantin Mierla 21 Apr '10

21 Apr '10

Module: sip-router Branch: master Commit: 5040ff5cc54f673af80190916de9c1ac5d4c1af9 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5040ff5… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Apr 21 15:04:55 2010 +0200 dialplan: safety check for fetch rows before data init --- modules/dialplan/dialplan.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/dialplan/dialplan.c b/modules/dialplan/dialplan.c index ad740b4..d514c4e 100644 --- a/modules/dialplan/dialplan.c +++ b/modules/dialplan/dialplan.c @@ -183,14 +183,14 @@ static int mod_init(void) return -1; } + if(dp_fetch_rows<=0) + dp_fetch_rows = 1000; + if(init_data() != 0) { LM_ERR("could not initialize data\n"); return -1; } - if(dp_fetch_rows<=0) - dp_fetch_rows = 1000; - return 0; }

1 0

git:master: modules_k/ usrloc Updated README to reflect the changes made to documentation
by Marius Zbihlei 21 Apr '10

21 Apr '10

Module: sip-router Branch: master Commit: 83ce345f438eecf53057c86042d030022287b13c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=83ce345… Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Date: Wed Apr 21 15:14:48 2010 +0300 modules_k/usrloc Updated README to reflect the changes made to documentation --- modules_k/usrloc/README | 867 +++++++++++++++++++++++++++-------------------- 1 files changed, 494 insertions(+), 373 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=83c…

1 0

[tracker] Task closed: (kamailio) Modify branch attributes via psuedo variables
by sip-router 21 Apr '10

21 Apr '10

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#8 - (kamailio) Modify branch attributes via psuedo variables User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Implemented Additional comments about closing: Implemented in commits git#4223ed and git#15627c. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=8 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
...
32
33
34
35
36
37
38
...
50
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2010