[SR-Users] Rewrite BYE to Cancel

Daniel-Constantin Mierla miconda at gmail.com
Fri Oct 25 13:08:14 CEST 2019


Hello,


which of the xlog messages were printed?


Cheers,
Daniel


On 25.10.19 13:04, Lars Olsson wrote:
> Hi Daniel,
>
> Thanks for your reply.
>
> Used the following script for testing:
>
> if (is_method("BYE")) {
>
>             xlog("CALLID: $ci\n");
>             xlog("CSEQ: $cs\n");
>
>             if (t_cancel_callid("$ci", "$cs", "0")) {
>                xlog("Transaction cancelled\n");
>             } else {
>                xlog("Failed to cancel transaction\n");
>             }
>             send_reply("200", "OK");
>             exit;
> }
>
> No cancel message was triggered.
>
> Best Regards,
> Lars
> ------------------------------------------------------------------------
> *From:* Daniel-Constantin Mierla <miconda at gmail.com>
> *Sent:* Friday, October 25, 2019 12:32 PM
> *To:* Kamailio (SER) - Users Mailing List
> <sr-users at lists.kamailio.org>; Lars Olsson <lars.olsson at optimobile.se>
> *Subject:* Re: [SR-Users] Rewrite BYE to Cancel
>  
>
> Hello,
>
>
> actually sending BYE for an in-progress call setup (initial INVITE
> routed, but 200ok was not received yet) is valid from SIP RFC point of
> view. So it is not really a broken implementation (or, not to put all
> my money in, it can be, but not because of this kind of BYE).
>
>
> Practically the BYE can be used to terminate a specific branch in a
> call setup. Think about parallel forking, and many branches start
> sending back 183. The caller UA can send BYE to some of the branches
> and let the others wait to complete.
>
>
> The CANCEL has to be used when all the branches should be terminated.
> If there is a single branch, then the BYE terminates the call in
> progress, I am not sure what the callee UA should reply to the INVITE.
>
>
> On the other hand, in the very few cases when I saw UAs sending BYE
> for early call setup, the other side was rejecting it, expecting the
> cancel.
>
>
> I expect it should work with kamailio to send 200ok for such BYE and
> then use t_cancel_callid():
>
>
> https://www.kamailio.org/docs/modules/stable/modules/tmx.html#tmx.f.t_cancel_callid
>
>
> The call-id and cseq values should be the same in the BYE request.
>
> Try it and write back if works, I am quite curious about...
>
> Cheers,
> Daniel
>
> On 25.10.19 12:17, Lars Olsson wrote:
>> Yes it is a BROKEN behavior from the remote system, unfortunately it
>> can not be changed.
>> Besides this issue, the remote system works as it should.
>>
>> A custom b2bua can for sure resolve this, but perhaps not in a
>> standard way.
>> Question is if it is possible to resolve with Kamailio or if I need
>> to patch SEMS to handle this.
>>
>> Something like this:
>>
>> if ("BYE" && dialog not confirmed)
>>     reply back 200 OK
>>     cancel other side of dialog
>>
>> As Kamailio can terminate active dialog with sending bye in both
>> directions, I thought that it might be possible to resolve this as
>> well.  Hence asking for ideas.
>>
>> Best Regards,
>> Lars
>>
>> ------------------------------------------------------------------------
>> *From:* sr-users <sr-users-bounces at lists.kamailio.org>
>> <mailto:sr-users-bounces at lists.kamailio.org> on behalf of Steve
>> Davies <steve-lists-srusers at connection-telecom.com>
>> <mailto:steve-lists-srusers at connection-telecom.com>
>> *Sent:* Friday, October 25, 2019 11:25 AM
>> *To:* Kamailio (SER) - Users Mailing List
>> <sr-users at lists.kamailio.org> <mailto:sr-users at lists.kamailio.org>
>> *Subject:* Re: [SR-Users] Rewrite BYE to Cancel
>>  
>> Hi,
>>
>> I'm normally a bystander.  But on this occasion I've got to comment -
>> there are broken SIP implementations, and there are BROKEN ones. 
>> Surely there is no hope with this one?  If they can't get this right
>> just imagine how many more problems it will have.
>>
>> Steve
>>
>>
>> On Fri, 25 Oct 2019 at 11:19, Lars Olsson <lars.olsson at optimobile.se
>> <mailto:lars.olsson at optimobile.se>> wrote:
>>
>>     hi,
>>
>>     I have a Kamailio setup infront of a SIP system that do not
>>     handle cancellation of a INVITE correctly.
>>     The system sends out a BYE request instead of a Cancel request on
>>     non connected dialogs.
>>
>>     I am trying to find a way to let Kamailio "translate" the BYE
>>     request to a Cancel reqeust for the ongoing INVITE dialog.
>>
>>     Alternative if SEMS b2bua can do it, but currently it replies:
>>     "not sip-relaying BYE in not connected dlg", and I have not found
>>     any obvious way to rewrite it there.
>>
>>     Any thoughts. I can not change the behavior of the remote system.
>>
>>     Best Regards,
>>     Lars
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191025/90daaa59/attachment.html>


More information about the sr-users mailing list