I’m trying to interface with a Rauland Campus Controller via SIP trunk. Unfortunately, this device doesn’t seem to want to send an OK response to SIP ACK (even though it responds to INVITE fine). Is there some way to configure the trunk to ignore the missing ACK or otherwise mitigate this issue? Both devices are on the LAN, no firewalls are involved, I’m pretty sure it’s just these controllers are pretty stubborn in how they expect to communicate.
The ACK is a required part of successful call setup - the controller isn’t being stubborn. A complete SIP capture would be helpful if you are able to share it.
Your pcap shows the Rauland starts sending audio, then stops. FreePBX sends audio the whole time. And the SIP interaction looks fine. Both sides are using internal IP addresses for both signaling and media which is probably what you want.
There is (apparently) nothing wrong with the SIP. However (at the point you took the pcap), the Rauland asks for audio to be sent to port 57226 and Asterisk dutifully complies, but Rauland sends audio from port 60809. It is presumably also listening on 60809, doesn’t ‘hear’ audio from Asterisk and stops sending after two seconds, just after the beep.
I suspect that either some networking device between the systems is rewriting the port numbers, or the Rauland is somehow misconfigured.
If the pcap was taken on the PBX, I’d expect Asterisk to see audio from 60809 and start sending there., as (assuming a pjsip trunk) RTP Symmetric is on by default. If you are using chan_sip, please explain.
If you still have trouble, post a screenshot of your trunk settings, as well as pasting the Asterisk log for a failed call, including SIP trace, at pastebin.freepbx.org . Post the link here.
Tons of great feedback here. Really appreciate it.
Clearly misunderstood how the handshake works, now I won’t bother trying to troubleshoot a missing OK that shouldn’t exist!
Pcap is taking right from the PBX using tcpdump
I ‘inherited’ a legacy PBX running a pretty (scratch that, VERY) old version of FreePBX (2.11), so the trunk is chan_sip. Clearly I should be looking to upgrade that ASAP! Just thought it might be possible to troubleshoot this issue first before moving in that direction.
The log is consistent with Stewart’s analysis, with the PBX dropping the call due to no RTP stream back. We’re using the Rauland as a one way paging interface to some local speakers, so I wouldn’t actually expect any audio back from the Rauland (besides the initial page tone), but I’m assuming it would still expect that RTP stream to maintain the connection? [2023-01-20 08:06:06] NOTICE[2225] chan_sip.c: Disconnecting call 'SIP/pagingtrunk-00050904' for lack of RTP activity in 31 seconds
Nothing should be rewriting ports in the network path (PBX > switch > private MPLS > switch > rauland), but it wouldn’t surprise me if the Rauland had some quirks about how to interact with it.
Just for laughs, try
nat=comedia
in your trunk settings (even though there is no NAT).
If it doesn’t help, check whether it does what I hope, i.e. sends RTP (the page you are trying to make) back to the Rauland to the same port from which the Rauland is sending its RTP.
Seems like the PBX is sending the RTP stream where the Rauland asks for it, which you previously mentioned (rauland sends SIP SDP body with m = audio 57204 RTP/AVP 0 101 which I assume means “send your page audio to port 57204”) PBX complies and never sends audio to where the Rauland is sending it’s audio from (60809).
I may just brute-force this and set the RTP timeout to 300 seconds instead of 30 in the PBX SIP settings for now until I can get upgraded to a modern verison (and pjsip) and see if that doesn’t fix things.