Hi Juha and others!
I wonder if I understand load/next_contacts(). If I understand it right it can be used for example to make parallel/serial forking after an ENUM lookup (multiple NAPTRs).
I think this is the correct usage:
if (enum_query()) { if (load_contacts()) { if (next_contacts()) { t_on_failure("1"); t_relay(); } else { sl_reply("500","error adding contacts"); } } else { sl_reply("500","error fetching destination set"); } exit; }
But I wonder what if all the branches after enum_query() have the same q value. According to the README: load_contact: If all contacts in the destination set have the same qvalue, load_contacts() does not do anything thus minimizing performance impact of sequential forking capability when it is not needed. Returns 1 if loading of contacts succeeded or there was nothing to do.
Thus, next_contacts() will be called although there are no AVPs to fetch. Do I miss something here?
regards klaus
Klaus Darilion writes:
But I wonder what if all the branches after enum_query() have the same q value. According to the README: load_contact: If all contacts in the destination set have the same qvalue, load_contacts() does not do anything thus minimizing performance impact of sequential forking capability when it is not needed. Returns 1 if loading of contacts succeeded or there was nothing to do.
Thus, next_contacts() will be called although there are no AVPs to fetch. Do I miss something here?
klaus.
i don't think you miss anything. if all contacts have same q value, load_contacts() does not do anything and does not add anything to the avp. when next_contacts() is then called, it, in turn. does not do anything because there is no avp values.
but this part of your script does not work
if (load_contacts()) { if (next_contacts()) { t_on_failure("1"); t_relay();
if t_relay fails, for example, due to tcp connect failure to the first contact. your failure route will never get called and no other contacts even if they exist, will never be tried.
i personally think this is a major problem with current t_relay implementation. i my opinion, failure route should be called also in case of internally generated negative replies.
-- juha
Juha Heinanen schrieb:
Klaus Darilion writes:
But I wonder what if all the branches after enum_query() have the same q value. According to the README: load_contact: If all contacts in the destination set have the same qvalue, load_contacts() does not do anything thus minimizing performance impact of sequential forking capability when it is not needed. Returns 1 if loading of contacts succeeded or there was nothing to do.
Thus, next_contacts() will be called although there are no AVPs to fetch. Do I miss something here?
klaus.
i don't think you miss anything. if all contacts have same q value, load_contacts() does not do anything and does not add anything to the avp. when next_contacts() is then called, it, in turn. does not do anything because there is no avp values.
Ok. I missed that next_contact have different return value on no AVPs depending on request_route or failure_route. This is fine, as long as the first usage is in a request route. If the load_contacts happens in a failure route, this can cause problems.
if t_relay fails, for example, due to tcp connect failure to the first contact. your failure route will never get called and no other contacts even if they exist, will never be tried.
i personally think this is a major problem with current t_relay implementation. i my opinion, failure route should be called also in case of internally generated negative replies.
Yes. I read your other emails. I always thought this was solved with the t_relay("2") flag, but obviously not.
regards klaus
-
jh＠tutpro.com -
Klaus Darilion