UDP Transport Invite delayed by 5 seconds

Dear FS community,

I keep encountering this issue and I can’t seem to figure out what’s causing it.

My setup is this:
Debian 11
FreeSWITCH Version 1.10.9-release-21-a615e85afc~64bit

Note: In configs and logs here I have replaced my public IPs with “EXTERNAL_IPv6” and “DESKPHONE_IPv6” for the FS server and my desk phone respectively.

  • I’m runnig IPv6 only with the internal-ipv6 profile.
  • I’m using a single Grandstream GXP2160 desk phone registering as EXT 1001 via UDP/5060.
  • Registration works, SIP packets are exchanged without issues, RTP / audio is exchanged both ways without any issues, calling extensions like 9000 and 9198 works without any issues.

But: Seemingly any invite has almost exactly a 5 second delay. I tested this both via a second registered extension calling the first (or the other way around) and placing a call to the extension via fs_cli using

originate sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 &echo()

Either way FS says “sending invite”, does CS_INIT → CS_ROUTING, CS_ROUTING → CS_CONSUME_MEDIA and then waits 5 seconds before actually sending out the invite to the desk phone. Here’s a log from fs_cli showing this after using originate to place a call:

Summary
2023-03-14 22:08:47.496050 99.07% [DEBUG] switch_ivr_originate.c:2291 Parsing global variables
2023-03-14 22:08:47.516010 99.07% [NOTICE] switch_channel.c:1123 New Channel sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 [dba18b7c-a28b-41ce-ace9-47956cde1ffe]
2023-03-14 22:08:47.516010 99.07% [DEBUG] mod_sofia.c:5117 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State Change CS_NEW -> CS_INIT
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) Running State Change CS_INIT (Cur 1 Tot 6)
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:624 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State INIT
2023-03-14 22:08:47.516010 99.07% [DEBUG] mod_sofia.c:97 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 SOFIA INIT
2023-03-14 22:08:47.516010 99.07% [INFO] sofia_glue.c:1654 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 sending invite call-id: (null)
2023-03-14 22:08:47.516010 99.07% [DEBUG] sofia_glue.c:1657 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 sending invite version: 1.10.9 -release-21-a615e85afc 64bit
Local SDP:
v=0
o=FreeSWITCH 1678831713 1678831714 IN IP6 EXTERNAL_IPv6
s=FreeSWITCH
c=IN IP6 EXTERNAL_IPv6
t=0 0
m=audio 25214 RTP/AVP 102 9 0 8 105 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 telephone-event/48000
a=fmtp:105 0-15
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
m=video 16544 RTP/AVP 103 104
b=AS:3072
a=rtpmap:103 H264/90000
a=rtpmap:104 VP8/90000
a=sendrecv
a=rtcp-fb:103 ccm fir
a=rtcp-fb:103 ccm tmmbr
a=rtcp-fb:103 nack
a=rtcp-fb:103 nack pli
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 ccm tmmbr
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli

2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:40 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 Standard INIT
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:48 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State Change CS_INIT -> CS_ROUTING
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:624 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State INIT going to sleep
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) Running State Change CS_ROUTING (Cur 1 Tot 6)
2023-03-14 22:08:47.516010 99.07% [DEBUG] sofia.c:7487 Channel sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 entering state [calling][0]
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:640 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State ROUTING
2023-03-14 22:08:47.516010 99.07% [DEBUG] mod_sofia.c:158 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 SOFIA ROUTING
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_ivr_originate.c:67 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State Change CS_ROUTING -> CS_CONSUME_MEDIA
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:640 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State ROUTING going to sleep
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) Running State Change CS_CONSUME_MEDIA (Cur 1 Tot 6)
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:659 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State CONSUME_MEDIA
2023-03-14 22:08:47.516010 99.07% [DEBUG] switch_core_state_machine.c:659 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State CONSUME_MEDIA going to sleep
send 1712 bytes to udp/[DESKPHONE_IPv6]:5060 at 22:08:52.518055:
------------------------------------------------------------------------
INVITE sip:1001@[DESKPHONE_IPv6]:5060 SIP/2.0
Via: SIP/2.0/UDP [EXTERNAL_IPv6];rport;branch=z9hG4bKSmpN7pN4j18rm
Max-Forwards: 70
From: <sip:0000000000@[EXTERNAL_IPv6]>;tag=Kjc95U8m2D6XK
To: <sip:1001@[DESKPHONE_IPv6]:5060>

[...]

