This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)".
The branch, zecke/fixes/mgcp-rtp-stats has been created
at 3a912d3f6ec53b907fe7f8f1b1f494807f2b468d (commit)
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openbsc/commit/?id=3a912d3f6ec53b907fe7f8f1b1f49480…
commit 3a912d3f6ec53b907fe7f8f1b1f494807f2b468d
Author: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
Date: Tue Sep 15 19:30:40 2015 +0200
mgcp: Align the code closer to Annex A and introduce bad_seq
Introduce the bad_seq handling that is dealing with a very
long sequence number jump. The only missing part is the
probation handling that is of not that much interest right
now.
Change the initialization sequence, in case of a new SSRC
re-set the jitter and transit time calculation to an initial
value. The sender might be a different system that takes a
different path so the average jitter does not make that
munch sense.
http://cgit.osmocom.org/openbsc/commit/?id=fb51539951c3e2e49497ad35c5032647…
commit fb51539951c3e2e49497ad35c5032647dd924fd6
Author: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
Date: Tue Sep 15 18:49:47 2015 +0200
mgcp: Change order and types of varriables to follow the Annex
http://cgit.osmocom.org/openbsc/commit/?id=7b311ba8068dbf889535ccbedc3ea313…
commit 7b311ba8068dbf889535ccbedc3ea3131905abd5
Author: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
Date: Tue Sep 15 18:35:07 2015 +0200
mgcp: Move the max_seq assignment into each branch
The initialization would put max_seq to seq - 1 while init_seq
of the annex does not. Move the max_seq assignment into all the
branches.
http://cgit.osmocom.org/openbsc/commit/?id=2d7298182db8ce8ed84749c89e82f412…
commit 2d7298182db8ce8ed84749c89e82f412cacda60f
Author: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
Date: Tue Sep 15 18:30:26 2015 +0200
mgcp: Make the packet loss calculation per session
Somehow we end up with calculations of 65536 for the packet loss
that is RTP_SEQ_MOD. So there might have been a sequence overflow
but no packets to count against it. I have no idea how this can
happen and could not reproduce it. But when we change the SSRC
we should re-initialize the state. Separate the total packets and
octets from the packets we count per SSRC.
Related: OW#1489
-----------------------------------------------------------------------
hooks/post-receive
--
The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)