[SR-Users] Rewrite BYE to Cancel
Daniel-Constantin Mierla
miconda at gmail.com
Tue Sep 29 11:32:05 CEST 2020
Hello,
do you have reparse invite modparam for tm set?
The Contact header should not be added to locally generated cancel
requests as I could see on a quick check over the code in master branch
(but I do not recall changes in this part for many years). Maybe you can
grab the pcap/ngrep output with sip traffic for such case to see if we
can spot any leads about what happens there.
Cheers,
Daniel
On 29.09.20 02:54, Lars Olsson wrote:
>
> Hi
>
>
>
> A follow up question on a almost one year old case.
>
>
> t_cancel_callid() is still working good.
>
>
> However, a new calling scenario towards the same system just got me
> another issue.
>
>
> The Cancel request generated by t_cancel_callid() is not accepted by
> this old legacy system.
>
> I have not yet confirmed it, but it looks like the only difference
> form other Cancel request is that t_cancel_callid() generates a Cancel
> with a Contact header.
>
>
> Should the Contact header really be inside the Cancel request?
>
> Is it possible to disable it?
>
>
> Running Kamailio 5.3.6
>
>
> Best Regards,
>
> Lars
>
>
>
> ------------------------------------------------------------------------
> *From:* Lars Olsson <lars.olsson at optimobile.se>
> *Sent:* Saturday, October 26, 2019 4:10 PM
> *To:* Kamailio (SER) - Users Mailing List
> <sr-users at lists.kamailio.org>; miconda at gmail.com <miconda at gmail.com>
> *Subject:* Re: [SR-Users] Rewrite BYE to Cancel
>
> Hi all,
>
> I just want to report back.
> Daniels suggestion worked great!
> Thanks a lot for your input.
>
> On the "incorrect" BYE request, trigger a cancel for the INVITE with
> t_cancel_callid() using call-id and cseq of the INVITE request. (Cseq
> was not the same on INVITE and BYE).
> Then reply with 200 OK to the BYE message.
>
> Cheers,
> Lars
> ------------------------------------------------------------------------
> *From:* Daniel-Constantin Mierla <miconda at gmail.com>
> *Sent:* Friday, October 25, 2019 1:32 PM
> *To:* Lars Olsson <lars.olsson at optimobile.se>; Kamailio (SER) - Users
> Mailing List <sr-users at lists.kamailio.org>
> *Subject:* Re: [SR-Users] Rewrite BYE to Cancel
>
>
> Run with debug=3 and see if you get other log messages from
> t_cancel_callid() execution.
>
>
> Cheers,
> Daniel
>
>
> On 25.10.19 13:09, Lars Olsson wrote:
>> Sorry for forgetting to that result:
>> ERROR: <script>: Failed to cancel transaction
>> ------------------------------------------------------------------------
>> *From:* Daniel-Constantin Mierla <miconda at gmail.com>
>> <mailto:miconda at gmail.com>
>> *Sent:* Friday, October 25, 2019 1:08 PM
>> *To:* Lars Olsson <lars.olsson at optimobile.se>
>> <mailto:lars.olsson at optimobile.se>; 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
>>
>>
>> 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>
>>> <mailto:miconda at gmail.com>
>>> *Sent:* Friday, October 25, 2019 12:32 PM
>>> *To:* Kamailio (SER) - Users Mailing List
>>> <sr-users at lists.kamailio.org> <mailto:sr-users at lists.kamailio.org>;
>>> Lars Olsson <lars.olsson at optimobile.se>
>>> <mailto: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
>>> <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
>>>> <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 <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 <https://asipto.com/u/kat>
>> --
>> 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 <https://asipto.com/u/kat>
> --
> 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 <https://asipto.com/u/kat>
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200929/8edb243a/attachment.htm>
More information about the sr-users
mailing list