Thanks Bogdan. Appreciate your followup. So let me put the question this way:
What is the benefit of creating a new transaction on top of the retrans checks? Why would I not just want to wait until I call t_relay(), which will also create a transaction if it does not already exist. Why it would be beneficial to have it exist beforehand?It seems that retransmission detection works the same way regardless. -- Sent from mobile device On Jul 16, 2009, at 11:54 AM, Bogdan-Andrei Iancu <[email protected] > wrote: > Hi Alex, > > No, t_check_trans() will NOT create a new transaction. Both function > will check (for non-ACK and non-CANCEL) if it is retransmission and > if so, it will sent (via TM) the last sent reply and stop the script > exectution. If it is not a retransmission, t_check_trans() will not > do anything else, but t_newtran() will create a new transaction. > > I added this function in 1.0 (?!?) as it was mainly intended for > proper CANCEL and ACK routing. > > Regards, > Bogdan > > Alex Balashov wrote: >> Bogdan, >> >> Are you saying that t_check_trans() will create a new transaction >> for a non-ACK/CANCEL retransmission too? Or that it retransmits >> the last reply sent "statelessly" somehow? >> >> -- >> Sent from mobile device >> >> On Jul 14, 2009, at 9:10 AM, Bogdan-Andrei Iancu <[email protected] >> > wrote: >> >>> Hi Stan, >>> >>> when comes to handling retransmissions (and not CANCELs and ACKs >>> belonging to an INVITE transaction), both function do more or less >>> the >>> same - handle the retransmission (by retransmitting the last sent >>> reply) >>> and breaking the script execution - of course, the difference is >>> if no >>> retransmission, t_newtran() will create a new transaction for the >>> request. >>> >>> So : >>> >>> t_check_trans(); >>> t_new_trans(); >>> >>> >>> is a bit redundant. Only: >>> >>> t_new_trans(); >>> >>> >>> will do exactly the same job. >>> >>> Again, this is true only in the context of non-CANCEL and non-ACK >>> requests! >>> >>> Regards, >>> Bogdan >>> >>> Stanisław Pitucha wrote: >>>> 2009/7/14 Alex Balashov <[email protected]>: >>>> >>>>> http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id272150 >>>>> >>>> >>>> A bit related question. Since the docs mention: >>>> "If the processing of requests may take long time (e.g. DB lookups) >>>> and the retransmission arrives before t_relay() is called, you >>>> can use >>>> the t_newtran() function to manually create a transaction." >>>> >>>> Is there any situation where: >>>> >>>> t_check_trans(); >>>> t_new_trans(); >>>> >>>> after all cancel / ack checks is a bad thing to do? Or maybe even: >>>> >>>> t_check_trans(); >>>> if (is_method('INVITE|UPDATE|REFER')) t_new_trans(); >>>> >>>> since everything else can be safely duplicated / is rather light >>>> in processing. >>>> >>>> _______________________________________________ >>>> 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
