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 Developer
http://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] <mailto:[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 Developer
http://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] <mailto:[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 Developer
http://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 list
[email protected] <mailto:[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
