Hi,
The same happens sometimes with INVITE requests, if it takes to long the UA
might start retransmitting.
I solve this by sending a provisional reply right upon receiving the request
if (is_method("INVITE"))
{
sl_send_reply("100", "Trying -- your call is important to us");
}
And then use t_relay("0x01") to avoid duplicate 100-replies. This avoids
race-conditions, it might help in your case as well.
Regards,
Remco.
On Tue, Jan 8, 2013 at 9:49 PM, Mariana Arduini <[email protected]>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
