Osmocom's Base Station Controller for 2G mobile networks
https://osmocom.org/projects/osmobsc
be1131df42
Do not instruct the MGW to move the RTP to the new lchan before we have received a HANDOVER DETECT. Before: Chan Activ Chan Activ Ack IPACC-CRCX -ACK IPACC-MDCX -ACK MGCP MDCX --> MGW ... HANDOVER DETECT Call continues on new lchan In above sequence, if the HANDOVER DETECT times out, the MGW has moved to the new lchan which never becomes used and is released. Furthermore, from the IPACC MDCX until the HANDOVER DETECT, the RTP stream would break off momentarily. After: Chan Activ Chan Activ Ack IPACC-CRCX -ACK IPACC-MDCX -ACK ... HANDOVER DETECT MGCP MDCX --> MGW Call continues on new lchan If the HANDOVER DETECT times out, the call happily continues on the old lchan. This change is inspired by Ivan Kluchnikov's HO work, who implemented a similar fix in the openbsc.git codebase (branch fairwaves/master-rebase): his patch moves ipacc_mdcx() to connect RTP to the new lchan from switch_for_handover() (which triggered on S_ABISIP_CRCX_ACK, i.e. creation of the new lchan) to later on in ho_detect() a.k.a. the S_LCHAN_HANDOVER_DETECT signal handler: http://git.osmocom.org/openbsc/commit/?h=fairwaves/master-rebase&id=9507a7a1ea627e07370c9d264816bb190b3b91b8 This patch does essentially the same: remove the mgcp_handover() call from the MDCX-ACK handling (creation of the new lchan), and add a signal handler for S_LCHAN_HANDOVER_DETECT to osmo_bsc_mgcp.c to effect the MGW switchover. Note, it would have been possible to call mgcp_handover() directly from rx of the HANDOVER DETECT message, but that produces linking fallout in some utils/ projects, which then need to link the mgcp code as well. That is because those aren't properly separated from the more complex parts of libbsc. Using the signal is a bit bloaty, but saves the linking hell for now. I've faced a similar problem twice recently, it would pay off to separate out the simpler utils/ and ipaccess/ tools so that they don't need to link all of libbsc and osmo-bsc, at some point (TM). Change-Id: Iec58c5fcc5697f1775da7ec0111135108ed1fc8f |
||
|---|---|---|
| contrib | ||
| debian | ||
| doc | ||
| include | ||
| m4 | ||
| src | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| AUTHORS | ||
| COPYING | ||
| Makefile.am | ||
| README | ||
| README.vty-tests | ||
| configure.ac | ||
| git-version-gen | ||
| osmoappdesc.py | ||
README
About OsmoBSC ============= OsmoBSC originated from the OpenBSC project, which started as a minimalistic all-in-one implementation of the GSM Network. In 2017, OpenBSC had reached maturity and diversity (including M3UA SIGTRAN and 3G support in the form of IuCS and IuPS interfaces) that naturally lead to a separation of the all-in-one approach to fully independent separate programs as in typical GSM networks. OsmoBSC was one of the parts split off from the old openbsc.git. Before, it worked as a standalone osmo-bsc binary as well as a combination of libbsc and libmsc, i.e. the old OsmoNITB. Since the standalone OsmoMSC with a true A interface (and IuCS for 3G support) is available, OsmoBSC exists only as a separate standalone entity. OsmoBSC exposes - A over IP towards an MSC (e.g. OsmoMSC); - Abis interfaces towards various kinds of BTS; - The Osmocom typical telnet VTY and CTRL interfaces. Find OsmoBSC issue tracker and wiki online at https://osmocom.org/projects/osmobsc https://osmocom.org/projects/osmobsc/wiki OsmoBSC-NAT is a specialized solution to navigating RTP streams through a NAT. (Todo: describe in more detail)