Hi Bogdan, Understood. Thanks again!
Mariana. On Wed, Jan 9, 2013 at 5:09 PM, Bogdan-Andrei Iancu <[email protected]>wrote: > ** > Hi Mariana, > > no, you do not need to create the INVITE trasaction in advance - do it as > usually : at the end, on t_relay(). Because if the INVITE transaction does > not exist (not yet relayed), the t_check_trans() for CANCEL will fail and > CANCEL will be dropped (not relayed). Only one of the following > retransmissions on the CANCEL will get relayed as soon as the INVITE > transaction is created. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > > On 01/09/2013 05:38 PM, Mariana Arduini wrote: > > 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
