Be careful of what you put in Settings->SIP Settings->Stun Server Address. An unresponsive STUN Server can cause incoming calls from standard, registered SIP trunks to fail.
This may be old news to some, but caused me grief this week.
Had a site experimenting with UCP/WebRTC support.
Performance had been solid for months, but we started getting incoming call "hangups" and CHANUNAVAIL alerts from Vitelity. At first very sporadically and infrequently, but really bad the past week or so. Testing showed the same behavior with other providers as well.
Turns out the STUN server from whatever source I was referencing when setting WebRTC up started failing and timing out. Asterisk was retrying STUN four times during call setup. By the time asterisk gave up and continued, the provider had failed the call.
Moral of the story - if non-blank, the STUN Server setting is critical even for registered trunks, even if it isn't really needed for a particular call. If set, make sure it is a 100% uptime server with fast response. I personally will not use the setting again without a separate job running to monitor status and responsiveness of the server.
This may be old news to some, but caused me grief this week.
Had a site experimenting with UCP/WebRTC support.
Performance had been solid for months, but we started getting incoming call "hangups" and CHANUNAVAIL alerts from Vitelity. At first very sporadically and infrequently, but really bad the past week or so. Testing showed the same behavior with other providers as well.
Turns out the STUN server from whatever source I was referencing when setting WebRTC up started failing and timing out. Asterisk was retrying STUN four times during call setup. By the time asterisk gave up and continued, the provider had failed the call.
Moral of the story - if non-blank, the STUN Server setting is critical even for registered trunks, even if it isn't really needed for a particular call. If set, make sure it is a 100% uptime server with fast response. I personally will not use the setting again without a separate job running to monitor status and responsiveness of the server.
Last edited: