Hi Bogdan, So I understand that the only way to recognize the transaction of a CANCEL message received before relaying the INVITE is to create the transaction using t_newtran() just after receiving the INVITE, but this would affect some of our features.
In this case, we´ll have to work on the time our server is taking to process the INVITE and make sure it won´t be stuck for too long waiting for a DB query or something. Thanks again for the kind help! Regards, Mariana. On Wed, Jan 9, 2013 at 11:29 AM, Bogdan-Andrei Iancu <[email protected]>wrote: > ** > Hi Mariana, > > According to RFC3261, the CANCEL processing (as cancelling the call) is > not up to a proxy, but up to the end devices. So a proxy has to simply > relay all received info (INVITE and CANCEL) - it cannot terminate the call > by itself. > > So you have to relay both INVITE and CANCEL and let the end device to > reject the call. > > Regarding Flavio's suggestion - that function (as name says) solves the > problem only for the flags, but not for changes as headers or SDP, AVPS, > etc. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 01/09/2013 02:31 PM, Mariana Arduini wrote: > > Hi All! > > Thank you both for the hints and explanation. > > The retransmission of CANCEL messages would for sure be really helpful, > but we´d like to be able to handle cases where processing the INVITE takes > too long. If introducing some huge delays in INVITE processing, OpenSIPS > will relay it when the processing finally ends, but UAC had already > canceled it, so UAS picks a dead call up. > > Flavio´s suggestion looks interesting. I´m just wondering if > t_flush_flags() would update all kind of changes in the SIP message. We > perform lots of translations in headers and SDP and not applying any of > them would totally mess everything up. Any idea of limitations? > > I begin to think that including timeouts during INVITE processing with > smaller values than the previous hop fr_inv would be less risky. I´d like > to hear your oppinions. > > Thanks again for the help! > > Regards, > Mariana. > > > > On Wed, Jan 9, 2013 at 9:54 AM, Bogdan-Andrei Iancu > <[email protected]>wrote: > >> 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 Developerhttp://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 >> [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
