[asterisk-bugs] [JIRA] (ASTERISK-25629) [patch] Native Packet-Loss Concealment (PLC)

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-25629:
---------------------------------------

    Affects Version/s:     (was: 13.6.0)
                           (was: 11.20.0)
                       11.21.0
                       13.7.0

> [patch] Native Packet-Loss Concealment (PLC)
> --------------------------------------------
>
>                 Key: ASTERISK-25629
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25629
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/codec_ilbc, Codecs/codec_speex, Codecs/General
>    Affects Versions: 11.21.0, 13.7.0
>            Reporter: Alexander Traud
>            Assignee: Alexander Traud
>            Severity: Minor
>         Attachments: native_plc.patch
>
>
> In VoIP/SIP, the RTP media is transferred not via reliable TCP but [UDP|https://en.wikipedia.org/wiki/User_Datagram_Protocol#Comparison_of_UDP_and_TCP]. This makes sure the data arrives as fast as possible. However, because of the use of UDP, packets might never arrive or take another route via the Internet. Therefore, one packet might be faster than previous packets. Or stated differently: Packets might arrive late. In both cases, those packets are lost because they cannot be used to re-build the media stream.
> Therefore, VoIP specific audio-codecs like iLBC, Speex, and SILK/Opus are able to conceal lost packets. This is called Packet-Loss Concealment (PLC). In this case, it is called native PLC, because no additional source code must be written, but the underlying library supports this already. Additionally, Asterisk offers generic PLC while writing Signed-Linear.
> To conceal packet-loss, the codec library must be aware that a packet got lost. Furthermore because RTP packets inter-depent, late packets must not be forwarded to the library not to confuse its state. If a late packet arrives, the library would not know that it has to discard it, because the library does not know its RTP sequence number. The VoIP application – in our case Asterisk – has to discard late packets and indicate lost packets to the library. This is true for iLBC, Speex, SILK, and Opus Codec.
> Long story short: In contrast to [the documentation|https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=5243109], native PLC does not happen. Without or with a jitter buffer.
> All Long-Term-Support releases (including Asterisk 1.8.32.3, Asterisk 1.4.44, and Asterisk 1.2.40) were re-tested with a simple setup: Two Wi-Fi access points bridged via Ethernet to the same DHCP server, using the same SSID, and just WPA2-Personal but sending on different 2,4 GHz channels (Wi-Fi Roaming). Plus a Wi-Fi enabled VoIP/SIP client, moving around those access point. Whenever the Wi-Fi client changes the access point, it has to authenticate again. That creates packet loss of about one to several dozen packets. In those Asterisk releases, their iLBC transcoding module was passed. The backtrace is
> main/channel.c:ast_read(.)
>   main/translate.c:ast_translate(.)
>     main/translate.c:framein(.)
>       codecs/codec_ilbc.c:framein(.)
> but native PLC was not done, because there was no indication of lost packets. Furthermore, late packets were not dropped but forwarded as usual packets. Those packets with unexpected RTP sequence numbers were double-checked via Wireshark » Menu » Telephony » RTP » Show All Streams » Analyse » Next non-OK.



--
This message was sent by Atlassian JIRA
(v6.2#6252)