Sporadic - Maybe One Way Audio - Cannot Confirm FMFM Calls

FreePBX 16

We have a call flow that sends calls to user’s cell phones (via FMFM) and uses call confirm to ensure we do not send calls to user’s personal voicemail. Sporadically the user will get the call and press 1, but the call will not connect, eventually timing out. When I look at the logs, I see as much. And when I look at sngrep, I see as much (missing RTP). I know (from this forum :slight_smile: ) that the most common answer is port mismatch. Maybe since it is sporadic the port range is not aligning perfectly creating the intermittent issue? Maybe this is another issue entirely? I am using 10000-20000 on the FreePBX box. Can anyone help me narrow the specific issue?

sngrep of working call:

sngrep of no RTP call (pressing 1 does not connect the call):

Pastebin of no RTP call (pressing 1 does not connect the call):

Thanks in advance!

Anyone have any ideas on this?

One last bump, I’ll do a deeper dive and post back anything I find here.

There is nothing wrong from the Asterisk end. The other end is using relatively low port numbers for the RTP; could it be blocking some of them?

PS. You might want to look at linux - Why does YaST now show lines as lqqqqqqqqqqqqqqq? - Super User and Graphic is characters rather than dashes and arrows · Issue #236 · irontec/sngrep · GitHub to see if you can get sngrep to display corrrectly.

@comtech Please close one of your threads. There is never a need for two threads opened by the same author for the same topic.

I just got a chance to look at the pastebin from your first post.

Very strange; the call has no 200 OK (it was apparently not answered), but on line 108, Asterisk sent an ACK. The 183 and 180 would not be ACKed. So it appears that Asterisk thought it received a 200. And the following BYE sequence is consistent with the call having been answered.

So I suspect that the capture was somehow corrupted. But it’s hard to tell, because the SIP trace doesn’t include the Asterisk log for the call. Do you have that? How did you make the trace?

The multiple threads make it awkward to get that log, but as I recall this was correct. CANCEL generates an immediate OK, for the CANCEL transaction, but also causes a final response for the original INVITE. It is that latter that is being ACKed.

Yes, Ill post the logs too.

But there is no CANCEL, 200 OK response, or 487 response to the INVITE. And in any case, BYE would be inappropriate after that.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.