Hello, As you will see I have merged my branch back into master.
These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry.
The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } }
Any bugs, memory leaks etc. let me know!
Hugh
Hugh Waite writes:
These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction.
so it is not possible to explicitly activate this, e.g., by calling a new function t_on_branch_failure()?
if not, then i guess i need to set a branch flag and then test it in the event route to find out if i need to do something in the event route, which adds overhead to every transaction.
-- juha
See my and Daniel's response to Olle's query. I did not realise this was possible for event_routes and I'll try to add this back in as soon as I can.
Hugh
On 06/04/2013 06:04, Juha Heinanen wrote:
Hugh Waite writes:
These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction.
so it is not possible to explicitly activate this, e.g., by calling a new function t_on_branch_failure()?
if not, then i guess i need to set a branch flag and then test it in the event route to find out if i need to do something in the event route, which adds overhead to every transaction.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hugh Waite writes:
A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry.
since ruid is unique id, why is second argument ($tu in the the example) needed in unregister call:
if (!unregister("location", "$tu", "$T_reply_ruid"))
-- juha
Hi Juha,
On 06/04/2013 06:39, Juha Heinanen wrote:
Hugh Waite writes:
A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry.
since ruid is unique id, why is second argument ($tu in the the example) needed in unregister call:
This function had already been implemented so I used it to create a solution quickly.
The usrloc tables are indexed on the hash of the AoR, so one is needed to find the correct entry. When functions like save() are called without a URI the To is used by default. Perhaps a new function: unregister_ruid(<table>, <ruid>, [<URI>]) would be a cleaner solution. The optional URI is needed for when the AoR is different from the To.
Regards, Hugh
if (!unregister("location", "$tu", "$T_reply_ruid"))-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 4/6/13 12:32 PM, Juha Heinanen wrote:
Hugh Waite writes:
The usrloc tables are indexed on the hash of the AoR, so one is needed to find the correct entry.
ok, but why cannot a new index on ruid field be created in which case unregister would not need uri (aor) or use argument at all?
keeping different indexes will add lot of complexity in synchronizing them on insert/update/delete, which can end up also in loss of performances. Other field that would need indexes are contact address, callid, path, if you look at the other types of lookups done in usrloc.
The aor is not necessary to be kept in order to locate the record, aorhash would be enough (which is unsigned int) along with ruid. Getting aorhash from aor is really fast, so keeping only the aor might be better in some situations when it is needed for other purposes.
Cheers, Daniel
hugh,
sometimes unregistering in event_route[tm:branch-failure] works fine, e.g.:
Apr 6 09:39:00 siika /usr/sbin/sip-proxy[21504]: INFO: event_route[tm:branch-failure] Apr 6 09:39:00 siika /usr/sbin/sip-proxy[21504]: INFO: Unregistering sip:test@test.fi with ruid <uloc-515fc1d4-53ff-2>
but sometimes looks like $T_reply_ruid is corrupted:
Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: INFO: event_route[tm:branch-failure] Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: INFO: Unregistering sip:test@test.fi with ruid <ulo` Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: WARNING: registrar [save.c:993]: AOR/Contact not found Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: WARNING: Failed to unregister sip:test@test.fi with ruid <ulo`
the piece of config file producing the above is:
if (t_check_status("(408|486)")) { xlog("L_INFO", "Unregistering <$avp(REQUEST_URI_AVP)> with ruid <$T_reply_ruid>\n"); if (!unregister("location", "$avp(REQUEST_URI_AVP)", "$T_reply_ruid")) { xlog("L_WARN", "Failed to unregister <$avp(REQUEST_URI_AVP)> with ruid <$T_reply_ruid>\n"); }; ...
i added 486 (busy) to t_check_status just to ease testing.
in usrloc table ruid field values are correct, i.e., there is no value "ulo`".
-- juha
Hi, I've fixed a bug in t_next_contacts where the ruid was not retrieved and put into the contact flows xavp. I don't know if that will help with this issue if you are not using multiple flows. I've also added the ruid to the append_branch debug in t_next_contacts which should show if it is corrupt before or after the request is sent.
Hugh
On 06/04/2013 07:45, Juha Heinanen wrote:
hugh,
sometimes unregistering in event_route[tm:branch-failure] works fine, e.g.:
Apr 6 09:39:00 siika /usr/sbin/sip-proxy[21504]: INFO: event_route[tm:branch-failure] Apr 6 09:39:00 siika /usr/sbin/sip-proxy[21504]: INFO: Unregistering sip:test@test.fi with ruid <uloc-515fc1d4-53ff-2>
but sometimes looks like $T_reply_ruid is corrupted:
Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: INFO: event_route[tm:branch-failure] Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: INFO: Unregistering sip:test@test.fi with ruid <ulo` Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: WARNING: registrar [save.c:993]: AOR/Contact not found Apr 6 09:39:06 siika /usr/sbin/sip-proxy[21533]: WARNING: Failed to unregister sip:test@test.fi with ruid <ulo`
the piece of config file producing the above is:
if (t_check_status("(408|486)")) { xlog("L_INFO", "Unregistering <$avp(REQUEST_URI_AVP)> with ruid <$T_reply_ruid>\n"); if (!unregister("location", "$avp(REQUEST_URI_AVP)", "$T_reply_ruid")) { xlog("L_WARN", "Failed to unregister <$avp(REQUEST_URI_AVP)> with ruid <$T_reply_ruid>\n"); }; ...i added 486 (busy) to t_check_status just to ease testing.
in usrloc table ruid field values are correct, i.e., there is no value "ulo`".
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hugh Waite writes:
I've fixed a bug in t_next_contacts where the ruid was not retrieved and put into the contact flows xavp. I don't know if that will help with this issue if you are not using multiple flows.
hugh,
the setup i'm testing is such where i have two proxies each serving as combined outbound proxy and registrar and having their own usrloc. i namely don't see any point in having separate proxies doing just outbound work.
if ua is outbound capable, it registers with both. if not, it registers with only one that saves the registration and forwards it with path to the other proxy, which also saves it.
i have now got the setup pretty much working. couple of things that are still missing: (1) t_branch_timeout() and t_branch_replied() in failure branch route that i need for proper implementation of unregister and (2) loose_route() return code improvement that i suggest in another email and that i'm planning to commit soon if no objections.
-- juha
forgot one thing. i need to look how hard it would be possible to favor instances without path in order to avoid the extra hop.
-- juha
I can see how implementing the branch failure route can handle the current message not being able to deliver to destination because the flow is broken and another flow exists. However, what about all subsequent in-dialog messages that follow the same route set? Will every subsequent message needs to go through the branch failure route to be routed properly?
-- View this message in context: http://sip-router.1086192.n5.nabble.com/Outbound-flow-failure-handling-merge... Sent from the Development mailing list archive at Nabble.com.
-
Daniel-Constantin Mierla -
Hugh Waite -
Juha Heinanen -
Robert