[OpenSIPS-Users] CANCELing transactions while perl_exec() running

[Bogdan-Andrei Iancu]

Hi Alex,

when using UDP, dropping UDP is not a problem (as long as you do not 
send anything back to UAC) - if no reply is received by UAC (for the 
CANCEL), the UAC will simply retransmit the CANCEL - this is the 
standard SIP RFC3261 behaviour, so nothing gets broken.

It is not possible to stop the execution of the script as this happens 
in a different process. The processing of INVITE and CANCEL takes place 
in parallel and it is not possible to cross communicate.

Regards,
Bogdan

Alex Massover wrote:
>
> Hi Bogdan!
>
> You wrote: " Not sure where the problem is. if your script is still 
> running, it means
>
> your opensips hasn't yet sent any INVITE out, so nothing is to be
>
> cancelled - so the received CANCELs are dropped."
>
> This is exactly what I want to avoid – dropping CANCELs. From UAC 
> point of view it's incorrect behavior, like we don't support CANCEL. 
> And even worse – we'll continue with transaction and send INVITE out 
> when perl_exec exits, while UAC will think that the transaction is 
> cancelled.
>
> I want to achieve answering with 200 to CANCELs and also to stop 
> executing the transactions when perl_exec exits.
>
> Something like creating new transaction with t_newtran() before 
> perl_exec and checking if transaction was cancelled after perl_exec. 
> The only problem is that t_was_cancelled() is not available in 
> REQUEST_ROUTE L
>
> Not working idea:
>
> […]
>
> if(is_method("INVITE"))
>
> { t_newtrans();
>
> if(perl_exec("call_backend") && !t_was_cancelled()) { …..
>
> […]
>
> if(is_method("CANCEL")) {
>
> if(t_check_trans())
>
> {
>
> if(!t_relay())
>
> {
>
> sl_reply_error();
>
> }
>
> }
>
> exit;
>
> }
>
> --
>
> Best Regards,
>
> Alex Massover
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro]
> Sent: Sunday, August 17, 2008 8:28 PM
> To: Alex Massover
> Cc: users at lists.opensips.org
> Subject: Re: [OpenSIPS-Users] CANCELing transactions while perl_exec() 
> running
>
> Hi Alex,
>
> Not sure where the problem is. if your script is still running, it means
>
> your opensips hasn't yet sent any INVITE out, so nothing is to be
>
> cancelled - so the received CANCELs are dropped.
>
> Once the INVITE is sent out, the transaction exists and t_check_trans()
>
> will return true for the CANCEL, so the CANCEL will be sent out to the
>
> same destination as INVITE.
>
> Regards,
>
> Bogdan
>
> Alex Massover wrote:
>
> >
>
> > Hi!
>
> >
>
> > Here's my logic:
>
> >
>
> > […]
>
> >
>
> > if(is_method("INVITE"))
>
> >
>
> > { if(perl_exec("call_backend")) { …..
>
> >
>
> > […]
>
> >
>
> > if(is_method("CANCEL")) {
>
> >
>
> > if(t_check_trans())
>
> >
>
> > {
>
> >
>
> > if(!t_relay())
>
> >
>
> > {
>
> >
>
> > sl_reply_error();
>
> >
>
> > }
>
> >
>
> > }
>
> >
>
> > exit;
>
> >
>
> > }
>
> >
>
> > The purpose of perl_exec("call_backend") is to authenticate each call,
>
> > before the call is routed to destination.
>
> >
>
> > I have a following problem - when UAC sends CANCEL while perl_exec is
>
> > still running. In this case t_check_trans() returns false, and CANCEL
>
> > is silently dropped, so UAC retransmits CANCEL until timer fires.
>
> >
>
> > I wonder how I can correctly process CANCEL for transaction while
>
> > perl_exec is still running?
>
> >
>
> > AFAIU, if I just reply with 200 to CANCEL it's not good, because the
>
> > when perl_exec exits the transactions will be continued. And if I
>
> > remove t_check_trans() it also will make no good.
>
> >
>
> > Probably I need to reply with 200 but really stop this transaction
>
> > from been continued after perl_exec, but I can't figure out how to do it.
>
> >
>
> > --
>
> >
>
> > Best Regards,
>
> >
>
> > Alex Massover
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > ************************************************************************************
>
> > This footnote confirms that this email message has been scanned by
>
> > PineApp Mail-SeCure for the presence of malicious code, vandals &
>
> > computer viruses.
>
> > ************************************************************************************
>
> >
>
> >
>
> > ------------------------------------------------------------------------
>
> >
>
> > _______________________________________________
>
> > Users mailing list
>
> > Users at lists.opensips.org
>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> >
>
> ************************************************************************************
>
> This footnote confirms that this email message has been scanned by
>
> PineApp Mail-SeCure for the presence of malicious code, vandals & 
> computer viruses.
>
> ************************************************************************************
>
>
>
>
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & 
> computer viruses.
> ************************************************************************************
>
>