Hi Joshua,
You're right, it was a firewall problem. One of those things where testing
a change in one place throws up a previously unseen problem somewhere else!
Thanks for the tip.
On Thu, 19 May 2022 at 21:18, Joshua C. Colp wrote:
> On Thu, May 19, 2022 at 6:04 AM David Cunningham <
>
On Thu, May 19, 2022 at 6:04 AM David Cunningham
wrote:
> Hi Dovid and Joshua,
>
> The PSTN is sending RTP immediately after the 200 OK, on both legs of the
> call. Since the PCAP taken on the Asterisk server itself shows this RTP
> from the PSTN then presumably it can't be a network issue
Hi Dovid and Joshua,
The PSTN is sending RTP immediately after the 200 OK, on both legs of the
call. Since the PCAP taken on the Asterisk server itself shows this RTP
from the PSTN then presumably it can't be a network issue preventing the
RTP.
Having said that, the problem is not reproduced
On Thu, May 19, 2022 at 3:52 AM Dovid Bender wrote:
> David,
>
> Are you getting any RTP from the PSTN for either leg? If not it could be
> that they assume you are behind NAT and want to see where the SRC of the
> RTP before they send it back. We had a few carriers that did this. The
> easiest
David,
Are you getting any RTP from the PSTN for either leg? If not it could be
that they assume you are behind NAT and want to see where the SRC of the
RTP before they send it back. We had a few carriers that did this. The
easiest way to get around it was to play a 0.5 second audio clip to the
We found that the 10 seconds relates to the "rtpkeepalive =10" in our
sip.conf. If the rtpkeepalive is reduced then the delay reduces as well. If
rtpkeepalive is removed from sip.conf then audio never starts flowing.
Does that help anyone make sense of what's happening?
We have DAHDI running on
