Hi Russel,

your assumption „ that the isc_match_filter should re-run through all of the iFCs” in case of a re-INVITE is not correct.

iFCs (initial filter criteria) are only invoked for initial or standalone request. A re-INVITE is a request within a dialog and therefore not initial.

BR Franz

From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Russell McConnachie Sent: Thursday, January 14, 2016 7:19 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: [SR-Users] IMS terminating dialog does not re-run through all iFCs after calling t_newtran()

Hi,

My CSCF environment has an application server acting as a B2BUA. It's originating a new session, and creating a new terminating session back to the S-CSCF (two separate sessions per-call). When I perform a re-INVITE with a diversion to transfer the call to another URI it is all good until the S-CSCF attempts to call the call control logic:

# Start new transaction:

t_newtran();

if (isc_match_filter("orig", "location")) {

t_on_failure("ISC_ORIG_FAILURE");

exit;

The t_newtran() method from what I understand will create a new transaction. Inside of this new transaction, I would think that the isc_match_filter should re-run through all of the iFCs defined on the HSS service profile, but it does not seem to be doing so. It seems to be continuing at where the original transaction ISC mark skip point was set.

Thanks