FreeSWITCH Not Responding to 180

[palmtown]

Describe the bug
FreeSWITCH is not responding to a 180 that includes "Require: 100rel" as required by RFC3261. Please note that if it is a 183, FreeSWITCH will respond. Also, I've noticed in version 1.9.0, FreeSWITCH sends the PRACK. Therefore, between 1.9.0 and 1.10.5, the issue was created.

To Reproduce
Steps to reproduce the behavior:

1. Make an outbound call from FreeSWITCH to a provider.
2. Provider sends 180 with "Require: 100rel"
3. FreeSWITCH doesn't respond with PRACK as required by RFC3261.
4. Call is terminated after no PRACK is received from FreeSWITCH.

Expected behavior
FreeSWITCH respond with a PRACK to the 180.

Package version or git hash

• Version 1.10.5

[hance2010]

<param name="enable-100rel" value="true"/>

and try again.

[mjerris]

note that 100rel support is NOT recommended and there are known crashes that will happen if you enable this in some scenarios

[anthmFS]

Also, best practices are to not have accusatory bug titles like YOU ARE NOT COMPLIANT.
RFC are only implementation guidelines, not rules we are forced to comply with. If we did comply with them verbatim you may have even more issues to report ;)

[palmtown]

Hello @hance2010, @mjerris, @anthmFS:

First and foremost, thank you for your assistance on this issue. Secondly, @anthmFS, in regards to "accusatory bug titles," thanks for explaining the purpose of RFCs, very much appreciated. I modified the title per your suggestion.

Third, please note that I tried enable-100rel, however, that did not work. Note that I believe the issue was created in a later release of FreeSWITCH. Reason being is that this issue does not occur in FreeSWITCH Version 1.9.0-1920-84f50db~64bit. Nonetheless, when I tried upgrading to FreeSWITCH Version 1.10.5-release-17-25569c1631~64bit, this is when I noticed the issue as most of the calls were dropping due to no response to the 180. Note that I have both of these versions running with identical configuration and only version 1.10.5 has this issue.

Any suggestions why FreeSWITCH is not responding to the 180?

[tony-abgm]

Hi @palmtown, did you find a solution to make it work ?
I have the same issue with version 1.10.7.

[nttranbao]

Looks like the issue lies in the underlying sofia-sip package...

Even with 100rel is set to true in sofia profile, FS as UAS, when responding using ring_ready(), won't include RSeq nor Require:100rel in its outgoing 180 Ringing

This is what I just did in my lab (using FS source 1.10.7), to include 180 Ringing when 100rel is applicable....

1. Backup sofia-sip-1.13.6/libsofia-sip-ua/nua/nua_session.c
2. Edit the above file, and add one condition line for 180..
3. Recompile sofia-sip, reinstall and restart FreesWITCH
4. Make sure the relevant sofia profile has enable-100rel set to true. Restart sofia profile if needed
   <param name="enable-100rel" value="true"/>
5. Now FS can both send PRACK upon receiving reliable 180; or respond with a reliable 180 Ringing ( when using ring_ready() )

Note that this is a quick fix good enough for my lab, and I have no idea about the impact it may cause, if any.

----------------- sofia-sip-1.13.6/libsofia-sip-ua/nua/nua_session.c -------------
if (sr->sr_status == 183)
    return 1;
  // line #2482 - nttranbao - 2022/03/30: patch to enable 100rel for 180 ringing (both inbound (UAS) and outbound (UAC))
  if (sr->sr_status == 180)
    return 1;
  //end of part modification

  if (NH_PGET(nh, early_media) && !NH_PGET(nh, only183_100rel))
    return 1;
    
----------------------------end of file -----------------------------------

*********************** Diff version **************************************

--- nua_session.c.orig  2022-03-30 12:22:30.000000000 -0400
+++ nua_session.c       2022-03-30 12:23:28.000000000 -0400
@@ -2480,6 +2480,10 @@
     return 0;
   if (sr->sr_status == 183)
     return 1;
+  // nttranbao - 2022/03/30: patch to enable 100rel for 180 ringing (both inbound (UAS) and outbound (UAC))
+  if (sr->sr_status == 180)
+    return 1;
+  //end of part modification

   if (NH_PGET(nh, early_media) && !NH_PGET(nh, only183_100rel))
     return 1;