Hi Mariana,
If CANCEL hits opensips while the the INVITE is still under processing
(in a different process), the INVITE transaction will not exist yet (it
is created by t_relay), so the t_check_trans() will return false ->
script will exit without doing anything for the CANCEL - more or less
the CANCEL will be dropped without being replied or fwded. This will
force retransmission of Cancel -> buying more time to finish the
processing of the INVITE.
Hope this helped.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 01/08/2013 10:49 PM, Mariana Arduini wrote:
Hello all,
I hope somebody can give me a kind hint on what to do here.
We have this piece of code for CANCEL handling:
# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
t_relay();
}
exit;
}
What happens is sometimes we take too long to process the INVITE due
to some DB issues, and the UAC sends us a CANCEL before we relay the
INVITE.
We don´t use t_newtran() because of this big warning in docs saying
that "the changes on the request that are made after this function
call will not be saved into transaction!!!". We need to perform a lot
of changes in the requests and I understand this wouldn´t be possible
after calling t_newtran().
So our transaction is not created untill we relay the INVITE, which
means that any CANCEL received before that will be dropped.
We also tried testing the CANCEL messages we´re receiving in these
cases with has_totag() and loose_route(), but they won´t pass as well.
Is there any way to verify a CANCEL message in this scenario and relay
it in case is belongs to a valid transaction?
Any help will be much appreciated.
Regards,
Mariana.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
