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=3a912d3f6ec53b907fe7f8f1b1f494807... commit 3a912d3f6ec53b907fe7f8f1b1f494807f2b468d Author: Holger Hans Peter Freyther <holger@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=fb51539951c3e2e49497ad35c5032647d... commit fb51539951c3e2e49497ad35c5032647dd924fd6 Author: Holger Hans Peter Freyther <holger@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=7b311ba8068dbf889535ccbedc3ea3131... commit 7b311ba8068dbf889535ccbedc3ea3131905abd5 Author: Holger Hans Peter Freyther <holger@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=2d7298182db8ce8ed84749c89e82f412c... commit 2d7298182db8ce8ed84749c89e82f412cacda60f Author: Holger Hans Peter Freyther <holger@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)