[SR-Users] Rewrite BYE to Cancel

[Daniel-Constantin Mierla]

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> on behalf of
> Steve Davies <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>
> *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
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
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/7f7a9659/attachment.html>