macOS: Call allocation always uses AF_UNSPEC with regint=0 accounts, ignoring net_af and mediaaf settings

[svengerhardt]

macOS: Call allocation always uses AF_UNSPEC with regint=0 accounts, ignoring net_af and mediaaf settings

Summary

On macOS, outgoing calls from local accounts (regint=0) always use AF_UNSPEC for RTP socket allocation, regardless of net_af ipv4 in config or mediaaf=ipv4 in account parameters. This causes getaddrinfo failures and prevents call establishment.

Environment

• baresip version: 4.5.0
• Operating System: macOS (tested on macOS with Wi-Fi interface en0)
• Installation method: from source (/usr/local/lib/baresip/modules/)
• Use case: Connecting to LiveKit SIP server without registration (regint=0)

Problem Description

When initiating an outgoing call, baresip always allocates the call with:

call: alloc with params laddr=?, af=AF_UNSPEC, use_rtp=1

This causes RTP socket creation to fail on macOS because getaddrinfo cannot resolve ?:0 with AF_UNSPEC:

sa: sa_set_port: no af 0 (port 22030)
udp: listen: getaddrinfo: ?:0 (nodename nor servname provided, or not known)
stream: rtp_listen failed: af=AF_UNSPEC ports=22000-22100 (Can't assign requested address [49])

The expected behavior would be:

call: alloc with params laddr=192.168.2.102, af=AF_INET, use_rtp=1

Configuration

config file (~/.baresip/config)

module_path /usr/local/lib/baresip/modules/

module stdio.so
module debug_cmd.so
module uuid.so
module_app menu.so

module coreaudio.so
ausrc  coreaudio
auplay coreaudio

module g711.so
module opus.so
audio_codecs pcmu/8000,pcma/8000,opus/48000/2

module srtp.so
module ice.so
module stun.so

stun_server stun:74.125.250.129:19302
rtp_ports 22000-22100

module account.so

sip_listen 192.168.2.102:5060
sip_transports tcp
sip_trans_def tcp

# Attempting to force IPv4
net_af ipv4
net_interface en0
dns_server 8.8.8.8:53

accounts file (~/.baresip/accounts)

<sip:tester@xxx.sip.livekit.cloud>;auth_pass=tester;regint=0;sipnat=outbound;outbound="sip:xxx.eu.sip.livekit.cloud;transport=tcp";mediaenc=srtp-mand;medianat=ice;stunserver="stun:74.125.250.129:19302";mediaaf=ipv4

Steps to Reproduce

1. Configure baresip with the above config and account on macOS
2. Start baresip: baresip -v
3. Verify network detection shows IPv4:

   Local network addresses:
           en0:  192.168.2.102
   uag: add local address 192.168.2.102
   

4. Initiate a call:

   /dial sip:+49123456789@xxx.sip.livekit.cloud;transport=tcp
   

5. Observe the failure

Full Startup Log

baresip v4.5.0 Copyright (C) 2010 - 2025 Alfred E. Heggestad et al.
Local network addresses:
        en0:  192.168.2.102
uag: add local address 192.168.2.102
ui: stdio
uuid: loaded UUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx from file /Users/sven/.baresip/uuid
auplay: coreaudio
ausrc: coreaudio
aucodec: PCMU/8000/1
aucodec: PCMA/8000/1
opus: fmtp="stereo=1;sprop-stereo=1"
aucodec: opus/48000/2
mediaenc: srtp
mediaenc: srtp-mand
mediaenc: srtp-mandf
medianat: ice
medianat: stun
using stunserver: 'stun:74.125.250.129:19302'
ua: contact user tester
tester@xxx.sip.livekit.cloud: Using sipnat: 'outbound'
tester@xxx.sip.livekit.cloud: Using medianat 'ice'
tester@xxx.sip.livekit.cloud: Using media encryption 'srtp-mand'
Populated 1 account
module: loading app menu.so
Populated 3 audio codecs
Populated 0 audio filters
Populated 0 video codecs
Populated 0 video filters
baresip is ready.

Full Dial Failure Log

/dial sip:+49123456789@xxx.sip.livekit.cloud;transport=tcp
tester@xxx.sip.livekit.cloud: selected for request
call uri: sip:+49123456789@xxx.sip.livekit.cloud;transport=tcp
call: alloc with params laddr=?, af=AF_UNSPEC, use_rtp=1
ice: new session with STUN-server at 74.125.250.129 (username=)
ice: resolved STUN-server to address 74.125.250.129:19302
call: use_video=0
call: connecting to 'sip:+49123456789@xxx.sip.livekit.cloud;transport=tcp'..
sa: sa_set_port: no af 0 (port 22030)
udp: listen: getaddrinfo: ?:0 (nodename nor servname provided, or not known)
sa: sa_set_port: no af 0 (port 22024)
udp: listen: getaddrinfo: ?:0 (nodename nor servname provided, or not known)
sa: sa_set_port: no af 0 (port 22046)
udp: listen: getaddrinfo: ?:0 (nodename nor servname provided, or not known)
[... repeats for all ports in range ...]
stream: rtp_listen failed: af=AF_UNSPEC ports=22000-22100 (Can't assign requested address [49])
stream: failed to create socket for media 'audio' (Can't assign requested address [49])
audio: destroyed (started=0)
ua_connect failed: Can't assign requested address [49]

UA Status Output (/uastat)

Note: mediaaf=ipv4 appears in the address string but is not parsed as a separate parameter (no mediaaf: line in output):

/uastat
--- sip:tester@xxx.sip.livekit.cloud ---
 nrefs:     1
 cuser:     tester
 pub-gruu:  
 Supported: ice,gruu,path,outbound,replaces,norefersub

Account:
 address:      <sip:tester@xxx.sip.livekit.cloud>;auth_pass=tester;regint=0;sipnat=outbound;outbound="sip:xxx.eu.sip.livekit.cloud;transport=tcp";mediaenc=srtp-mand;medianat=ice;stunserver="stun:74.125.250.129:19302";mediaaf=ipv4
 luri:         sip:tester@xxx.sip.livekit.cloud
 aor:          sip:tester@xxx.sip.livekit.cloud
 dispname:     
 100rel:           no
 answerdelay:      0
 answermode:       manual
 autoredirect:     no
 autelev_pt:       0
 auth_user:        
 call_transfer:    yes
 catchall:         no
 cert:             
 check_origin  yes
 dtmfmode:         rtpevent
 extra:            none
 inreq_allowed:    yes
 mediaenc:         srtp-mand
 medianat:         ice
 mwi:              yes
 natpinhole:       no
 outbound1:        sip:xxx.eu.sip.livekit.cloud;transport=tcp
 ptime:            20
 prio:             0
 pubint:           0
 regint:           0
 regq:             
 rtcp_mux:         no
 sipnat:           outbound
 stunuser:         
 stunserver:       scheme=stun host='74.125.250.129' port=19302 proto=UDP
 sipans:           no
 sipansbeep:       on
 sip_autoredirect: no

Network Status (/netstat)

/netstat
--- Network debug ---
enabled interfaces:
        en0:  192.168.2.102 (default)
 DNS Servers from System: (3)
   0: 192.168.2.1:53
   1: [fd00::1]:53
   2: [2001:db8::1]:53

Attempted Workarounds (all failed)

1. net_af ipv4 in config - Network layer detects IPv4 correctly, but call allocation still uses AF_UNSPEC

2. mediaaf=ipv4 in account - Parameter appears in address string but is not parsed (no mediaaf: in /uastat output)

3. dns_server 8.8.8.8:53 in config - Does not affect call allocation

4. Disabling IPv6 on macOS system level:

   sudo networksetup -setv6off Wi-Fi

   Still results in AF_UNSPEC - the problem is in baresip's call allocation logic, not system network configuration

5. Using STUN server IP directly (avoiding DNS lookup) - STUN resolves correctly but call allocation still fails

Analysis

The issue appears to be in the call allocation path for regint=0 (local/peer-to-peer) accounts:

1. The network layer correctly detects and uses AF_INET (IPv4) - visible in startup log
2. The account is created but mediaaf parameter is not being parsed from the account string
3. When ua_connect() is called, the address family is not inherited from the network layer or account settings
4. The call is allocated with AF_UNSPEC, which fails on macOS when trying to bind RTP sockets

According to the wiki documentation, mediaaf should be a valid account parameter:

mediaaf={ipv4,ipv6,auto} - default: auto which means same address family like the SIP registration, or ipv4 for registrar-less accounts if ipv4 is available.

However, the parameter does not appear in the parsed account output, suggesting it may have been removed or renamed in version 4.x.

Expected Behavior

For regint=0 accounts on a system with only IPv4 configured (or with net_af ipv4), calls should be allocated with:

call: alloc with params laddr=192.168.2.102, af=AF_INET, use_rtp=1

Possible Fix Locations

• src/call.c - call_alloc() function where laddr and af are determined
• src/ua.c - ua_connect() where the call parameters are set up
• src/account.c - Parsing of mediaaf parameter (if it should still be supported)

Related Issues

This may be related to the changes in PR #1618 "ua: select proper af and laddr for outgoing IP calls" and PR #1590 "ua: select laddr with route to SDP offer address", which addressed similar issues on Linux.

Workaround Request

Is there any other configuration option to force IPv4 for call allocation that I may have missed?

[sreimers]

regint=0 is for registrar less accounts, but looks like you want to use a proxy:

<sip:tester@xxx.sip.livekit.cloud>;auth_pass=tester;regint=0;sipnat=outbound;outbound="sip:xxx.eu.sip.livekit.cloud;transport=tcp";mediaenc=srtp-mand;medianat=ice;stunserver="stun:74.125.250.129:19302";mediaaf=ipv4

And please don't make any assumptions with AI generated bug reports. A clear log, config and short description of the problem is enough.