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 <[email protected]> > *Sent:* Saturday, October 26, 2019 4:10 PM > *To:* Kamailio (SER) - Users Mailing List > <[email protected]>; [email protected] <[email protected]> > *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 <[email protected]> > *Sent:* Friday, October 25, 2019 1:32 PM > *To:* Lars Olsson <[email protected]>; Kamailio (SER) - Users > Mailing List <[email protected]> > *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 <[email protected]> >> <mailto:[email protected]> >> *Sent:* Friday, October 25, 2019 1:08 PM >> *To:* Lars Olsson <[email protected]> >> <mailto:[email protected]>; Kamailio (SER) - Users Mailing >> List <[email protected]> <mailto:[email protected]> >> *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 <[email protected]> >>> <mailto:[email protected]> >>> *Sent:* Friday, October 25, 2019 12:32 PM >>> *To:* Kamailio (SER) - Users Mailing List >>> <[email protected]> <mailto:[email protected]>; >>> Lars Olsson <[email protected]> >>> <mailto:[email protected]> >>> *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 <[email protected]> >>>> <mailto:[email protected]> on behalf of Steve >>>> Davies <[email protected]> >>>> <mailto:[email protected]> >>>> *Sent:* Friday, October 25, 2019 11:25 AM >>>> *To:* Kamailio (SER) - Users Mailing List >>>> <[email protected]> <mailto:[email protected]> >>>> *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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> 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
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
