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=5724fb76169008c7f7d6bf8ffedbe2a4a...

commit 5724fb76169008c7f7d6bf8ffedbe2a4a78f8e00 Author: Andreas Eversberg jolly@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=a964c3e894e13530d17eff50d3903d8ac...

commit a964c3e894e13530d17eff50d3903d8ac968bb37 Author: Andreas Eversberg jolly@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=c155ea7240776a151e763ea50bceeb57f...

commit c155ea7240776a151e763ea50bceeb57fcf48ffd Author: Andreas Eversberg jolly@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=d4cde09829cfce77a1dd553b5b8ad1074...

commit d4cde09829cfce77a1dd553b5b8ad1074c93b9b6 Author: Andreas Eversberg jolly@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=4622fbe25d9a8a0d03e260f5d3fcf1669...

commit 4622fbe25d9a8a0d03e260f5d3fcf1669c996d00 Author: Andreas Eversberg jolly@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=fa032ac8b3c1f49c908dcd5380b48f198...

commit fa032ac8b3c1f49c908dcd5380b48f198439494e Author: Andreas Eversberg jolly@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=990b41308770426eec50cbee6ac5f270f...

commit 990b41308770426eec50cbee6ac5f270f93afee2 Author: Andreas Eversberg jolly@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