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.
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.
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
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.
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.
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.
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.
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.
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.
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