FS responds 488 to t38 reinvite for some bridge syntax

[ynasida]

Hello,

I noted that FS handles t38 reinvites differently some cases below:

session:execute(“bridge”, “user/”… user …“@${domain_name}”) Grandsteam ata sends reinvite with t38 and it work perfectly. But if I use this syntax session:execute(“bridge”, “${sofia_contact(”… user …“@${domain_name})}”) FS responds with 488 Not Acceptable to ABSOLUTELY same reinvite from Grandstem. Again. There is no difference in reinvite. Also it is the same lua script. I just change two strings above. In lua i also have session:execute(“export”, “38_passthru=true”) session:execute(“export”, “fax_enable_t38=true”)

FreeSWITCH Version 1.10.11-release-25-f24064f7c9~64bit (-release-25-f24064f7c9 64bit) Debian 12

[cpmkasinski]

@ynasida not sure which one of these params are correct but you can try with change in vars.xml:

  <X-PRE-PROCESS cmd="set" data="refuse_t38=false"/>
  <X-PRE-PROCESS cmd="set" data="fax_enable_t38=true"/>

[ynasida]

@cpmkasinski um.. not sure how this should help. fax_enable_t38 is enabled in lua already. As for refuse_t38 - it is not set anywhere.

[cpmkasinski]

Oh, i didn't red your post thoroughly.

Perhaps it has something to do with what you have in your user directory? What is your dial-string? Do you have any additional variables?

You could verify your case by simplifying directory to include only sofia_contact in dial string. Then it would be clear if calling user/ syntax messes up with fax processing.

[ynasida]

@cpmkasinski, thank you for the answer. I checked dial-string and it is: {vm-enabled=true}${sofia_contact(${dialed_user}@${dialed_domain})}

So it is the same string i use in lua session:execute(“bridge”, “${sofia_contact(”… user …“@${domain_name})}”)

Yes, variables are the 1st thing I checked. But like i mentioned i use the same lua script. I just set session:execute(“bridge”, “user/”… user …“@${domain_name}”) instead of session:execute(“bridge”, “${sofia_contact(”… user …“@${domain_name})}”) and FS does not reply with 488 to t38 reinvite. I almost sure it's something in C code.

[cpmkasinski]

I would get debug logs of both cases and compare it with diff or diff-like tool. I use vimdiff on linux or winmerge in windows. The difference may point to the path in code specific to user application in which there may be something that affects call processing.

With this approach i sometimes find things that are dependent on configuration solely, so eventually i dont have to make any changes in code to make things work.

[ynasida]

@cpmkasinski yes, i tried to compare with max debug level but it did not help me to understand where to find the issue. May be you can see something useful here ?

nta.c:8905 outgoing_reclaim_queued() outgoing_reclaim_all((nil), (nil), 0x7ff75f64fac0)
nta.c:9045 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 3/13 term, 3/13 free
nta.c:1317 agent_timer() nta: timer set next to 1996 ms
nua.c:878 nua_respond() nua: nua_respond: entering
nua_stack.c:558 nua_signal() nua(0x7ff6c805f640): sent signal r_respond
nua.c:365 nua_handle_magic() nua: nua_handle_magic: entering
nua.c:1170 nua_handle_unref_user() nua nua_handle_unref_user(0x7ff6c805f640): entering
nua_stack.c:558 nua_signal() nua(0x7ff6c805f640): sent signal r_handle_unref
nua.c:1157 nua_unref_user() nua: nua_unref_user: entering
nua_stack.c:558 nua_signal() nua((nil)): sent signal r_unref
**nua_stack.c:601 nua_stack_signal() nua(0x7ff6c805f640): recv signal r_respond 488 Not Acceptable Here**
nua_params.c:484 nua_stack_set_params() nua: nua_stack_set_params: entering
soa.c:402 soa_set_params() soa_set_params(static::0x7ff72c051a10, ...) called
nua_session.c:2317 nua_invite_server_respond() nua: nua_invite_server_respond: entering
soa.c:1213 soa_clear_remote_sdp() soa_clear_remote_sdp(static::0x7ff72c051a10) called
tport.c:3290 tport_tsend() tport_tsend(0x7ff72c0051a0) tpn = UDP/IP:5060
tport.c:4076 tport_resolve() tport_resolve addrinfo = IP:5060
tport.c:4713 tport_by_addrinfo() tport_by_addrinfo(0x7ff72c0051a0): not found by name UDP/IP:5060
tport.c:3625 tport_vsend() tport_vsend(0x7ff72c0051a0): 693 bytes of 693 to udp/IP:5060
tport.c:3526 tport_send_msg() tport_vsend returned 693
send 693 bytes to udp/[IP]:5060 at 16:35:23.358112:
------------------------------------------------------------------------
SIP/2.0 488 Not Acceptable Here

[cpmkasinski]

You have "IP" string instead of actual IP address here. Or it's just obfuscation?

If you compared complete logs of both calls line by line, and there is no difference than i can't help more. It may be in code of user application in freeswitch but that would require more comprehensive analysis.

[ynasida]

@cpmkasinski yes, i changed real ip address to 'IP' in logs. Thanks for your wiliness to help. Yes, need to get more comprehensive analysis somehow.