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(a)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