Module: kamailio
Branch: master
Commit: 00b1aba770c26f75c31cf2a28e7ca425f18788dc
URL: https://github.com/kamailio/kamailio/commit/00b1aba770c26f75c31cf2a28e7ca42…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2021-01-25T12:42:36+01:00
tm: docs for reply_relay_mode parameter
---
Modified: src/modules/tm/doc/params.xml
---
Diff: https://github.com/kamailio/kamailio/commit/00b1aba770c26f75c31cf2a28e7ca42…
Patch: https://github.com/kamailio/kamailio/commit/00b1aba770c26f75c31cf2a28e7ca42…
---
diff --git a/src/modules/tm/doc/params.xml b/src/modules/tm/doc/params.xml
index 0c187375cc..3fdb0a7a49 100644
--- a/src/modules/tm/doc/params.xml
+++ b/src/modules/tm/doc/params.xml
@@ -1547,6 +1547,35 @@ modparam("tm", "rich_redirect", 3)
...
modparam("tm", "exec_time_check", 0)
...
+</programlisting>
+ </example>
+ </section>
+
+ <section id="tm.p.reply_relay_mode">
+ <title><varname>reply_relay_mode</varname> (int)</title>
+ <para>
+ If set to 1, a received 200ok response that was suspeneded is no
+ longer forwarded in the transactional context if another final
+ response was forward while 200ok was suspended. Forwarding the 200ok,
+ even it was received first, results in overwritting the transaction
+ response buffer that can impact matching of incoming ACKs.
+ </para>
+ <para>
+ Set it to 0 in order to disable this behaviour and attempt to forward
+ suspended 200ok in the transaction context. This was the behaviour
+ before the commit 18410da0.
+ </para>
+ <para>
+ <emphasis>
+ Default value is 1.
+ </emphasis>
+ </para>
+ <example>
+ <title>Set <varname>reply_relay_mode</varname> parameter</title>
+ <programlisting format="linespecific">
+...
+modparam("tm", "reply_relay_mode", 0)
+...
</programlisting>
</example>
</section>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x ] Commit message has the format required by CONTRIBUTING guide
- [x ] Commits are split per component (core, individual modules, libs, utils, ...)
- [x ] Each component has a single commit (if not, squash them into one commit)
- [x ] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [x ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x ] Tested changes locally -- tested at 5.1.6
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
Problem:
Forwarding of 200 OK while sent 488 waits for ACK, destroys the UAS send buffer
Scenario:
During suspension of 200 OK by ims_qos module function Rx_AAR() at terminating PCSCF,
The PCRF sends an AA Answer with result code DIAMETER_TOO_BUSY (3004), which triggers
the PCSCF to send a 488 ‘Sorry no QoS available’ to the originating side (ims_dialog
module function dlg_terminate()).
Afterwards neither the 200 OK nor the ACK(488) is processed correctly by the PCSCF.
Solution:
The UAS send buffer should not be overwritten during processing of 200 OK,
because non-2xx is needed to associate the ACK message in a correct way.
200 OK must be forwarded statelessly.
Side-Effect (potentially breaks existing function):
Some callbacks cannot be called for the 200 OK, to avoid messing the stored 488.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2590
-- Commit Summary --
* tm: 200 OK not processed correctly by Proxy after final non-2xx
-- File Changes --
M src/modules/tm/t_reply.c (72)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2590.patchhttps://github.com/kamailio/kamailio/pull/2590.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2590
Module: kamailio
Branch: master
Commit: 18410da04c7f7bbc9628820427fedb92cf893526
URL: https://github.com/kamailio/kamailio/commit/18410da04c7f7bbc9628820427fedb9…
Author: Theo <theodor.scherney(a)kapsch.net>
Committer: Theo <theodor.scherney(a)kapsch.net>
Date: 2020-12-17T14:32:39+01:00
tm: 200 OK not processed correctly by Proxy after final non-2xx
Description:
Problem:
Forwarding of 200 OK while sent 488 waits for ACK, destroys the UAS send buffer
Scenario:
During suspension of 200 OK by ims_qos module function Rx_AAR() at terminating PCSCF,
The PCRF sends an AA Answer with result code DIAMETER_TOO_BUSY (3004), which triggers
the PCSCF to send a 488 âSorry no QoS availableâ to the originating side (ims_dialog
module function dlg_terminate()).
Afterwards neither the 200 OK nor the ACK(488) is processed correctly by the PCSCF.
Solution:
The UAS send buffer should not be overwritten during processing of 200 OK,
because non-2xx is needed to associate the ACK message in a correct way.
200 OK must be forwarded statelessly.
Side-Effect (potentially breaks existing function):
Some callbacks cannot be called for the 200 OK, to avoid messing the stored 488.
---
Modified: src/modules/tm/t_reply.c
---
Diff: https://github.com/kamailio/kamailio/commit/18410da04c7f7bbc9628820427fedb9…
Patch: https://github.com/kamailio/kamailio/commit/18410da04c7f7bbc9628820427fedb9…
Module: kamailio
Branch: master
Commit: 12414972ad0c28ac50ece3c14f98134c3f06c522
URL: https://github.com/kamailio/kamailio/commit/12414972ad0c28ac50ece3c14f98134…
Author: Nicolas C <nchaigne(a)capgemini.fr>
Committer: Nicolas C <nchaigne(a)capgemini.fr>
Date: 2021-01-22T16:04:40+01:00
core: fix to xavp_rm_internal (#2604)
This fixes the following issue:
https://github.com/kamailio/kamailio/issues/2604
Description of the issue:
When called to remove a specific index from a given xavp, function xavp_rm_by_index removes the index (as expected) but also all others before it.
E.g :
If called with idx = 1, it removes indexes 0 and 1.
Likewise if invoked with idx = 2 => the first 3 elements are removed.
This bug is located in function xavp_rm_internal. An assignment was missing when looping over the xavp list.
Same for xavi_rm_internal.
---
Modified: src/core/xavp.c
---
Diff: https://github.com/kamailio/kamailio/commit/12414972ad0c28ac50ece3c14f98134…
Patch: https://github.com/kamailio/kamailio/commit/12414972ad0c28ac50ece3c14f98134…
---
diff --git a/src/core/xavp.c b/src/core/xavp.c
index de6da0c858..26e89a8df3 100644
--- a/src/core/xavp.c
+++ b/src/core/xavp.c
@@ -454,6 +454,8 @@ static int xavp_rm_internal(str *name, sr_xavp_t **head, int idx)
if(idx>=0)
return 1;
count++;
+ } else {
+ prv = foo;
}
n++;
} else {
@@ -1914,6 +1916,8 @@ static int xavi_rm_internal(str *name, sr_xavp_t **head, int idx)
if(idx>=0)
return 1;
count++;
+ } else {
+ prv = foo;
}
n++;
} else {