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 <
>
The Asterisk Development Team would like to announce the release of Asterisk
19.4.1.
This release is available for immediate download at
https://downloads.asterisk.org/pub/telephony/asterisk
The release of Asterisk 19.4.1 resolves an issue reported by the
community and would have not been
The Asterisk Development Team would like to announce the release of Asterisk
18.12.1.
This release is available for immediate download at
https://downloads.asterisk.org/pub/telephony/asterisk
The release of Asterisk 18.12.1 resolves an issue reported by the
community and would have not been
The Asterisk Development Team would like to announce the release of Asterisk
16.26.1.
This release is available for immediate download at
https://downloads.asterisk.org/pub/telephony/asterisk
The release of Asterisk 16.26.1 resolves an issue reported by the
community and would have not been
On Thu, May 19, 2022 at 1:18 PM Dan Cropp wrote:
> After further testing, not sure this is chan_sip related.
>
>
>
> I can disable chan_sip.so from loading in modules.conf and that does solve
> the startup/loading for res_pjsip_transport_websocket.
>
> However, there is some issue with the wss
After further testing, not sure this is chan_sip related.
I can disable chan_sip.so from loading in modules.conf and that does solve the
startup/loading for res_pjsip_transport_websocket.
However, there is some issue with the wss transport. Seeing this in both
16.26.0 (not in 16.25.0) and
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
10 matches
Mail list logo
