sr-dev September 2011

sr-dev@lists.kamailio.org

40 participants
298 discussions

[tracker] Task opened: dialplan replacement with AVPs doesn't work

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 - Andrew Pogrebennyk (marduk) Attached to Project - sip-router Summary - dialplan replacement with AVPs doesn't work Task Type - Bug Report Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Normal Reported Version - 3.1 Due in Version - Undecided Due Date - Undecided Details - Hi, I'm checking dialplan with AVPs in repl_exp. There was an attempt to fix it in commit eb005b74c1d47d215b17ac395efafe56c14ec295 but it doesn't give the expected results: the replacement, which should be an AVP value, is empty: Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dialplan.c:235]: searching 4 Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dialplan.c:251]: searching 7 Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dialplan.c:338]: input is 0101 Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dp_repl.c:326]: regex operator testing Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dp_repl.c:362]: found a matching rule 0x7ff6516be588: pr 996, match_exp ^0([1-9][0-9]+)$ Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dp_repl.c:268]: copying pvar value <> token size 17 Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dp_repl.c:268]: copying pvar value <> token size 17 Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dp_repl.c:219]: copying match <101> token size 2 Sep 12 10:35:46 andrewdev1 /usr/sbin/kamailio[7610]: DEBUG: dialplan [dialplan.c:347]: input 0101 with dpid 6 => output 101 Here is the dialplan rule: mysql> select * from dialplan where dpid=6\G *************************** 1. row *************************** id: 5 dpid: 6 pr: 996 match_op: 1 match_exp: ^0([1-9][0-9]+)$ match_len: 0 subst_exp: ^0([1-9][0-9]+)$ repl_exp: $avp(s:caller_cc)$avp(s:caller_ac)\1 attrs: 1 row in set (0.00 sec) I have checked with debug statements that $avp(s:caller_cc) and $avp(s:caller_ac) contain values. Where else could I possibly look? Thanks. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=153 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.

12 years, 12 months

[tracker] Assignee added: dialplan replacement with AVPs doesn't work

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#153 - dialplan replacement with AVPs doesn't work User who did this - Andrew Pogrebennyk (marduk) http://sip-router.org/tracker/index.php?do=details&task_id=153 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.

12 years, 12 months

Dialog2

by Jason Penton

Hi All, Does anyone know if work has been started on dialog2 as proposed here: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-… If not we are looking at starting it if that is ok? Also, who wrote this page on the wiki? I know some features like spiraling have been included in original dialog module, but I know forking doesn't work and terminating early dialog sessions, etc Cheers Jason

12 years, 12 months

[tracker] Comment added: dialog flags in onreply route

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#151 - dialog flags in onreply route User who did this - Timo Reimann (tr) ---------- As mentioned on the mailing list, the code to access dialog data in reply routes is already there and used for other features of the module (for example, CDR generation). Dialog flags, however, and treated differently yet. Their implementation needs to rely on get_current_dialog() as well. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=151#comment275 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.

13 years

PATCH: use correct to-tag in 302 redirects following early dialog creation

by Andrew Mortensen

Hi all. We've recently been experimenting with 302 redirects as the vehicle for call-forwarding, and ran into an issue with call-forward no answer. A small patch against (see below) fixed things. Caller and callee are Polycom 550s. The caller sends an INVITE to the callee, and the callee returns a 180 with a to-tag, establishing an early dialog. When sip-router's fr_inv_timer fires and sends the fake 408 reply to the INVITE, we handle enter the failure route and redirect to the forwarding address: # ... set URI to forwarded target here ... t_reply("302", "Call Forwarded"); exit; This should have worked, but in our testing the caller would completely ignore the 302. I tracked it down to sip-router returning a new to-tag in the 302, not the to-tag used in the early dialog. The Polycoms were evidently rejecting the 302 from sip-router as not matching any known dialog because of the unrecognized to-tag. [1] My patch simply stores forwarded to-tags for early dialogs, making the winning to-tag available for the 302 reply. We've tested it with 3.0.3; the patch below is against git head. I'm happy to revise it to get it into acceptable form. Please let me know. Best, andrew [1] Oddly, our Cisco gateways don't care about the new to-tag from sip-router, and will happily redirect regardless of the tag value in the 302. Perhaps it's the result of a looser interpretation of RFC 3261 12.1 and 12.3.

13 years

[tracker] Task opened: t_reply 302 redirects use wrong to-tag after fr_inv_timer fires (Attachment added)

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 - Andrew Mortensen (admorten) Attached to Project - sip-router Summary - t_reply 302 redirects use wrong to-tag after fr_inv_timer fires Task Type - Bug Report Category - tm Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Medium Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - If the failure route is armed and a call's fr_inv_timer fires following a 180 with to-tag from the callee, invoking t_reply("302", "Redirect") from the failure route does not use the to-tag from the callee. Instead, sip-router generates a new to-tag and attaches that to the 302 response. Our Polycom handsets then ignore the 302 because the to-tag does not match the to-tag it already received in the 180 from the callee. (Oddly, our Cisco gateways will happily redirect regardless of the unexpected to-tag in the 302. I suspect it has to do with a different reading of RFC3261 12.1 and 12.3.) The attached patch stores the early dialog's to-tag in t->fwded_totags, and passes the winning to-tag into build_res_buf_from_sip_req in the _reply() routine. This ensures the correct to-tag is part of the final response, so the UAC considers it an in-dialog response, and redirects as instructed. One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=152 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.

13 years

[tracker] Assignee added: t_reply 302 redirects use wrong to-tag after fr_inv_timer fires

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#152 - t_reply 302 redirects use wrong to-tag after fr_inv_timer fires User who did this - Andrew Mortensen (admorten) http://sip-router.org/tracker/index.php?do=details&task_id=152 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.

13 years

[tracker] Task opened: dialog flags in onreply route

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 - Jasmin Schnatterbeck (jasmin) Attached to Project - sip-router Summary - dialog flags in onreply route Task Type - Improvement Category - dialog Status - Assigned Assigned To - Timo Reimann Operating System - All Severity - Medium Priority - Normal Reported Version - 3.1 Due in Version - Undecided Due Date - Undecided Details - In 3.1/3.2 dialog flags are not available in onreply route and failure route. If it is possible to access dialog flags in those routes, that will be very useful. Thanks for any improvements! Jasmin More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=151 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.

13 years

[tracker] Assignee added: dialog flags in onreply route

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#151 - dialog flags in onreply route User who did this - Jasmin Schnatterbeck (jasmin) http://sip-router.org/tracker/index.php?do=details&task_id=151 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.

13 years

Developing kamailio module - Forking issue

by Luis Martin Gil

Hello, This is Luis Martin. I am developing a new module for Kamailio. This module will include some functions which will allow Kamailio to connect to another servers and retrieve information. I'm thinking on creating a couple of child from my main function, each child will execute a query to an specific server. I read this file "doc/modules_init.txt", but I'm having some troubles and I would appreciate if you could please help me with this. This is the how the the first draft of the forking code looks like: http://pastebin.com/MLXDN9p9 I call the "mod_child" function from my function like this: int myFunction () { (...) mod_child(randomNUMBER); (...) } But nothing happens, neither during the compilation process, nor the execution. Nothing is printed on the logs. Can you please point me out any suggestion or example? - How I am supposed to call the "mod_child()" function? - Which should be the rank_number: PROC_MAIN? - How I am supposed to cal the "mod_init()" function? - Again, could you please provide my any example? Thanks a lot. Best, Luis Martin

13 years

← Newer
1
...
11
12
13
14
15
16
17
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev September 2011