As you can see, the last log message before the invite is State CONSUME_MEDIA going to sleep at 22:08:47 and the next line, sending the invite is at 22:08:52

Now I have tested the exact same scenario just registering the desk phone via TCP instead of UDP and there is no delay whatsoever. For external reasons I won’t be able to use TCP though, so I would love to figure out what could be causing this delay.

If anyone has any pointers I would be extremely grateful, as I seem to not be getting anywhere in my troubleshooting.

This is my internal-ipv6 profile, just in case:

Summary
<profile name="internal-ipv6">
  <settings>
    <param name="context" value="default"/>
    <param name="rfc2833-pt" value="101"/>
    <param name="sip-port" value="$${internal_sip_port}"/>
    <param name="dialplan" value="XML"/>
    <param name="dtmf-duration" value="2000"/>
    <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/>
    <param name="outbound-codec-prefs" value="$${global_codec_prefs}"/>
    <param name="use-rtp-timer" value="true"/>
    <param name="rtp-timer-name" value="soft"/>
    <param name="rtp-ip" value="EXTERNAL_IPv6"/>
    <param name="sip-ip" value="EXTERNAL_IPv6"/>
    <param name="hold-music" value="$${hold_music}"/>
    <param name="apply-inbound-acl" value="domains"/>
    <param name="record-template" value="$${recordings_dir}/${caller_id_number}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav"/>
    <param name="manage-presence" value="true"/>
    <param name="inbound-codec-negotiation" value="generous"/>
    <param name="tls" value="$${internal_ssl_enable}"/>
    <param name="tls-bind-params" value="transport=tls"/>
    <param name="tls-sip-port" value="$${internal_tls_port}"/>
    <param name="tls-cert-dir" value="$${internal_ssl_dir}"/>
    <param name="tls-version" value="$${sip_tls_version}"/>
    <param name="inbound-late-negotiation" value="true"/>
	<param name="nonce-ttl" value="60"/>
    <param name="auth-calls" value="$${internal_auth_calls}"/>
    <param name="auth-all-packets" value="false"/>
    <param name="rtp-timeout-sec" value="300"/>
    <param name="rtp-hold-timeout-sec" value="1800"/>
    <param name="force-register-domain" value="$${domain}"/>
    <param name="force-register-db-domain" value="$${domain}"/>
	<param name="debug" value="0"/>
    <param name="sip-trace" value="yes"/>
    <param name="track-calls" value="true"/>
    <param name="odbc-dsn" value="PGSQL_CONNECTION"/>
  </settings>
</profile>

And this is the output of sofia status profile internal-ipv6 reg

Summary
Registrations:
==============================================
Call-ID:        1032127981-5060-1@CGAA:GcFB:HEHf:dFCc::CBG
User:           1001@[DOMAIN]
Contact:        "" <sip:1001@[DESKPHONE_IPv6]:5060;fs_nat=yes>
Agent:          Grandstream GXP2160 1.0.11.64
Status:         Registered(AUTO-NAT)(unknown) EXP(2023-03-14 23:02:52) EXPSECS(78)
Ping-Status:    Reachable
Ping-Time:      0.00
Host:           [HOSTNAME]
IP:             [DESKPHONE_IPv6]
Port:           5060
Auth-User:      1001
Auth-Realm:     [DOMAIN]
MWI-Account:    1001@[DOMAIN]

Total items returned: 1
==============================================

Here is a log of the same scenario, but with sofia loglevel all 9 :

Summary
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_ivr_originate.c:2291 Parsing global variables
2023-03-14 23:07:38.596020 98.30% [NOTICE] switch_channel.c:1123 New Channel sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 [827a3f4d-317a-4d48-a60e-039095948ab7]
2023-03-14 23:07:38.596020 98.30% [DEBUG] mod_sofia.c:5117 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State Change CS_NEW -> CS_INIT
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) Running State Change CS_INIT (Cur 1 Tot 11)
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:624 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State INIT
2023-03-14 23:07:38.596020 98.30% [DEBUG] mod_sofia.c:97 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 SOFIA INIT
nua_common.c:108 nh_create_handle() nua: nh_create_handle: entering
nua.c:341 nua_handle_bind() nua: nua_handle_bind: entering
2023-03-14 23:07:38.596020 98.30% [INFO] sofia_glue.c:1654 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 sending invite call-id: (null)
2023-03-14 23:07:38.596020 98.30% [DEBUG] sofia_glue.c:1657 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 sending invite version: 1.10.9 -release-21-a615e85afc 64bit
Local SDP:
v=0
o=FreeSWITCH 1678830412 1678830413 IN IP6 EXTERNAL_IPv6
s=FreeSWITCH
c=IN IP6 EXTERNAL_IPv6
t=0 0
m=audio 30046 RTP/AVP 102 9 0 8 105 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 telephone-event/48000
a=fmtp:105 0-15
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
m=video 19748 RTP/AVP 103 104
b=AS:3072
a=rtpmap:103 H264/90000
a=rtpmap:104 VP8/90000
a=sendrecv
a=rtcp-fb:103 ccm fir
a=rtcp-fb:103 ccm tmmbr
a=rtcp-fb:103 nack
a=rtcp-fb:103 nack pli
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 ccm tmmbr
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli

