0

This is my first time using opensips, so am probably missing something obvious.

I am trying to use opensips and mid_registrar in front of freeswitch. The opensips is behind a NAT so I am setting the advertised_address to my public IP. The registrations work Ok, but an invite goes through the auth required but the ACK from the client is not routed back to the freeswitch server, instead going to the public interface.

I am using a modified version of the sample for the mid_registrar tutorial, mainly changes for 3.3 as the script is for 2.x.

It seems that the loose_route() is returning true but the $du is not being modified. If I hack to set the $du for both ACK and BYE to the freeswitch ip then the call completes Ok (still have rtp issues, but that comes next).

In the attached https://pastebin.com/Pz3anhYb

it all goes a bit pear shaped at 2022/11/28 12:17:42.170560

In the attached https://pastebin.com/siCZDEt2

if I enable line 142 to modify $du it gets one step further.

I am familiar with SIP but not at this level.

(sorry can't seem to add file links without making then code)

Peter Bonham
  • 47
  • 6

1 Answers1

0

Most likely, FreeSWITCH is discarding the ACK because you are manually modifying the Request-URI, leading to a URI it does not recognize anymore. Notice the difference:

  • 200 OK Contact header from FS contains sip:1008@115.188.133.253:5060;transport=udp
  • The ACK sent to FS contains sip:115.188.133.253;lr as Request-URI (??)

To fix this, you should use the "route recording" mechanism specific to SIP RFC 3261, where the mid-registrar effectively records itself in the path of mid-dialog requests, rather than achieving this through some hardcoded-behavior in your UAC (e.g. "Why is the ACK sent to 192.168.1.238 in the first place? SIP-wise, it should go directly to 115.188.133.253!").

Concretely, call record_route() before mid_registrar_lookup() on your initial INVITEs.

Liviu Chircu
  • 1,000
  • 3
  • 11
  • 24