sr-dev

sr-dev@lists.kamailio.org

15 participants
44239 discussions

Start a nNew thread

[tracker] Task opened: Makefile error prevent tls module from being build

by sip-router

15 years, 4 months

[tracker] Assignee added: Makefile error prevent tls module from being build

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#17 - Makefile error prevent tls module from being build User who did this - Nils Ohlmeier (nils) http://sip-router.org/tracker/index.php?do=details&task_id=17 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.

15 years, 4 months

[tracker] Comment added: TLS modul problem

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#14 - TLS modul problem User who did this - Nils Ohlmeier (nils) ---------- I saw the same log message several times as well when I tested TLS support at the SIPit. But I did not debugged the issue that far. In my case I saw additionally saw that SER tried to open a connection from an IP address which is wasn't listening on (it was configured to use an alias IP only, but according to the logs for new TLS connections it used the IP address of the real interface to which the alias IP belonged). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=14#comment6 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.

15 years, 4 months

[tracker] Task opened: Local 487 forwarded upstream (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 - Nils Ohlmeier (nils) Attached to Project - sip-router Summary - Local 487 forwarded upstream Task Type - Bug Report Category - tm Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - Mac OS X (Darwin) Severity - High Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Setup: - INVITE gets forked to three destinations - branch one answers the call - the two remaining branches are canceled locally - branch two gets canceled normally - branch three answers only the CANCEL request - meanwhile the call is setup and even teared down - finally branch three sends a 487 - tm module does not match the transaction and forwards the 487 upstream Note: the setup included the new topoh module, but that should hopefully does not make any difference. Please find attached a log file on debug level from the scenario described above. 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=16 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.

15 years, 4 months

[tracker] Assignee added: Local 487 forwarded upstream

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#16 - Local 487 forwarded upstream User who did this - Nils Ohlmeier (nils) http://sip-router.org/tracker/index.php?do=details&task_id=16 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.

15 years, 4 months

[tracker] Task opened: Proto names are causing parser errors

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 - Nils Ohlmeier (nils) Attached to Project - sip-router Summary - Proto names are causing parser errors Task Type - Bug Report Category - Core 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 - When the configuration file contains a statement like this: if (proto==TCP) { this is causing a parser errors at the startup of SER like this: 0(26225) : <core> [cfg.y:3163]: parse error in config file /home/lando/sip-router/etc/sip-router-basic.cfg, line 76, column 13-15: syntax error 0(26225) : <core> [cfg.y:3163]: parse error in config file /home/lando/sip-router/etc/sip-router-basic.cfg, line 76, column 13-15: number expected 0(26225) : <core> [cfg.y:3166]: parse error in config file /home/lando/sip-router/etc/sip-router-basic.cfg, line 76, column 16: bad expression 0(26225) : <core> [cfg.y:3166]: parse error in config file /home/lando/sip-router/etc/sip-router-basic.cfg, line 76, column 16: invalid route statement Currently only statements like this are working: if (proto==2) { More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=15 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.

15 years, 4 months

[tracker] Assignee added: Proto names are causing parser errors

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#15 - Proto names are causing parser errors User who did this - Nils Ohlmeier (nils) http://sip-router.org/tracker/index.php?do=details&task_id=15 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.

15 years, 4 months

[LCR] next_gw() doesn't update $ru

by Iñaki Baz Castillo

Hi, in failure route I call next_gw(), it success and the request is sent to a second gateway (inspecting with ngrep I see that the sent request has the gw IP as RURI). But if I print (xlog) $ru it still shows the previously selected gw (the first one). This is, the behaviour is correct but $ru is not updated in the script process. I show an example which hopefully would show the issue (xlogs). Basically the script invokes ROUTE_GW which uses LCR to select the first gw, sets FAILURE_ROUTE_GW and calls ROUTE_DEFAULT (in which t_relay is done). FAILURE_ROUTE block also sets FAILURE_ROUTE block, uses LCR to select a new gw and calls to ROUTE_DEFAULT: INVITE sip:1234@sip.mydomain.org - From: ibc - from 222.230.253.254:48254 (Twinkle/1.4.2) [ROUTE GW] LCR: Selected gw ($rd): 222.230.249.81 [ROUTE DEFAULT] $ru = sip:1234@222.230.249.81:0 <---- Seems to be OK 500 "Internal Error" from 222.230.249.81:5060 (GW1) [FAILURE ROUTE GW] CRITICAL: LCR: 500 replied by gw 222.230.249.81 --> Doing failover... [FAILURE ROUTE GW] Selected gw ($rd): 222.230.249.81 <----- WRONG !!! [ROUTE DEFAULT] $ru = sip:1234@222.230.249.81:0 <----- WRONG !!! 503 "Service Unavailable" from 99.121.79.216:5060 (GW2) <----- But the used gw is the expected. [FAILURE ROUTE GW] CRITICAL: LCR: 503 replied by gw 99.121.79.216 --> Doing failover... [FAILURE ROUTE GW] CRITICAL: LCR: No gateways available --> 503 Kamailio 1.5 rev 5925. -- Iñaki Baz Castillo <ibc(a)aliax.net>

15 years, 4 months

siprouter.org domain

by Greger Viken Teigre

I just realized today that I have the siprouter.org domain (for pre-historic reasons that I don't even remember). It didn't even have proper DNS, but I have set that up and pointed www. to the same ip as www (but the server does not recognize the siprouter.org domain). Or maybe I should use CNAME? Who is the keeper of DNS for sip-router.org? Let's sync up so at least siprouter.org redirects correctly the most important addresses. g-)

15 years, 4 months

git:master: xmlrpc doc: use set_reply_close()

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: b2ba3a96b33e4bac14a9de6b615665af9f598c78 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b2ba3a9… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Fri Sep 18 23:56:08 2009 +0200 xmlrpc doc: use set_reply_close() Updated doc & examples to use set_reply_close() and set_reply_no_connect() in the XMLRPC route instead of return -1. (this allows using rpc async commands with the broken python xmlrpclib). --- modules_s/xmlrpc/README | 19 ++++++++++++++++--- modules_s/xmlrpc/doc/functions.xml | 6 ++++++ modules_s/xmlrpc/doc/xmlrpc.xml | 14 +++++++++++--- 3 files changed, 33 insertions(+), 6 deletions(-) diff --git a/modules_s/xmlrpc/README b/modules_s/xmlrpc/README index b497e66..d1abb54 100644 --- a/modules_s/xmlrpc/README +++ b/modules_s/xmlrpc/README @@ -456,14 +456,21 @@ Content-Length: 276 xmlrpclib with a Transport class that works. For the second solution (force closing tcp connections after answering) - the XMLRPC route should end with a return -1, exit -1 or drop -1. + the XMLRPC route should have a set_reply_close() command before + dispatch_rpc(). set_reply_no_connect() is also recommended (avoid + trying to open tcp connection to xmlrpc clients that closed it). + Alternatively ending the XMLRPC route with return -1, exit -1 or drop + -1 can also be used, but note that this will not work for async rpcs + (it will close the connection immeidately and not on the async + response). Example 1. route[XMLRPC]{ - dispatch_rpc(); # close connection only for xmlrpclib user agents if search("^User-Agent:.*xmlrpclib")) - return -1 ; + set_reply_close(); + set_reply_no_connect(); # optional + dispatch_rpc(); } 1.4. Client Examples @@ -543,6 +550,9 @@ modparam("xmlrpc", "autoconversion", 1) modparam("xmlrpc", "route", "XMLRPC"); #... route[XMLRPC]{ + if search("^User-Agent:.*xmlrpclib")) + set_reply_close(); + set_reply_no_connect(); # optional dispatch_rpc(); } @@ -566,5 +576,8 @@ route[XMLRPC]{ xmlrpc_reply("400", "Unauthorized"); return; } + if search("^User-Agent:.*xmlrpclib")) + set_reply_close(); + set_reply_no_connect(); # optional dispatch_rpc(); } diff --git a/modules_s/xmlrpc/doc/functions.xml b/modules_s/xmlrpc/doc/functions.xml index bc3820f..adacbac 100644 --- a/modules_s/xmlrpc/doc/functions.xml +++ b/modules_s/xmlrpc/doc/functions.xml @@ -43,6 +43,9 @@ modparam("xmlrpc", "route", "XMLRPC"); #... route[XMLRPC]{ + if search("^User-Agent:.*xmlrpclib")) + set_reply_close(); + set_reply_no_connect(); # optional dispatch_rpc(); } </programlisting> @@ -74,6 +77,9 @@ route[XMLRPC]{ xmlrpc_reply("400", "Unauthorized"); return; } + if search("^User-Agent:.*xmlrpclib")) + set_reply_close(); + set_reply_no_connect(); # optional dispatch_rpc(); } </programlisting> diff --git a/modules_s/xmlrpc/doc/xmlrpc.xml b/modules_s/xmlrpc/doc/xmlrpc.xml index c893e97..2cdf422 100644 --- a/modules_s/xmlrpc/doc/xmlrpc.xml +++ b/modules_s/xmlrpc/doc/xmlrpc.xml @@ -677,15 +677,23 @@ Content-Length: 276 </para> <para> For the second solution (force closing tcp connections after answering) - the XMLRPC route should end with a return -1, exit -1 or drop -1. + the XMLRPC route should have a <function>set_reply_close()</function> + command before <function>dispatch_rpc()</function>. + <function>set_reply_no_connect()</function> is also recommended + (avoid trying to open tcp connection to xmlrpc clients that closed it). + Alternatively ending the XMLRPC route with return -1, exit -1 or + drop -1 can also be used, but note that this will not work for + async rpcs (it will close the connection immeidately and not on the + async response). <example> <programlisting> <![CDATA[ route[XMLRPC]{ - dispatch_rpc(); # close connection only for xmlrpclib user agents if search("^User-Agent:.*xmlrpclib")) - return -1 ; + set_reply_close(); + set_reply_no_connect(); # optional + dispatch_rpc(); } ]]> </programlisting>

15 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev