sr-dev

sr-dev@lists.kamailio.org

13 participants
44202 discussions

git:master: modules_s/domain: is_local can now be called from BRANCH_ROUTE

by Juha Heinanen

Module: sip-router Branch: master Commit: a86fdc96c147c584836d44fb41c92176338bfa8d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a86fdc9… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Mon Jul 13 15:28:59 2009 +0300 modules_s/domain: is_local can now be called from BRANCH_ROUTE - Added BRANCH_ROUTE to list of routes for is_local function after no one answered to my question on if it would cause any trouble. --- modules_s/domain/domain_mod.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_s/domain/domain_mod.c b/modules_s/domain/domain_mod.c index 30766da..8121285 100644 --- a/modules_s/domain/domain_mod.c +++ b/modules_s/domain/domain_mod.c @@ -128,7 +128,7 @@ static domain_t dom_buf[2]; * Exported functions */ static cmd_export_t cmds[] = { - {"is_local", is_local, 1, fixup_var_str_1, REQUEST_ROUTE|FAILURE_ROUTE }, + {"is_local", is_local, 1, fixup_var_str_1, REQUEST_ROUTE|FAILURE_ROUTE|BRANCH_ROUTE }, {"lookup_domain", lookup_domain, 2, lookup_domain_fixup, REQUEST_ROUTE|FAILURE_ROUTE }, {"get_did", (cmd_function)get_did, 0, 0, 0}, {0, 0, 0, 0, 0}

15 years, 6 months

xmlrpc interfaces

by jh＠tutpro.com

in situation where both k and s modules are in use, is there a need for two different xmlrpc clients or can s or k xmlrpc interface be used to issue all xmlrpc commands? i have noticed that serctl has mi argument after which a k ctl command can be given via ser ctl transport. does the same apply also to ser xmlrpc transport? -- juha

15 years, 6 months

[Fwd: Re: [Kamailio-Users] TCP supervisor process in Kamailio]

by Klaus Darilion

Hi Andrei! Do you think this is also relevant for sip-router's TCP implementation? regards klaus -------- Original-Nachricht -------- Betreff: Re: [Kamailio-Users] TCP supervisor process in Kamailio Datum: Tue, 7 Jul 2009 15:00:49 +0200 Von: Pascal Maugeri <pascal.maugeri(a)gmail.com> An: Daniel-Constantin Mierla <miconda(a)gmail.com> CC: kamailio <users(a)lists.kamailio.org> Referenzen: <990aed650907070551k594ee26cl3056fa7090742e1b(a)mail.gmail.com> <4A53466F.1070102(a)gmail.com> On Tue, Jul 7, 2009 at 2:58 PM, Daniel-Constantin Mierla<miconda(a)gmail.com> wrote: > Hello, > > On 07/07/2009 02:51 PM, Pascal Maugeri wrote: >> >> Hi >> >> I recently read the following in order to optimize OpenSER in handling >> TCP connections: >> >> "First, the TCP supervisor process must be given an elevated priority >> level in order to prevent anomalous behavior due to the Linux >> scheduler." >> >> First of all, as this is quite old paper > > where is this paper? http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf (Section 4.3, page 6). -pascal > > Thanks, > Daniel > >> (it refers to OpenSER 1.2), >> I'm wondering if such a tuning is still needed for Kamailio 1.5 branch >> ? If yes, how can I do this ? >> >> Regards, >> Pascal >> >> _______________________________________________ >> Kamailio (OpenSER) - Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >> >> > > -- > Daniel-Constantin Mierla > http://www.asipto.com/ > > _______________________________________________ Kamailio (OpenSER) - Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

15 years, 6 months

roadmap to kamailio 3.0

by Daniel-Constantin Mierla

Hello, the roadmap to next major release of Kamailio, codenamed 3.0, was sketched during last week IRC meeting as: - freezing in 1-1.5 months - 1-1.5 months testing - release by end of September/ beginning of October Right now, current development state is: - all but one module (seas) were updated to work with the new core - several addons in kamailio core and tm still to be included in GIT master branch - many new features developed: mecached, event_route, xml doc handling ... see: http://sip-router.org/wiki/features/new-in-devel I invite all of you to test, startup guidelines at: http://sip-router.org/wiki/migration/kamailio-3.0-config Any feedback is very much appreciated, thanks, Daniel -- Daniel-Constantin Mierla http://www.asipto.com/

15 years, 6 months

preparing kamailio 1.5.2

by Daniel-Constantin Mierla

Hello, last week during the IRC meeting it was proposed to release kamailio 1.5.2 tomorrow. If anyone of you is aware of some show stopper, please reply. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com/

15 years, 6 months

git:master: tm: reason phrase of 100 is corrected in t_suspend()

by Miklos Tirpak

Module: sip-router Branch: master Commit: 5775f9b86b14ef5887112a12d098d38e283b47c0 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5775f9b… Author: Miklos Tirpak <miklos(a)iptel.org> Committer: Miklos Tirpak <miklos(a)iptel.org> Date: Fri Jul 10 16:02:14 2009 +0200 tm: reason phrase of 100 is corrected in t_suspend() - t_suspend() now uses the tm_auto_inv_100_r config option to form the 100 reply message. --- modules/tm/t_suspend.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/modules/tm/t_suspend.c b/modules/tm/t_suspend.c index c8527a5..f6a57d0 100644 --- a/modules/tm/t_suspend.c +++ b/modules/tm/t_suspend.c @@ -34,6 +34,7 @@ #include "../../action.h" #include "../../script_cb.h" +#include "config.h" #include "sip_msg.h" #include "t_reply.h" #include "h_table.h" @@ -69,7 +70,7 @@ int t_suspend(struct sip_msg *msg, && (t->uas.status < 100) ) { if (!t_reply( t, msg , 100 , - "trying -- your call is important to us")) + cfg_get(tm, tm_cfg, tm_auto_inv_100_r))) DBG("SER: ERROR: t_suspend (100)\n"); }

15 years, 6 months

git:master: tm: check whether or not 100 response has already been sent

by Miklos Tirpak

Module: sip-router Branch: master Commit: a3fe154263bd4c94e53c55ea7af42cf6e1952cd5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3fe154… Author: Miklos Tirpak <miklos(a)iptel.org> Committer: Miklos Tirpak <miklos(a)iptel.org> Date: Fri Jul 10 15:58:17 2009 +0200 tm: check whether or not 100 response has already been sent - Do not send the 100 Trying response when it has already been sent The script writer can do it for example before t_relay(). --- modules/tm/t_funcs.c | 5 +++-- modules/tm/t_suspend.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/modules/tm/t_funcs.c b/modules/tm/t_funcs.c index aa7d1f4..33d141d 100644 --- a/modules/tm/t_funcs.c +++ b/modules/tm/t_funcs.c @@ -342,8 +342,9 @@ int t_relay_to( struct sip_msg *p_msg , struct proxy_l *proxy, int proto, /* INVITE processing might take long, particularly because of DNS look-ups -- let upstream know we're working on it */ - if (p_msg->REQ_METHOD==METHOD_INVITE && (t->flags&T_AUTO_INV_100)) - { + if (p_msg->REQ_METHOD==METHOD_INVITE && (t->flags&T_AUTO_INV_100) + && (t->uas.status < 100) + ) { DBG( "SER: new INVITE\n"); if (!t_reply( t, p_msg , 100 , cfg_get(tm, tm_cfg, tm_auto_inv_100_r))) diff --git a/modules/tm/t_suspend.c b/modules/tm/t_suspend.c index f05e7eb..c8527a5 100644 --- a/modules/tm/t_suspend.c +++ b/modules/tm/t_suspend.c @@ -65,7 +65,9 @@ int t_suspend(struct sip_msg *msg, /* send a 100 Trying reply, because the INVITE processing will probably take a long time */ - if (msg->REQ_METHOD==METHOD_INVITE && (t->flags&T_AUTO_INV_100)) { + if (msg->REQ_METHOD==METHOD_INVITE && (t->flags&T_AUTO_INV_100) + && (t->uas.status < 100) + ) { if (!t_reply( t, msg , 100 , "trying -- your call is important to us")) DBG("SER: ERROR: t_suspend (100)\n");

15 years, 6 months

[ openser-Bugs-2819457 ] dialog module. BYE with bad Cseq.

by SourceForge.net

Bugs item #2819457, was opened at 2009-07-10 10:47 Message generated for change (Comment added) made by baron76 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Dubovikov (baron76) Assigned to: Nobody/Anonymous (nobody) Summary: dialog module. BYE with bad Cseq. Initial Comment: the dialog module in timeout BYE request send thru tm_module Cseq number from INVITE. dlg_req_within.c: function: dlg_t * build_dlg_t(struct dlg_cell * cell, int dir){ line: td->loc_seq.value = loc_seq; if before final 200 OK, we will recieve PRACK/200 (new Cseq) , the dialog module will send bad Cseq number (loc_seq + 1); Scenario: ----INVITE ( Cseq: 1) -> <--- 183 ( Cseq: 1) ---- ---- PRACK ( Cseq: 3) -> <---- 200 OK ( Cseq: 3) - ---------- timeout ----> ---- BYE ( Cseq: 2) -> <------ 503 (Bad CSeq number) ------- Quickly Solution: td->loc_seq.value = loc_seq + 100; ---------------------------------------------------------------------- >Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 16:02 Message: should but didn't. because dlg_onroute check record-route param. If the param is not present, than ignored this message. if ( seq_match_mode!=SEQ_MATCH_NO_ID ) { if( d_rrb.get_route_param( req, &rr_param, &val)!=0) { LM_DBG("Route param '%.*s' not found\n", rr_param.len,rr_param.s); if (seq_match_mode==SEQ_MATCH_STRICT_ID ) return; } default value for dlg_match_mode is 0; so. should works only in dlg_match_mode 2 2 - DID_NONE - the match is done exclusively based on SIP elements; no DID information is added in RR. . so fix should be anyway. Or default value set to 2, or loc_cseq +100 or a notice in the README: "in 100rel mode, use only dlg_match_mode 2. Daniel. you should decide. :-) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-10 15:22 Message: CSeq should be increased in dialog module also for PRACKs. What's the original problem? Is dialog module not able to detect the PRACK as belonging to the dialog? ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 15:19 Message: ok, in this case we couldn't remove Require, but can use this solution: http://www.faqs.org/rfcs/rfc3261.html 8.2.2.3 Require UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. anyway, all ways are posible. But as I told before, just make loc_seq +=100; it will be enougth. Wbr, Alexandr ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-10 14:37 Message: Imagine that the UAC uses "Require: 100rel" instead of "Supported". The header cannot be removed or the call won't take place. A proxy shouldn't play to be god :) ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 13:56 Message: > and PRACK/200 ok in the dialog. But I think, the best solution, set and PRACK/200 are not ok in the dialog. But I think, the best solution, set ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 13:55 Message: Hi miconda, much better remove_hf("Supported:") from INVITE request; :-) and PRACK/200 ok in the dialog. But I think, the best solution, set loc_seq +100. P.S. don't forget about UPDATE method. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2009-07-10 13:48 Message: quick fix: reply pracks on server, with sl_send_reply() as they just get into config?!?! ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-10 12:59 Message: This is a good example of why a proxy shouldn't try to behave as a B2BUA XD ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 10:50 Message: oops: Scenario: ----INVITE ( Cseq: 1) -> <--- 183 ( Cseq: 1) ---- ---- PRACK ( Cseq: 3) -> <---- 200 OK ( Cseq: 3 PRACK) - <---- 200 OK ( Cseq: 1 INVITE) - ---------- timeout dialog ----> ---- BYE ( Cseq: 2) -> <------ 503 (Bad CSeq number) ------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_…

15 years, 6 months

[ openser-Bugs-2819457 ] dialog module. BYE with bad Cseq.

by SourceForge.net

Bugs item #2819457, was opened at 2009-07-10 08:47 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Dubovikov (baron76) Assigned to: Nobody/Anonymous (nobody) Summary: dialog module. BYE with bad Cseq. Initial Comment: the dialog module in timeout BYE request send thru tm_module Cseq number from INVITE. dlg_req_within.c: function: dlg_t * build_dlg_t(struct dlg_cell * cell, int dir){ line: td->loc_seq.value = loc_seq; if before final 200 OK, we will recieve PRACK/200 (new Cseq) , the dialog module will send bad Cseq number (loc_seq + 1); Scenario: ----INVITE ( Cseq: 1) -> <--- 183 ( Cseq: 1) ---- ---- PRACK ( Cseq: 3) -> <---- 200 OK ( Cseq: 3) - ---------- timeout ----> ---- BYE ( Cseq: 2) -> <------ 503 (Bad CSeq number) ------- Quickly Solution: td->loc_seq.value = loc_seq + 100; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-10 13:22 Message: CSeq should be increased in dialog module also for PRACKs. What's the original problem? Is dialog module not able to detect the PRACK as belonging to the dialog? ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 13:19 Message: ok, in this case we couldn't remove Require, but can use this solution: http://www.faqs.org/rfcs/rfc3261.html 8.2.2.3 Require UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. anyway, all ways are posible. But as I told before, just make loc_seq +=100; it will be enougth. Wbr, Alexandr ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-10 12:37 Message: Imagine that the UAC uses "Require: 100rel" instead of "Supported". The header cannot be removed or the call won't take place. A proxy shouldn't play to be god :) ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 11:56 Message: > and PRACK/200 ok in the dialog. But I think, the best solution, set and PRACK/200 are not ok in the dialog. But I think, the best solution, set ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 11:55 Message: Hi miconda, much better remove_hf("Supported:") from INVITE request; :-) and PRACK/200 ok in the dialog. But I think, the best solution, set loc_seq +100. P.S. don't forget about UPDATE method. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2009-07-10 11:48 Message: quick fix: reply pracks on server, with sl_send_reply() as they just get into config?!?! ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-10 10:59 Message: This is a good example of why a proxy shouldn't try to behave as a B2BUA XD ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 08:50 Message: oops: Scenario: ----INVITE ( Cseq: 1) -> <--- 183 ( Cseq: 1) ---- ---- PRACK ( Cseq: 3) -> <---- 200 OK ( Cseq: 3 PRACK) - <---- 200 OK ( Cseq: 1 INVITE) - ---------- timeout dialog ----> ---- BYE ( Cseq: 2) -> <------ 503 (Bad CSeq number) ------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_…

15 years, 6 months

[ openser-Bugs-2819457 ] dialog module. BYE with bad Cseq.

by SourceForge.net

Bugs item #2819457, was opened at 2009-07-10 10:47 Message generated for change (Comment added) made by baron76 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Dubovikov (baron76) Assigned to: Nobody/Anonymous (nobody) Summary: dialog module. BYE with bad Cseq. Initial Comment: the dialog module in timeout BYE request send thru tm_module Cseq number from INVITE. dlg_req_within.c: function: dlg_t * build_dlg_t(struct dlg_cell * cell, int dir){ line: td->loc_seq.value = loc_seq; if before final 200 OK, we will recieve PRACK/200 (new Cseq) , the dialog module will send bad Cseq number (loc_seq + 1); Scenario: ----INVITE ( Cseq: 1) -> <--- 183 ( Cseq: 1) ---- ---- PRACK ( Cseq: 3) -> <---- 200 OK ( Cseq: 3) - ---------- timeout ----> ---- BYE ( Cseq: 2) -> <------ 503 (Bad CSeq number) ------- Quickly Solution: td->loc_seq.value = loc_seq + 100; ---------------------------------------------------------------------- >Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 15:19 Message: ok, in this case we couldn't remove Require, but can use this solution: http://www.faqs.org/rfcs/rfc3261.html 8.2.2.3 Require UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. anyway, all ways are posible. But as I told before, just make loc_seq +=100; it will be enougth. Wbr, Alexandr ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-10 14:37 Message: Imagine that the UAC uses "Require: 100rel" instead of "Supported". The header cannot be removed or the call won't take place. A proxy shouldn't play to be god :) ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 13:56 Message: > and PRACK/200 ok in the dialog. But I think, the best solution, set and PRACK/200 are not ok in the dialog. But I think, the best solution, set ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 13:55 Message: Hi miconda, much better remove_hf("Supported:") from INVITE request; :-) and PRACK/200 ok in the dialog. But I think, the best solution, set loc_seq +100. P.S. don't forget about UPDATE method. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2009-07-10 13:48 Message: quick fix: reply pracks on server, with sl_send_reply() as they just get into config?!?! ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-10 12:59 Message: This is a good example of why a proxy shouldn't try to behave as a B2BUA XD ---------------------------------------------------------------------- Comment By: Alexandr Dubovikov (baron76) Date: 2009-07-10 10:50 Message: oops: Scenario: ----INVITE ( Cseq: 1) -> <--- 183 ( Cseq: 1) ---- ---- PRACK ( Cseq: 3) -> <---- 200 OK ( Cseq: 3 PRACK) - <---- 200 OK ( Cseq: 1 INVITE) - ---------- timeout dialog ----> ---- BYE ( Cseq: 2) -> <------ 503 (Bad CSeq number) ------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_…

15 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev