sr-dev April 2010

sr-dev@lists.kamailio.org

27 participants
495 discussions

git:kamailio_3.0: core: sip warning header disabled by default

by Daniel-Constantin Mierla

Module: sip-router Branch: kamailio_3.0 Commit: c0f409a686b6b468b406185dd090813aef46f513 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c0f409a… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sat Apr 17 11:46:44 2010 +0200 core: sip warning header disabled by default - do not append Warning header to local generated replies by default - it can be enabled from config file via sip_warning parameter (cherry picked from commit 258b58e29fe9e63a75d853d1826fe9c4b9a5f0ab) --- main.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/main.c b/main.c index 8d0f7e5..fc5c8ad 100644 --- a/main.c +++ b/main.c @@ -336,10 +336,10 @@ int phone2tel = 1; int syn_branch = 1; /* debugging level for timer debugging */ int timerlog = L_WARN; -/* should replies include extensive warnings? by default yes, +/* should replies include extensive warnings? by default no, good for trouble-shooting */ -int sip_warning = 1; +int sip_warning = 0; /* should localy-generated messages include server's signature? be default yes, good for trouble-shooting */

14 years, 7 months

git:master: core: sip warning header disabled by default

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 258b58e29fe9e63a75d853d1826fe9c4b9a5f0ab URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=258b58e… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sat Apr 17 11:46:44 2010 +0200 core: sip warning header disabled by default - do not append Warning header to local generated replies by default - it can be enabled from config file via sip_warning parameter --- main.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/main.c b/main.c index 64913c1..23db569 100644 --- a/main.c +++ b/main.c @@ -344,10 +344,10 @@ int phone2tel = 1; int syn_branch = 1; /* debugging level for timer debugging */ int timerlog = L_WARN; -/* should replies include extensive warnings? by default yes, +/* should replies include extensive warnings? by default no, good for trouble-shooting */ -int sip_warning = 1; +int sip_warning = 0; /* should localy-generated messages include server's signature? be default yes, good for trouble-shooting */

14 years, 7 months

git:master: modules/lcr: always use current time when loading gateways

by Juha Heinanen

