The Asterisk Development Team would like to announce the release of Asterisk
13.19.1.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk
The release of Asterisk 13.19.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
15.2.1.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk
The release of Asterisk 15.2.1 resolves an issue reported by the
community and would have not been
On 2/13/18 1:36 PM, Jonathan H wrote:
Um, I may be missing something here, but if it was "percent", wouldn't
it simply be the internationally recognised symbol for percent, the,
um, percent symbol? %
16641/188 = 8852% is not quite 8809% but I suspect it is just a rounding
issue. Of couse it
On 2/13/18 1:32 PM, Eric Wieling wrote:
Could this gap in sequence numbers caused by a codec change generate
errors like the one below?
Yes, that is something I have seen before as well. The CPE changes
codec and forgets what sequence number it was on (or something like
that). The two ends
Um, I may be missing something here, but if it was "percent", wouldn't it
simply be the internationally recognised symbol for percent, the, um,
percent symbol? %
That's why I don't think it can be percent.
On 13 February 2018 at 18:32, Eric Wieling wrote:
> Could this gap
Could this gap in sequence numbers caused by a codec change generate
errors like the one below?
[2018-02-13 12:57:43] WARNING[4917][C-0004c2cb] codec_sangoma.c:
[526559][g722toulaw] Got Seq 15944 but expecting 10106 (time since last
read = 0ms), dropped 5838 packets
On 02/13/2018 01:24 PM,
On 2/13/18 11:55 AM, Michael Maier wrote:
On 02/13/2018 at 08:41 AM Floimair Florian wrote:
No you're reading it wrong.
There are 188K received with no loss, and 16441K transmitted.
This doesn't make any sense to me, either. There can't be more packages
transmitted than received. It's the
On 02/13/2018 at 08:41 AM Floimair Florian wrote:
> No you're reading it wrong.
>
> There are 188K received with no loss, and 16441K transmitted.
This doesn't make any sense to me, either. There can't be more packages
transmitted than received. It's the same codec in and out and it's been