nua.c:632 nua_invite() nua: nua_invite: entering
nua_stack.c:599 nua_stack_signal() nua(0x7faf30005e40): recv signal r_invite
nua_params.c:484 nua_stack_set_params() nua: nua_stack_set_params: entering
soa.c:278 soa_clone() soa_clone(static::0x7faf20001bd0, 0x7faf200013d0, 0x7faf30005e40) called
soa.c:402 soa_set_params() soa_set_params(static::0x7faf20052ff0, ...) called
soa.c:402 soa_set_params() soa_set_params(static::0x7faf20052ff0, ...) called
soa.c:1051 soa_set_user_sdp() soa_set_user_sdp(static::0x7faf20052ff0, (nil), 0x7faf30009e0d, -1) called
soa.c:889 soa_set_capability_sdp() soa_set_capability_sdp(static::0x7faf20052ff0, (nil), 0x7faf30009e0d, -1) called
nua_dialog.c:336 nua_dialog_usage_add() nua(0x7faf30005e40): adding session usage
nta.c:4497 nta_leg_tcreate() nta_leg_tcreate(0x7faf20068650)
soa.c:1301 soa_init_offer_answer() soa_init_offer_answer(static::0x7faf20052ff0) called
soa.c:1425 soa_generate_offer() soa_generate_offer(static::0x7faf20052ff0, 0) called
soa_static.c:1147 offer_answer_step() soa_static_offer_answer_action(0x7faf20052ff0, soa_generate_offer): called
soa_static.c:1188 offer_answer_step() soa_static(0x7faf20052ff0, soa_generate_offer): generating local description
soa_static.c:1216 offer_answer_step() soa_static(0x7faf20052ff0, soa_generate_offer): upgrade with local description
soa_static.c:1028 soa_sdp_mode_set() soa_sdp_mode_set(0x7faf39897840, (nil), ""): called
soa_static.c:1445 offer_answer_step() soa_static(0x7faf20052ff0, soa_generate_offer): storing local description
soa.c:1268 soa_get_local_sdp() soa_get_local_sdp(static::0x7faf20052ff0, [(nil)], [0x7faf398999d0], [0x7faf398999cc]) called
nta.c:2716 nta_tpn_by_url() nta: selecting scheme sip
tport.c:3290 tport_tsend() tport_tsend(0x7faf20006260) tpn = */[DESKPHONE_IPv6]:5060
tport.c:4076 tport_resolve() tport_resolve addrinfo = [DESKPHONE_IPv6]:5060
tport.c:4713 tport_by_addrinfo() tport_by_addrinfo(0x7faf20006260): not found by name */[DESKPHONE_IPv6]:5060
tport.c:4621 tport_by_name() tport(0x7faf20006740): found 0x7faf20054810 by name tcp/[DESKPHONE_IPv6]:5060
nta.c:8478 outgoing_try_tcp_instead() nta: INVITE (64876437) too large for UDP, trying TCP
tport.c:3290 tport_tsend() tport_tsend(0x7faf20054810) tpn = tcp/[DESKPHONE_IPv6]:5060
tport.c:3814 tport_queue() tport_queue(0x7faf20054810): queueing 0x7faf2002ed50 for tcp/[DESKPHONE_IPv6]:5060
nta.c:8400 outgoing_send() nta: sent INVITE (64876437) to tcp/[DESKPHONE_IPv6]:5060
tport.c:4191 tport_pend() tport_pend(0x7faf20054810): pending 0x7faf2002ed50 for tcp/[DESKPHONE_IPv6]:5060 (already 0)
nta.c:1369 set_timeout() nta: timer shortened to 5000 ms
nua_session.c:4131 signal_call_state_change() nua(0x7faf30005e40): call state changed: init -> calling, sent offer
soa.c:1268 soa_get_local_sdp() soa_get_local_sdp(static::0x7faf20052ff0, [0x7faf398999b0], [0x7faf398999b8], [(nil)]) called
nua_stack.c:299 nua_stack_event() nua(0x7faf30005e40): event i_state INVITE sent
nua_stack.c:389 nua_application_event() nua: nua_application_event: entering
nua.c:1170 nua_handle_unref_user() nua nua_handle_unref_user(0x7faf30005e40): entering
nua_stack.c:558 nua_signal() nua(0x7faf30005e40): 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:599 nua_stack_signal() nua(0x7faf30005e40): recv signal r_handle_unref
nua_stack.c:599 nua_stack_signal() nua((nil)): recv signal r_unref
nua_stack.c:558 nua_signal() nua(0x7faf30005e40): sent signal r_invite
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:40 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 Standard INIT
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:48 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State Change CS_INIT -> CS_ROUTING
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:624 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State INIT going to sleep
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) Running State Change CS_ROUTING (Cur 1 Tot 11)
nua.c:365 nua_handle_magic() nua: nua_handle_magic: entering
2023-03-14 23:07:38.596020 98.30% [DEBUG] sofia.c:7487 Channel sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 entering state [calling][0]
nua.c:365 nua_handle_magic() nua: nua_handle_magic: entering
nua.c:1170 nua_handle_unref_user() nua nua_handle_unref_user(0x7faf30005e40): entering
nua_stack.c:599 nua_stack_signal() nua(0x7faf30005e40): recv signal r_handle_unref
nua_stack.c:558 nua_signal() nua(0x7faf30005e40): sent signal r_handle_unref
nua.c:1157 nua_unref_user() nua: nua_unref_user: entering
nua_stack.c:599 nua_stack_signal() nua((nil)): recv signal r_unref
nua_stack.c:558 nua_signal() nua((nil)): sent signal r_unref
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:640 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State ROUTING
2023-03-14 23:07:38.596020 98.30% [DEBUG] mod_sofia.c:158 sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060 SOFIA ROUTING
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_ivr_originate.c:67 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State Change CS_ROUTING -> CS_CONSUME_MEDIA
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:640 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State ROUTING going to sleep
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) Running State Change CS_CONSUME_MEDIA (Cur 1 Tot 11)
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:659 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State CONSUME_MEDIA
2023-03-14 23:07:38.596020 98.30% [DEBUG] switch_core_state_machine.c:659 (sofia/internal-ipv6/1001@[DESKPHONE_IPv6]:5060) State CONSUME_MEDIA going to sleep
nta.c:9002 _nta_outgoing_timer() nta: timer N3 fired, try UDP instead for INVITE (64876437)
tport.c:4253 tport_release() tport_release(0x7faf20054810): 0x7faf2002ed50 by 0x7faf200bc200 with (nil)
nta.c:8525 outgoing_try_udp_instead() nta: INVITE (64876437) TCP times out, trying UDP
tport.c:2316 tport_set_secondary_timer() tport(0x7faf20054810): reset timer
tport.c:3290 tport_tsend() tport_tsend(0x7faf20006260) tpn = udp/[DESKPHONE_IPv6]:5060
tport.c:4076 tport_resolve() tport_resolve addrinfo = [DESKPHONE_IPv6]:5060
tport.c:4713 tport_by_addrinfo() tport_by_addrinfo(0x7faf20006260): not found by name udp/[DESKPHONE_IPv6]:5060
tport.c:3625 tport_vsend() tport_vsend(0x7faf20006260): 1712 bytes of 1712 to udp/[DESKPHONE_IPv6]:5060
tport.c:3526 tport_send_msg() tport_vsend returned 1712
send 1712 bytes to udp/[DESKPHONE_IPv6]:5060 at 23:07:43.602950:
------------------------------------------------------------------------
INVITE sip:1001@[DESKPHONE_IPv6]:5060 SIP/2.0
Via: SIP/2.0/UDP [EXTERNAL_IPv6];rport;branch=z9hG4bKy1mHgy9N4Drpe
Max-Forwards: 70
From: <sip:0000000000@[EXTERNAL_IPv6]>;tag=SF3eyaB09eaac
To: <sip:1001@[DESKPHONE_IPv6]:5060>

