THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - oren avraham (orenav)
Attached to Project - sip-router
Summary - Problem with SUBSCRIBE presence status on WEBSOCKET protocol
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - on version 4.0.0
I was tring to subscribe PRESENCE status with a WEBSOCKET user agent (a js library)
and got the following error messages:
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: : <core> [dns_cache.c:2746]: BUG: sip_resolvehost: unknown proto 5
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: <core> [resolve.c:1727]: ERROR: sip_hostport2su: could not resolve hostname: "df7jal23ls0d.invalid"
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: tm [ut.h:337]: failed to resolve "df7jal23ls0d.invalid"
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: tm [uac.c:266]: t_uac: no socket found
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: presence [notify.c:1591]: in function tmb.t_request_within
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: presence [notify.c:1678]: sending Notify not successful
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: presence [subscribe.c:678]: Could not send notify
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: presence [subscribe.c:713]: occured
Mar 17 01:57:47 oren-ubuntu /usr/sbin/kamailio[1963]: ERROR: presence [subscribe.c:994]: in update_subscription
It seems the dns_cache doesn't familiar with WS PROTO, and it seems there are more problems with it.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=276
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.
Module: sip-router
Branch: 4.0
Commit: e446aa58a89c60ef9449fc8f79492232c7ed6f7f
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e446aa5…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat Mar 16 06:33:13 2013 +0200
modules/registrar: outbound_mode=1 fix
outbound_mode=1 now accepts REGISTER requests that either contain
or do not contain a Supported: outbound header.
a Supported: outbound header is always added to 200 OK reply and if
request contained a Supported: outbound header, also a Require: outbound
header is added.
---
modules/registrar/doc/registrar_admin.xml | 14 +++++++++-----
modules/registrar/reply.c | 13 ++++++++++---
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/modules/registrar/doc/registrar_admin.xml b/modules/registrar/doc/registrar_admin.xml
index 47e52d5..cb55218 100644
--- a/modules/registrar/doc/registrar_admin.xml
+++ b/modules/registrar/doc/registrar_admin.xml
@@ -731,11 +731,15 @@ modparam("registrar", "gruu_enabled", 0)
with the outbound options tag.
</para>
<para>
- If set to 1 then this module will accept REGISTER requests
- that do not contain a Supported: header with the outbound
- options-tag. The 200 OK response to REGISTER requests that this
- module generates will contain a Supported: header with the
- outbound options tag.
+ If set to 1 this module will accept REGISTER requests that do
+ not contain a Supported: header with the outbound options-tag
+ and REGISTER requests that do contain a Supported: or a
+ Requires: header with the outbound options-tag. The 200 OK
+ response that this module generates, will contain a Supported:
+ header with the outbound options tag. The 200 OK response
+ will also contain a Require: header with the outbound options
+ tag if the REGISTER request contained a Supported:
+ header with the outbound options-tag.
</para>
<para>
If set to 2 then this module will reject REGISTER requests
diff --git a/modules/registrar/reply.c b/modules/registrar/reply.c
index 5903710..7ed2a05 100644
--- a/modules/registrar/reply.c
+++ b/modules/registrar/reply.c
@@ -658,11 +658,18 @@ int reg_send_reply(struct sip_msg* _m)
if (add_flow_timer(_m) < 0)
return -1;
}
- /* Fall-thru */
- case REG_OUTBOUND_SUPPORTED:
if (add_supported(_m, &outbound_str) < 0)
- return -1;
+ return -1;
break;
+ case REG_OUTBOUND_SUPPORTED:
+ if ((parse_supported(_m) == 0) &&
+ (((struct supported_body *)_m->supported->parsed)->supported_all & F_SUPPORTED_OUTBOUND)) {
+ if (add_require(_m, &outbound_str) < 0)
+ return -1;
+ }
+ if (add_supported(_m, &outbound_str) < 0)
+ return -1;
+ break;
}
break;
case R_OB_UNSUP:
Hello,
I have been researching the work needed to implement forking of outbound
flows based on the discussions by Peter, Olle and others on this list.
I suggest the following:
A new route type "branch_failure_route" which can be called on a failure
response for every branch created.
Change t_next_contact_flows() so that it can only be called from the
branch_failure route.
Modify t_next_contact_flows() so that it will search the xavp of
alternative flows and select the next instance that matches the failed
instance. This will create another branch.
t_relay() can be used in the branch_failure route to fork to the new branch.
There will be a few more functions that can be called in the
branch_failure route, including unregister_contact().
If no new flows are available, the response is passed on to be handled
by the failure route handler. If a new flow is available, and a branch
created, the failure response must not be passed on. A response from the
new branch, plus all other branches must be received before the failure
route is called with the best response.
If the failure route is called, t_next_contacts() can be called to
implement serial forking based on q-value, as before.
Any comments before I start work?
Hugh
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
Hi,
I've noticed that the config file parser allows for un-named branch and
failure routes (see failure_route_stm and branch_route_stm in cfg.y)
The core cookbook says that these routes are only run when armed with
t_on_failure/t_on_branch, and a quick test confirms that.
Should default failure and branch routes be removed from cfg.y?
Hugh
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.