# A host name in external\_signaling\_address can silently resolve to 127.0.1.1 (no audio, calls drop at 32 s) **URL:** \ **Category:** Asterisk SIP\ **Created:** [October 15, 2026, 5:19pm UTC](https://community.asterisk.org/t/a-host-name-in-external-signaling-address-can-silently-resolve-to-127-0-1-1-no-audio-calls-drop-at-32-s/114796 "2026-10-15T17:19:37Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![keshavdutt](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/keshavdutt/32/10270_2.png) [@keshavdutt](https://community.asterisk.org/u/keshavdutt)\ **Post date:** [October 15, 2026, 5:19pm UTC](https://community.asterisk.org/t/a-host-name-in-external-signaling-address-can-silently-resolve-to-127-0-1-1-no-audio-calls-drop-at-32-s/114796/1 "2026-10-15T17:19:37Z")
Posting this one because the symptom pointed in completely the wrong direction and it cost us a day. **Setup:** Asterisk 22 on Ubuntu on a cloud VM, PJSIP, one UDP transport with `external_signaling_address` and `external_media_address` set to the box’s own **host name** instead of its public IP. **Symptom:** calls were set up and answered, no audio in either direction, and every call ended at exactly 32 seconds with no BYE from the far end. `pjsip show channelstats` showed 0 RTP received _and_ 0 sent on _both_ legs, including a desk phone on the same LAN as Asterisk — which is what sent us hunting an SRTP/codec problem that did not exist. **Cause:** Debian and Ubuntu put ```auto 127.0.1.1 my-host-name ``` in `/etc/hosts`. Asterisk resolves the name in `external_signaling_address` / `external_media_address` through the normal resolver, so it got `127.0.1.1` and put that on the wire: `c=IN IP4 127.0.1.1` in the SDP and `127.0.1.1` in the `Contact:`. Media went nowhere, and the ACK — and later the BYE — was addressed to the far end’s _own_ loopback, so the 200 OK was retransmitted until timer H gave up: 64 × T1 = 32 s. Hence the suspiciously round `billsec=32`. **Confirming it in a minute:** - `pjsip show transports` prints the _configured_ value, not what it resolved to, so it looks perfectly fine. Look at the wire instead: `pjsip set logger host `, place a call, and read the `Contact:` and `c=` lines of the INVITE. - `getent hosts $(hostname)` on the box. If that answers `127.0.1.1`, that is what Asterisk saw. **Fixes:** - Put an IP literal in `external_signaling_address` / `external_media_address`. A name is resolved once when the transport is loaded and transports cannot be reloaded, so a name buys you nothing anyway: a changed address needs a restart either way. - If a script writes that config, take the address from a resolver that cannot see `/etc/hosts` — `dig +short @1.1.1.1 ` — rather than `hostname -I`, `getent` or `hostname -f`. - Check `local_net` covers every network that really is local. A handset on the office wi-fi that hairpins through the public IP counts as _outside_ it. Two things I would do differently next time: no RTP in **either** direction on **both** legs means Asterisk is not even trying to send to a reachable address, so read the SDP before looking at media; and any host name in `pjsip.conf` on a Debian-family box deserves a `getent` check before anything else. ---
**Author:** ![Rob](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@Rob](https://community.asterisk.org/u/Rob)\ **Post date:** [October 16, 2026, 7:19am UTC](https://community.asterisk.org/t/a-host-name-in-external-signaling-address-can-silently-resolve-to-127-0-1-1-no-audio-calls-drop-at-32-s/114796/2 "2026-10-16T07:19:52Z")
Hi there If I understand correctly, this won’t happen if you set host name, domain and IP address during install; > **[5.1.1. The hostname resolution - Chapter 5. Network setup](https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution)** > > The hostname resolution is currently supported by the NSS (Name Service Switch) mechanism too. The flow of this resolution is the following. Regards, Rob