[...]

Could be your hostfile with localhost, is this debian by chance?

Yep, Debian 11.

What were you thinking could possibly cause this in relation to the hostfile? I’m assuming you mean /etc/hosts

This is my /etc/hosts:

Summary
127.0.1.1 [HOSTNAME] [HOSTNAME]
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Debian’s v6 localhost has been weirdly broken for a while, not sure its fixed, remove the v6 localhost and restart FreeSWITCH and see if it stops that.

/b

I did, but unfortunately it didn’t change anything. I can’t help but notice log messages that refer to timers, or agent timers, like these:

And the plot thickens: This morning I connected a Polycom desk phone as a second extension, and found out that calling the original Grandstream from the new Polycom works without a delay.

Digging deeper into the debug output and comparing the two call flows, I found that the delay might be either caused by, or related to this log message:

In the scenario without delay, the invite is not too large. For comparison, here is the “too large” invite:

Summary
INVITE sip:1000@[POLYCOM_IPv6]:5060 SIP/2.0
Via: SIP/2.0/UDP [EXTERNAL_IPv6];rport;branch=z9hG4bKXQNX6j130SNQH
Max-Forwards: 69
From: "Extension 1001" <sip:1001@[DOMAIN]>;tag=a703tU4egZXap
To: <sip:1000@[POLYCOM_IPv6]:5060>
Call-ID: f6e8060c-3e06-123c-01b4-5600044d67be
CSeq: 64899723 INVITE
Contact: <sip:mod_sofia@[EXTERNAL_IPv6]:5060>
User-Agent: FreeSWITCH-mod_sofia/1.10.9-release-21-a615e85afc~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 481
X-FS-Support: update_display,send_info
Remote-Party-ID: "Extension 1001" <sip:1001@[DOMAIN]>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1678881366 1678881367 IN IP6 EXTERNAL_IPv6
s=FreeSWITCH
c=IN IP6 EXTERNAL_IPv6
t=0 0
m=audio 25666 RTP/AVP 9 123 0 8 101 102
a=rtpmap:9 G722/8000
a=rtpmap:123 opus/48000/2
a=fmtp:123 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40; stereo=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:102 telephone-event/48000
a=fmtp:102 0-15
a=ptime:20

