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 ) 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?
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.
) 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?