Module: sip-router Branch: master Commit: 219771572b120fe9349170c7f8502b3be1ed22c1 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=2197715… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Wed Apr 14 17:17:59 2010 +0300 modules/lcr: always use current time when loading gateways - Always use current time when deciding if a gateway is defunct or not. Otherwise a gateway may get used even if its defunct until time in database is greater than current time. (cherry picked from commit 0c819f3ff3d947897fa0bafbaaa0081b671bb4e4) --- modules/lcr/lcr_mod.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/modules/lcr/lcr_mod.c b/modules/lcr/lcr_mod.c index 847e53b..8b03704 100644 --- a/modules/lcr/lcr_mod.c +++ b/modules/lcr/lcr_mod.c @@ -1741,12 +1741,11 @@ static int load_gws(struct sip_msg* _m, char *_lcr_id, char *_from_uri) gw_count = gws[0].ip_addr; if (defunct_capability > 0) { - now = time((time_t *)NULL); delete_avp(defunct_gw_avp_type, defunct_gw_avp); - } else { - now = MAX_UVAR_VALUE(now); } + now = time((time_t *)NULL); + while (pl) { if (ruri_user.len < pl->prefix_len) { pl = pl->next;

14 years, 7 months

git:master: tm: use E_CFG for handling the drop in branch route

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 208c9dab5e4545212ceedd2fe884360ebfd007f9 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=208c9da… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sat Apr 17 10:19:44 2010 +0200 tm: use E_CFG for handling the drop in branch route - don't print error message of failure adding branches since drop was called by script - reported by Juha Heinanen --- modules/tm/t_fwd.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/modules/tm/t_fwd.c b/modules/tm/t_fwd.c index 24dfeb1..cc22096 100644 --- a/modules/tm/t_fwd.c +++ b/modules/tm/t_fwd.c @@ -352,6 +352,8 @@ static int prepare_new_uac( struct cell *t, struct sip_msg *i_req, { tm_ctx_set_branch_index(0); set_route_type(backup_route_type); + /* triggered by drop in CFG */ + ret=E_CFG; goto error03; } } @@ -1385,7 +1387,8 @@ int t_forward_nonack( struct cell *t, struct sip_msg* p_msg , ser_error=MIN_int(lowest_ret, E_CFG); return -1; } - LOG(L_ERR, "ERROR: t_forward_nonack: failure to add branches\n"); + if(lowest_ret!=E_CFG) + LOG(L_ERR, "ERROR: t_forward_nonack: failure to add branches\n"); ser_error=lowest_ret; return lowest_ret; }

14 years, 7 months

'address' table and composite UNIQUE key for 'ip_addr' and 'mask' columns

by Iñaki Baz Castillo

Hi, 'ip_addr' and 'mask' columns (in 'address' table) should be a composite UNIQUE key as it doesn't make sense to have two entries sharing both values (the module would always take the first one). This would requiere a change in the DB schema. Opinions? -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 7 months

Is it possible to change media path?

by Abdul

Hi Friends, I am developing a project to encrypt/decrypt SIP Packet. for this project i made tow service one in client and other at server side. All going well, now my problem is that SIP Server send media packet to the local IP of SIP Client. Is there anyway to modify the SIP packet which came from client and change the media IP so SIP server should use that IP for media? in the below packet 89.45.22.xx is the sip server ip.in the below packet 10.0.0.27 is the nat ip for client but the WAN ip is : 79.662.40.91===============================================INVITE sip:800800@89.45.22.xx:5060SIP/2.0Via: SIP/2.0/UDP 10.0.0.27;branch=z9hG4bK-b4ab0c9a;rportFrom: 20012 <sip:20012@89.45.22.xx:5060>;tag=524054e9b5484c2o0To: <sip:800800@89.45.22.xx:5060>Call-ID: 3c7ca935-2b155ce6(a)10.0.0.27CSeq: 101 INVITEMax-Forwards: 70Contact: 20012 <sip:20012@10.0.0.27>Expires: 240User-Agent: Linksys/PAP2-3.1.22(LS)Content-Length: 247Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFERSupported: x-sipura, replacesContent-Type: application/sdp v=0o=- 412184 412184 IN IP4 10.0.0.27s=-c=IN IP4 10.0.0.27t=0 0m=audio 16410 RTP/AVP 4 100 101a=rtpmap:4 G723/8000a=rtpmap:100 NSE/8000a=fmtp:100 192-193a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=ptime:30a=sendrecv In this above packet, which value should i change, before sending to the SIP server so SIP server can send media direct to the client without passing to our service? I will appreciate for your kind of guides and help. BR,

14 years, 7 months

[tracker] Task opened: Kamailio/SIP-Router should return error (255) when cannot assign requested address even in fork mode

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Iñaki Baz Castillo (ibc) Attached to Project - sip-router Summary - Kamailio/SIP-Router should return error (255) when cannot assign requested address even in fork mode Task Type - Improvement Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Hi, there is an issue which prevents SR/Kamailio to being managed by software as HeartBeat (which mostly relies on init script return codes): Let's suppose we configure SR to work in fork=yes mode (of course) and to bind into a wrong address (i.e. a virtual address which for some reason is down in the server). When running it an error would be logged: ERROR:core:udp_init: bind(6, 0x813f414, 16) on 1.2.3.4: Cannot assign requested address However the command returns 0. This is ugly as it would indicate that the server has started correctly while in fact it's not running. This occurs because the sockets are initialized after daemonizing so the SR main process is forked before detecting such address error. Then the parent process (that we started by executing the command) knows nothing about the failure and just returns 0. Ok, so how to improve it? I asked for the same feature for Unicorn http server (a very robust http server writen in Ruby which is used by Github along with other sites): http://unicorn.bogomips.org/ The author implemented this feature, and the same could be implemented in SR. The mechanism is as follows (very simple and robust): * The parent process (launched from a controlling terminal or script) shares a pipe with the SR master process. The parent process reads in the pipe and the master process will write into it. * The parent process will wait until the master process is ready before returning. It will listen into the pipe until it received data from the master process, or until the pipe is closed by the master process: * If the master process determines the server can run (no errors) it will communicate it to the parent process via the shared pipe. Then the parent process exits with 0 (OK). * If instead the master process fails to start (i.e. "Cannot assign requested address") it will close the shared pipe. The parent process would detect such error (as the 'read' function would exit with error) and then it would exit with -1 (error). I will try to implement it by myself, but would prefer to hear your opinions first :) More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=66 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.

14 years, 7 months

[tracker] Assignee added: Kamailio/SIP-Router should return error (255) when cannot assign requested address even in fork mode

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#66 - Kamailio/SIP-Router should return error (255) when cannot assign requested address even in fork mode User who did this - Iñaki Baz Castillo (ibc) http://sip-router.org/tracker/index.php?do=details&task_id=66 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.

14 years, 7 months

kamailio 1.5 segfault when trying to listen in TCP at a non local address

by Iñaki Baz Castillo

Hi, my server has IP 9.9.9.9 but I set: listen=tcp:1.2.3.4 Running kamailio I get a segfault: -------------------- (gdb) bt full #0 0xb7e163b3 in strlen () from /lib/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7acfa4d in uac_init () at uac.c:112 src = {{s = 0xb7ad8810 "Long live SER server", len = 20}, {s = 0x0, len = 28}, {s = 0xb59940b8 "", len = -1213400550}} si = (struct socket_info *) 0x813f3d8 __FUNCTION__ = "uac_init" #2 0xb7ac2fc7 in mod_init () at tm.c:610 __FUNCTION__ = "mod_init" #3 0x08093ad3 in init_mod (m=0x813f7b0) at sr_module.c:408 __FUNCTION__ = "init_mod" #4 0x08093a70 in init_mod (m=0x813f9d0) at sr_module.c:403 __FUNCTION__ = "init_mod" #5 0x08093a70 in init_mod (m=0x8141050) at sr_module.c:403 __FUNCTION__ = "init_mod" #6 0x08093a70 in init_mod (m=0x81410f0) at sr_module.c:403 __FUNCTION__ = "init_mod" #7 0x08093a70 in init_mod (m=0x8141190) at sr_module.c:403 __FUNCTION__ = "init_mod" #8 0x08093a70 in init_mod (m=0x8141250) at sr_module.c:403 __FUNCTION__ = "init_mod" #9 0x08093a70 in init_mod (m=0x81412f0) at sr_module.c:403 __FUNCTION__ = "init_mod" #10 0x08093a70 in init_mod (m=0x8141390) at sr_module.c:403 __FUNCTION__ = "init_mod" #11 0x08093a70 in init_mod (m=0x8141468) at sr_module.c:403 __FUNCTION__ = "init_mod" #12 0x08093a70 in init_mod (m=0x8141508) at sr_module.c:403 __FUNCTION__ = "init_mod" #13 0x08093a70 in init_mod (m=0x81415e0) at sr_module.c:403 __FUNCTION__ = "init_mod" #14 0x08093a70 in init_mod (m=0x8141680) at sr_module.c:403 __FUNCTION__ = "init_mod" #15 0x08093a70 in init_mod (m=0x8141720) at sr_module.c:403 __FUNCTION__ = "init_mod" #16 0x08067d91 in main (argc=1, argv=0xbf9d96f4) at main.c:1303 cfg_log_stderr = 0 cfg_stream = (FILE *) 0x9b08008 c = <value optimized out> r = <value optimized out> tmp_len = <value optimized out> port = <value optimized out> proto = <value optimized out> ret = <value optimized out> rfd = <value optimized out> tmp = 0xb7ef6ff4 "\234m\025" seed = 2624953942 __FUNCTION__ = "main" -------------------- The log (debug=4) ends with: ------------------ Apr 15 18:48:14 callerid-loco-kamailio-1 kamailio[20588]: INFO:core:init_mod: initializing module tm Apr 15 18:48:14 callerid-loco-kamailio-1 kamailio[20588]: DBG:tm:init_callid: Call-ID initialization: '6fff2fff' Apr 15 18:48:14 callerid-loco-kamailio-1 kamailio[20588]: DBG:tm:lock_initialize: lock initialization started ------------------ -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 7 months

Re: [sr-dev] new dialog module design: tm trigger for dialog management

by Iñaki Baz Castillo

2010/4/1 Timo Reimann <timo.reimann(a)1und1.de>: > Hi, > > sorry for not replying any earlier. I was distracted by other, higher > prioritized tasks (such as vacation :) ). That's an important task! ;) > I just completed a major refurbishment on the proposal page according to > what we have discussed on the mailing list. Unfortunately, I had to do > it in one big piece instead of changing the page iteratively since the > changes depend on each other more or less. This is what I have modified: > > - Dialog state transition on responses is now done when a response is > forwarded (instead of when it is received). Ok > - References to and examples of spiraled routing with the > "allow_multiple_dialogs_for_spiral" parameter set to "yes" are gone. > There's just one way of spiraling left, plus a new callback > DLGCB_SPIRALED that allows users to hook up to spiraling events in order > to imitate the old behavior (without the drawback of having multiple > Kamailio dialogs to represent the same SIP dialog). Ok > - dialog_out does not need a state anymore. Ok > Please have a look and tell me what you think about it. (You will > probably need to re-read from top to bottom.) Furthermore, while I was > working on the page, I came up with two more questions and would be > grateful for some further feedback: It's really ok. I just did a minor fix you can see in the history. At the end of this mail I comment, however, a possible problem I see. > (1) Is the inv_branch parameter really needed? Initially, my impression > was that proxies require it in order to know which branches to prune in > case of remote forking and a final response coming in. However, the > inv_branch shouldn't be required for that IMHO since callbacks to the > response handling function pass along the dialog_in's hash ID that the > responses refer to. By matching the dialog_in's dialog_id with entries > in the dialog_out table, it can determine all the branches belonging to > a given call, and thereby also those that need to be deleted. Right. As now dialog status just relies on the responses sent upstream to the client I think inv_branch is not required anymore. I just see a minor issue with this. Imagine P1 is running the Dialog module and a proxy P2 behind it does parallel forking and replies 2 early dialogs. This would mean two entries under dialog_out table. Later P2 sends a negative final response for the first dialog. Just the dialog_out entry matching the To-tag would be deleted, while the other one would exist until the whole dialog is confirmed or terminated. Anyhow, I think this is not a big problem. > (2) Is the dialog_out table required for anything else but displaying > dialog data (e.g., callee To-tag, callee CSeq number, etc.) over the MI > interface right now? Specifically, is it needed for proper state > keeping? AFAICS, the current proposal's state machine may operate on > response codes/request methods and current state alone. > I realize that displaying statistics is important enough to hold on to > the dialog_out table; this question is for clarification purposes only. dialog_out entries are important in order to mantain the proper CSeq of caller and callee and also remote target and route set for each dialog (useful when using the Dialog module MI function to terminate a call). Also dialog_out entries store per (early-)dialog flags (dflags), probably needed by some modules also during early-dialog (i.e. mediaproxy and "engage_media()" method). Also, currently I see an issue related to "Concurrently confirmed calls": ------------- Immediately afterwards, Bob-2 replies 200 as well. The delay is too short for the proxy to cancel Bob-2 yet so it forwards the response it as well, thereby establishing another dialog. That is, a new dialog_in and dialog_out entry will be created from Bob-2's 200 response and associated with each other. In order to preserve any dflags from the dialog just confirmed, the proxy will also copy the dflags from the dialog_out entry under the current hash ID (which, remember, was passed as part of the callback). Specifically, it will find the dialog_out entry “branch1” for the hash ID “1111a” and copy its dflags to the new dialog_out entry ------------- Imagine the following case: - alice calls to bob and the proxy forks to bob1 and bob2. - Both replies 183 with SDP. - 183 from bob2 requires PRACK. - alice sends PRACK for bob2 (so its associated entry in dialog_out gets the caller_cseq incremented). - Module XXX sets a dflag(N) just for the dialog with bob1. - bob1 replies 200. - At this point the dialog_out entry for bob2 is destroyed. - But bob2 replies 200 before receiving the CANCEL. - As the text above states a new entry in dialog_out would be created by copying the dflags from the already confirmed dialog_out entry (so dfalg(N) is set), and copying the dialog_in's original_caller_cseq into its caller_cseq. This would be obviously wrong becase the created dialog for bob2 has a wrong caller_cseq and wrong dflags. However the solution seems easy: When a dialog gets confirmed mantain the rest of dialog_out entries for a while (maybe 3-5 seconds), time enough to ensure that if a new 200 arrives within an existing early-dialog it will match (an update properly) such entry in dialog_out. What do you think? Thanks a lot for all, really good job refactoring the page :) -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 7 months

← Newer
1
...
38
39
40
41
42
43
44
...
50
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2010