asterisk users - May 2022 - No audio for 10 seconds and then comfort noise

On Thu, May 19, 2022 at 3:52 AM Dovid Bender <dovid at telecurve.com>
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 way to get around it was to play a 0.5 second audio clip to the
> incoming leg. This will send RTP to the inbound carrier, causing them to
> send RTP back to you which would then hit the terminating carrier, which
> then sends you back RTP completing the loop. The dialplan looks
> something like this.
>
> same =>                n, Progress()
> same =>                n,
> Playback(/var/lib//asterisk_custom/sounds/xc,noanswer)
> same =>                n, Dial(SIP/+${EXTEN}@carrier,,)
>
I've also seen this happen due to networking equipment, specifically the
equipment wanting Asterisk to send packets before allowing packets in. If
both sides of the call are in this state, then you reach a stalemate and
media won't flow. Since rtp_keepalive is generated by Asterisk, it gets
sent, and media starts flowing.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20220519/be719e41/attachment.html>

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 when the peer is another
Asterisk server on the same network, and that does point to a network
difference.

Is there any other way in which the RTP keepalive might affect Asterisk's
behaviour?

Thanks for your help on this.


On Thu, 19 May 2022 at 20:40, Joshua C. Colp <jcolp at sangoma.com> wrote:
> On Thu, May 19, 2022 at 3:52 AM Dovid Bender <dovid at telecurve.com>
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 way to get around it was to play a 0.5 second audio clip to the
>> incoming leg. This will send RTP to the inbound carrier, causing them
to
>> send RTP back to you which would then hit the terminating carrier,
which
>> then sends you back RTP completing the loop. The dialplan looks
>> something like this.
>>
>> same =>                n, Progress()
>> same =>                n,
>> Playback(/var/lib//asterisk_custom/sounds/xc,noanswer)
>> same =>                n, Dial(SIP/+${EXTEN}@carrier,,)
>>
>
> I've also seen this happen due to networking equipment, specifically
the
> equipment wanting Asterisk to send packets before allowing packets in. If
> both sides of the call are in this state, then you reach a stalemate and
> media won't flow. Since rtp_keepalive is generated by Asterisk, it gets
> sent, and media starts flowing.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users


-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20220519/64b36798/attachment.html>