Hello,
It seems that current implementation of the listed modules has a bug in the
"agregate_xmls" function in the "notify_body.c" files. Current implementation is
"allowing" a single event entry in the XML body of the NOTIFY messages only.
This is caused by "unlinking the XML node" in the for loop "for (node =
p_root->children; node; node = node->next) {". After unlinking it cannot point
to another node. Therefore, it will never enter the aggregation loop again and
stop adding XML childs.... That´s the reason why we have the problem that DB
"body" entries of the presentity table, which include more than one event entry
(e.g. dialog), cannot be fully added to SIP NOTIFY messages. It is always
inserting the first event entry only.
We have tested a workaround with up to three (3) dialog entries (with module
presence_dialoginfo) in a single message body. This is working fine!
According RFC4235 it is allowed using more than onle dialog entry in a single
message body. Therefore, I´d like to ask, if the current behaviour can be seen
as "bug" or not?
regards,
Klaus
as per daniel's suggestion, i wrote a new tmx function t_reuse_branch(),
which can currently be called from branch-failure route:
/**
* Creates new "main" branch by making copy of branch-failure branch.
* Currently the following branch attributes are included:
* request-uri, ruid, path, instance, and branch flags.
*/
static int w_t_reuse_branch(struct sip_msg* msg, char *p1, char *p2)
{
struct cell *t;
int branch;
if (msg == NULL) return -1;
/* first get the transaction */
if (_tmx_tmb.t_check(msg, 0) == -1) return -1;
if ((t = _tmx_tmb.t_gett()) == 0) {
LM_ERR("no transaction\n");
return -1;
}
switch (get_route_type()) {
case BRANCH_FAILURE_ROUTE:
/* use the reason of the winning reply */
if ((branch = _tmx_tmb.t_get_picked_branch()) < 0) {
LM_CRIT("no picked branch (%d) for a final response"
" in MODE_ONFAILURE\n", branch);
return -1;
}
rewrite_uri(msg, &(t->uac[branch].uri));
set_ruid(msg, &(t->uac[branch].ruid));
if (t->uac[branch].path.len) {
set_path_vector(msg, &(t->uac[branch].path));
} else {
reset_path_vector(msg);
}
setbflagsval(0, t->uac[branch].flags);
set_instance(msg, &(t->uac[branch].instance));
return 1;
default:
LM_ERR("unsupported route_type %d\n", get_route_type());
return -1;
}
}
the new "main" branch does not include destination uri and socket,
because i didn't find them in struct ua_client. unless someone adds
them to struct ua_clients, they thus need to be set separately from
htable after calling t_reuse_branch().
is it ok that i commit the above function to tmx module?
in addition, i would like to add $T_reply_bf (branch flags) pv, since i
need to test some of the branch flags in other parts of branch-failure
route.
-- juha
I have an edge-proxy which accepts TCP connections from clients. When I know that the clients are behind NATs (for example), I use the set_forward_no_connect() function to force connection reuse and avoid timeouts. In the case where the connection has already gone, the system sends a "477 Unfortunately error on sending to next hop occurred (477/TM)" response back to the registrar.
These connections are using outbound, so I would like to convert this into a "430 Flow Failed" response to the registrar, but the 477 response doesn't seem to trigger the onreply_route or failure_route.
Is there a way of trapping and handling this failure? If not, do we need more flexibility in handling this particular tcp_send error (or other similar ones)? Other systems may wish to try additional destinations from the failure route.
Snippets of my cfg and logs are below. The con_reuse flag is checked in tcp_send at tcp_main.c:1846
Regards,
Hugh
route[RELAY] {
xlog("L_INFO", "$rm: route[RELAY]\n");
loose_route();
$var(lr_ret) = $rc;
if ($var(lr_ret) == 2) {
xlog("L_INFO", "$rm: loose route with outbound\n");
t_on_failure("FAIL_OUTBOUND");
set_forward_no_connect();
if (t_relay() < 0) {
xlog("L_WARN", "$rm: loose route with outbound failed\n");
sl_send_reply("500", "Something bad happened");
}
exit;
}
. . .
}
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: INVITE: Routing logic starts here
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: INVITE: route[REQINIT]
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: INVITE: route[INITIAL_REQUEST]
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: INVITE: route[RECORD_ROUTE]
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: INVITE: route[RELAY]
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: INVITE: loose route with outbound
May 1 17:01:08 kamailio-cep[28226]: ERROR: tm [../../forward.h:219]: msg_send(): msg_send: ERROR: tcp_send failed
May 1 17:01:08 kamailio-cep[28226]: ERROR: tm [t_fwd.c:1609]: t_send_branch(): ERROR: t_send_branch: sending request on branch 0 failed
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: ACK: Routing logic starts here
May 1 17:01:08 kamailio-cep[28226]: INFO: <script>: ACK: route[REQINIT]
________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
This is probably due to changes in perl.
The docs for app_perl use sl_send_reply() and xlog() as examples for the
explicit and implicit Kamailio::moduleFunction() methods.
Neither work.
For sl_send_reply, one gets errors of the form:
ERROR: app_perl [kamailioxs.xs:255]: moduleFunc(): function 'sl_send_reply' \
called, but not available.
ERROR: app_perl [kamailioxs.xs:978]: XS_Kamailio__Message_moduleFunction(): \
calling module function 'sl_send_reply' failed. Missing loadmodule?
even though the modules is loaded and sl_send_reply works fine in the .cfg.
Xlog, OTOH, generates:
ERROR: app_perl [kamailioxs.xs:280]: moduleFunc (): Module function 'xlog' \
is unsafe. Call is refused.
ERROR: app_perl [kamailioxs.xs:978]: XS_Kamailio__Message_moduleFunction(): \
calling module function 'xlog' failed. Missing loadmodule?
Removing «use strict» from the script does not prevent the «is unsafe» error.
Using Kamailio::log() works, albeit with superfluous verbosity.
-JimC
--
James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#426 - DNS SRV lookup in rewritehost port fails
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Fixed
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=426
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.