And here is the invite coming from the Polycom, that fits within the “maximum size”:

Summary
INVITE sip:1001@[[GRANDSTREAM_IPv6]]:5060 SIP/2.0
Via: SIP/2.0/UDP [[EXTERNAL_IPv6]];rport;branch=z9hG4bKvev44Qg03gZ4N
Max-Forwards: 69
From: "Extension 1000" <sip:1000@[DOMAIN]>;tag=5S27HmgXyjeDc
To: <sip:1001@[[GRANDSTREAM_IPv6]]:5060>
Call-ID: e793cb55-3e06-123c-01b4-5600044d67be
CSeq: 64899710 INVITE
Contact: <sip:mod_sofia@[[EXTERNAL_IPv6]]:5060>
User-Agent: FreeSWITCH-mod_sofia/1.10.9-release-21-a615e85afc~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 272
X-FS-Support: update_display,send_info
Remote-Party-ID: "Extension 1000" <sip:1000@[DOMAIN]>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1678882242 1678882243 IN IP6 [EXTERNAL_IPv6]
s=FreeSWITCH
c=IN IP6 [EXTERNAL_IPv6]
t=0 0
m=audio 24764 RTP/AVP 9 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

So it seems to me that, due to the extra codec definitions in the SDP coming from Grandstream, FS decides that the packet is “too large” (MTU?), and goes on to try TCP which somehow ends up resulting in a 5 second delay, before ultimately sending the whole thing via UDP anyway.

This must be the same thing that happens when I originate the calls from fs_cli. The INVITE packet is deemed “too large” by FS, and goes through the whole “trying TCP”-Spiel, resulting in the delay.

Now what I don’t know is:

  • Why does FS try TCP? The extension is specifically registered via UDP and FS is aware of this.
  • Why, if UDP ultimately ends up working anyway, does FS hang itself up waiting for the TCP connection to time out.

It seems to me that FS should only try to send the INVITE over TCP if it knows the endpoint is reachable via TCP; especially if UDP works anyway, even when the packet is deemed “too large”.

Does anyone have insight into this FS behavior / what can be done to prevent this?

Hi @mo1

During various testing in our environment we noticed similar results, especially with varying result depending on the make and the model of the handsets. After some digging there was 2 fixes (although I cant find the details online to share with you) from memory one was a change to the C code but the other which worked well for us was

setting the below at the end of vars.xml

<X-PRE-PROCESS cmd="set" data="rtp_notimer_during_bridge=false"/>

I dont know if you are having the exact same issue however it has striking similarities especially with the 5s delay.

Worth a quick test.

Lewis

What distro are you on?

/b