Hi Remco, We´re actually doing it already, but we didn´t know how to avoid the duplicate 100-replies. Thanks for the hint!
Regards, Mariana. On Wed, Jan 9, 2013 at 6:19 PM, Remco . <[email protected]> wrote: > 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 > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
