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, jolly/32c3 has been updated
discards f7637bc5155e14aabdcae1d3271a43ebbade6ef8 (commit)
discards 4d255e2aaacda06f042abb14e2e0117a8d2eb269 (commit)
discards de522c78ca8b4b225b4df880d7e28faa8134f3ad (commit)
discards ab56d32c57c670084bc009757651db9127d005b5 (commit)
discards 60eefc6620cd709a7d3d26d55209168812726156 (commit)
discards df202379cb69eaa7ab12a9f568177436aae67129 (commit)
discards b113b0bd35c9f964c1d513cde917d55aef9baf18 (commit)
discards d3ae9498a8d26fb1583f992dd64b734a6f98018c (commit)
discards c42af135521031ba061a31bd256529972e078fbe (commit)
discards fd0b0528be9cec102239e4ec935101e1bf110f82 (commit)
discards 7ef67185e692f2dff75d5c3952cc15dbd6586bb0 (commit)
discards fbc3393bee719c8c4723cb089635ccb804a12464 (commit)
discards 08f433e1a3e7d2c6e9d1244fb3d63266b69e2409 (commit)
discards 00bfaf0f96d7899790d89f9d2605b40cf445bb03 (commit)
via 5724fb76169008c7f7d6bf8ffedbe2a4a78f8e00 (commit)
via a964c3e894e13530d17eff50d3903d8ac968bb37 (commit)
via c155ea7240776a151e763ea50bceeb57fcf48ffd (commit)
via d4cde09829cfce77a1dd553b5b8ad1074c93b9b6 (commit)
via 4622fbe25d9a8a0d03e260f5d3fcf1669c996d00 (commit)
via fa032ac8b3c1f49c908dcd5380b48f198439494e (commit)
via 990b41308770426eec50cbee6ac5f270f93afee2 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (f7637bc5155e14aabdcae1d3271a43ebbade6ef8)
\
N -- N -- N (5724fb76169008c7f7d6bf8ffedbe2a4a78f8e00)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openbsc/commit/?id=5724fb76169008c7f7d6bf8ffedbe2a4…
commit 5724fb76169008c7f7d6bf8ffedbe2a4a78f8e00
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Mar 31 12:01:25 2013 +0200
osmo-nitb support for codec negotiation
The caller's most preferred codec is selected out of the union of codecs,
which both parties support.
Since codec negotiation is done automatically, there is no need to define
codec for TCH/F and TCH/H via VTY anymore.
http://cgit.osmocom.org/openbsc/commit/?id=a964c3e894e13530d17eff50d3903d8a…
commit a964c3e894e13530d17eff50d3903d8ac968bb37
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Mar 31 11:57:38 2013 +0200
If requested TCH/H channel is not available, try assigning TCH/F
If MNCC application requests a half rate channel, the channel might not be
available, due to different cell configuration, so the full rate channel
is used instead.
http://cgit.osmocom.org/openbsc/commit/?id=c155ea7240776a151e763ea50bceeb57…
commit c155ea7240776a151e763ea50bceeb57fcf48ffd
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Mar 31 11:44:34 2013 +0200
Fix: If paging for half rate was requested, use hr, if supported by MS
http://cgit.osmocom.org/openbsc/commit/?id=d4cde09829cfce77a1dd553b5b8ad107…
commit d4cde09829cfce77a1dd553b5b8ad1074c93b9b6
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Thu Mar 14 09:41:18 2013 +0100
Drop bad speech frames rather than forwarding them via RTP
Some RTP endpoints may not check for bad frame indications, so a frame
that is marked as bad may be still forwarded, which creates anoying noise.
This patch drops these frames. It depends on the other RTP endpoint how
dropped frames are handled. (insert silence, extrapolate speech...)
http://cgit.osmocom.org/openbsc/commit/?id=4622fbe25d9a8a0d03e260f5d3fcf166…
commit 4622fbe25d9a8a0d03e260f5d3fcf1669c996d00
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Thu Mar 8 11:08:37 2012 +0100
Fixed (ipaccess BTS) delay/silence problems, if RTP stream jitters too much
After OpenBSC stalled for some reason (e.g. CPU overload or database
access) or after speech frames have been lost (MNCC application problems /
hold/retrieve call), the timestamp and the sequence number of the RTP
socket state must be corrected. The amount of incrmentation is calculated
from the elapsed time. Not incrementing timestamp and sequence number would
cause all frames to be dropped by ipaccess BTS, because the BTS expects
frames with more recent timestamps.
If speech frames are received too fast, they must be dropped. The timestamp
and sequence number of the RTP socket state are not changed in this case.
Incmenetating timestamp and sequence number would causes high delay at
ipaccess BTS, because the BTS would queue the frames until the timestamp
matches the current time.
There is a simple test case:
Make a call between two phones and check the delay. (When using LCR, make
a call to the echo test.) The press CTRL+z to suspend OpenBSC process for
a few seconds and enter "fg" to continue OpenBSC process. There shall be no
change in the delay, even after repeating this test many times.
http://cgit.osmocom.org/openbsc/commit/?id=fa032ac8b3c1f49c908dcd5380b48f19…
commit fa032ac8b3c1f49c908dcd5380b48f198439494e
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Fri Feb 17 15:20:59 2012 +0100
Allow dynamic RTP payload types between application and MNCC interface
Since EFR/AMR/HR codecs use dynamic RTP payload, the payload type can
be set. If it is set, the frame type must be set also, so OpenBSC
knows what frame types are received via RTP.
This modification only affects traffic beween application and MNCC
interface, not the RTP traffic between OpenBSC and BTS.
http://cgit.osmocom.org/openbsc/commit/?id=990b41308770426eec50cbee6ac5f270…
commit 990b41308770426eec50cbee6ac5f270f93afee2
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Mon Jan 16 09:29:28 2012 +0100
Add traffic forwarding via RTP to remote application
Instead of forwarding traffic through MNCC interface, traffic can
be forwarded to a given RTP peer directly. A special MNCC message
is used to control the peer's destination. The traffic can still be
forwarded through MNCC interface when this special MNCC message is
not used.
It also works with E1 based BTSs.
In conjunction with LCR's "rtp-bridge" feature, the RTP traffic
can be directly exchanged with a remote SIP endpoint, so that the
traffic is not forwarded by LCR itself. This way the performance
of handling traffic only depends on OpenBSC and the remote SIP
endpoint. Also the traffic is exchanged with the SIP endpoint
without transcoding, to have maximum performance.
Increment MNCC version to 5.
-----------------------------------------------------------------------
Summary of changes:
openbsc/include/openbsc/gsm_data_shared.h | 1 -
openbsc/include/openbsc/mncc_int.h | 2 -
openbsc/include/openbsc/rtp_proxy.h | 4 +-
openbsc/include/openbsc/transaction.h | 2 +-
openbsc/src/libbsc/abis_rsl.c | 59 +++++++--------
openbsc/src/libbsc/bsc_vty.c | 25 -------
openbsc/src/libbsc/bts_nokia_site.c | 1 -
openbsc/src/libmsc/gsm_04_08.c | 104 ++------------------------
openbsc/src/libmsc/mncc_builtin.c | 17 ++---
openbsc/src/libmsc/mncc_sock.c | 8 +-
openbsc/src/libmsc/vty_interface_layer3.c | 36 ---------
openbsc/src/libtrau/rtp_proxy.c | 117 +++++++++++++++---------------
openbsc/tests/gbproxy/gbproxy_test.c | 3 +-
13 files changed, 107 insertions(+), 272 deletions(-)
hooks/post-receive
--
The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)