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
