25 Oct
2019
25 Oct
'19
11:18 a.m.
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
25 Oct
25 Oct
11:25 a.m.
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12:17 p.m.
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(a)lists.kamailio.org> on behalf of Steve Davies
<steve-lists-srusers(a)connection-telecom.com>
Sent: Friday, October 25, 2019 11:25 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)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@optimobile.se<mailto:lars.olsson@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12:32 p.m.
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_cance…
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(a)lists.kamailio.org> on behalf of
Steve Davies <steve-lists-srusers(a)connection-telecom.com>
*Sent:* Friday, October 25, 2019 11:25 AM
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)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(a)optimobile.se
<mailto:lars.olsson@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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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
12:32 p.m.
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_cance…
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(a)lists.kamailio.org> on behalf of
Steve Davies <steve-lists-srusers(a)connection-telecom.com>
*Sent:* Friday, October 25, 2019 11:25 AM
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)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(a)optimobile.se
<mailto:lars.olsson@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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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
1:04 p.m.
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(a)gmail.com>
Sent: Friday, October 25, 2019 12:32 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Lars Olsson
<lars.olsson(a)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_cance…
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@lists.kamailio.org><mailto:sr-users-bounces@lists.kamailio.org>
on behalf of Steve Davies
<steve-lists-srusers@connection-telecom.com><mailto:steve-lists-srusers@connection-telecom.com>
Sent: Friday, October 25, 2019 11:25 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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@optimobile.se<mailto:lars.olsson@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@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
1:08 p.m.
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(a)gmail.com>
*Sent:* Friday, October 25, 2019 12:32 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>rg>; Lars Olsson <lars.olsson(a)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_cance…
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:
--
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
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(a)lists.kamailio.org>
<mailto:sr-users-bounces@lists.kamailio.org> on behalf of Steve
Davies <steve-lists-srusers(a)connection-telecom.com>
<mailto:steve-lists-srusers@connection-telecom.com>
*Sent:* Friday, October 25, 2019 11:25 AM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org> <mailto:sr-users@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(a)optimobile.se
<mailto:lars.olsson@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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@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
1:09 p.m.
Sorry for forgetting to that result:
ERROR: <script>: Failed to cancel transaction
________________________________
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: Friday, October 25, 2019 1:08 PM
To: Lars Olsson <lars.olsson(a)optimobile.se>se>; Kamailio (SER) - Users Mailing List
<sr-users(a)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@gmail.com><mailto:miconda@gmail.com>
Sent: Friday, October 25, 2019 12:32 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>; Lars Olsson
<lars.olsson@optimobile.se><mailto:lars.olsson@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_cance…
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@lists.kamailio.org><mailto:sr-users-bounces@lists.kamailio.org>
on behalf of Steve Davies
<steve-lists-srusers@connection-telecom.com><mailto:steve-lists-srusers@connection-telecom.com>
Sent: Friday, October 25, 2019 11:25 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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@optimobile.se<mailto:lars.olsson@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@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<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
1:32 p.m.
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(a)gmail.com>
*Sent:* Friday, October 25, 2019 1:08 PM
*To:* Lars Olsson <lars.olsson(a)optimobile.se>se>; Kamailio (SER) - Users
Mailing List <sr-users(a)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:
--
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
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(a)gmail.com>
<mailto:miconda@gmail.com>
*Sent:* Friday, October 25, 2019 12:32 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org> <mailto:sr-users@lists.kamailio.org>;
Lars Olsson <lars.olsson(a)optimobile.se>
<mailto:lars.olsson@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_cance…
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:
--
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
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(a)lists.kamailio.org>
<mailto:sr-users-bounces@lists.kamailio.org> on behalf of Steve
Davies <steve-lists-srusers(a)connection-telecom.com>
<mailto:steve-lists-srusers@connection-telecom.com>
*Sent:* Friday, October 25, 2019 11:25 AM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org> <mailto:sr-users@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(a)optimobile.se
<mailto:lars.olsson@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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@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
26 Oct
26 Oct
4:10 p.m.
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(a)gmail.com>
Sent: Friday, October 25, 2019 1:32 PM
To: Lars Olsson <lars.olsson(a)optimobile.se>se>; Kamailio (SER) - Users Mailing List
<sr-users(a)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@gmail.com><mailto:miconda@gmail.com>
Sent: Friday, October 25, 2019 1:08 PM
To: Lars Olsson <lars.olsson@optimobile.se><mailto:lars.olsson@optimobile.se>;
Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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@gmail.com><mailto:miconda@gmail.com>
Sent: Friday, October 25, 2019 12:32 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>; Lars Olsson
<lars.olsson@optimobile.se><mailto:lars.olsson@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_cance…
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@lists.kamailio.org><mailto:sr-users-bounces@lists.kamailio.org>
on behalf of Steve Davies
<steve-lists-srusers@connection-telecom.com><mailto:steve-lists-srusers@connection-telecom.com>
Sent: Friday, October 25, 2019 11:25 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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@optimobile.se<mailto:lars.olsson@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@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<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<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
29 Sep
29 Sep
2:54 a.m.
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(a)optimobile.se>
Sent: Saturday, October 26, 2019 4:10 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>;
miconda(a)gmail.com <miconda(a)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(a)gmail.com>
Sent: Friday, October 25, 2019 1:32 PM
To: Lars Olsson <lars.olsson(a)optimobile.se>se>; Kamailio (SER) - Users Mailing List
<sr-users(a)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@gmail.com><mailto:miconda@gmail.com>
Sent: Friday, October 25, 2019 1:08 PM
To: Lars Olsson <lars.olsson@optimobile.se><mailto:lars.olsson@optimobile.se>;
Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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@gmail.com><mailto:miconda@gmail.com>
Sent: Friday, October 25, 2019 12:32 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>; Lars Olsson
<lars.olsson@optimobile.se><mailto:lars.olsson@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_cance…
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@lists.kamailio.org><mailto:sr-users-bounces@lists.kamailio.org>
on behalf of Steve Davies
<steve-lists-srusers@connection-telecom.com><mailto:steve-lists-srusers@connection-telecom.com>
Sent: Friday, October 25, 2019 11:25 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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@optimobile.se<mailto:lars.olsson@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@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@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<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<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
11:32 a.m.
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(a)optimobile.se>
*Sent:* Saturday, October 26, 2019 4:10 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>rg>; miconda(a)gmail.com <miconda(a)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(a)gmail.com>
*Sent:* Friday, October 25, 2019 1:32 PM
*To:* Lars Olsson <lars.olsson(a)optimobile.se>se>; Kamailio (SER) - Users
Mailing List <sr-users(a)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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Sorry for forgetting to that result:
ERROR: <script>: Failed to cancel transaction
------------------------------------------------------------------------
*From:* Daniel-Constantin Mierla <miconda(a)gmail.com>
<mailto:miconda@gmail.com>
*Sent:* Friday, October 25, 2019 1:08 PM
*To:* Lars Olsson <lars.olsson(a)optimobile.se>
<mailto:lars.olsson@optimobile.se>; Kamailio (SER) - Users Mailing
List <sr-users(a)lists.kamailio.org> <mailto:sr-users@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:
--
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> 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(a)gmail.com>
<mailto:miconda@gmail.com>
*Sent:* Friday, October 25, 2019 12:32 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org> <mailto:sr-users@lists.kamailio.org>;
Lars Olsson <lars.olsson(a)optimobile.se>
<mailto:lars.olsson@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_cance…
<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:
--
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> 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(a)lists.kamailio.org>
<mailto:sr-users-bounces@lists.kamailio.org> on behalf of Steve
Davies <steve-lists-srusers(a)connection-telecom.com>
<mailto:steve-lists-srusers@connection-telecom.com>
*Sent:* Friday, October 25, 2019 11:25 AM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org> <mailto:sr-users@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(a)optimobile.se <mailto:lars.olsson@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(a)lists.kamailio.org <mailto:sr-users@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(a)lists.kamailio.org <mailto:sr-users@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>
1302
days inactive
1642
days old
11 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Lars Olsson -
Steve Davies