5 Apr
2013
5 Apr
'13
11:40 a.m.
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
Principal Design Engineer
Crocodile RCS Ltd.
6 Apr
6 Apr
7:04 a.m.
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
8:48 p.m.
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:
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
7:39 a.m.
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
12:27 p.m.
Hi Juha,
On 06/04/2013 06:39, Juha Heinanen wrote:
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
Hugh Waite writes:
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
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 
12:58 p.m.
On 4/6/13 12:32 PM, Juha Heinanen wrote:
Hugh Waite writes:
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
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?
8:45 a.m.
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
9 Apr
9 Apr
1 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
1:39 p.m.
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
1:43 p.m.
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
23 Nov
23 Nov
6:35 p.m.
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-merg…
Sent from the Development mailing list archive at Nabble.com.
2705
days inactive
4033
days old
11 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Hugh Waite -
Juha Heinanen -
Robert