986fe7ed18
Store all Classmark information in the VLR. So, we now always know the Classmark 1 (mandatory IE for LU). This is visible in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported" because classmark 1 is missing, because we now know the Classmark 1. Rationale: During Location Updating, we receive Classmark 1; during CM Service Request and Paging Response, we receive Classmark 2. So far we stored these only for the duration of the conn, so as soon as a LU is complete, we would forget CM1. In other words, for anything else than a LU Request, we had no Classmark 1 available at all. During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1 is supported. That is moot if we don't even have a Classmark 1 for any CM Service Request or Paging Response initiated connections. The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1 is missing. To add to the confusion, if a phone indicated that it did *not* support A5/1 in the Classmark 1, according to spec we're supposed to not service it at all. A code comment however says that we instead want to heed the flag -- which so far was only present in a Location Updating initiated connection. Now we can make this decision without assuming things. This got my attention while hacking on sending a BSSMAP Classmark Request from the MSC if it finds missing Classmark information, and was surprised to see it it lacking CM1 to decide about A5/1. Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a |
||
|---|---|---|
| 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 OsmoMSC ============= OsmoMSC 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. OsmoMSC was one of the parts split off from the old openbsc.git. Before, it was the libmsc part of the old OsmoNITB. Since a true A interface and IuCS for 3G support is available, OsmoMSC exists only as a separate standalone entity. OsmoMSC exposes - GSUP towards OsmoHLR (or a MAP proxy); - A over IP towards a BSC (e.g. OsmoBSC); - IuCS towards an RNC or HNB-GW (e.g. OsmoHNBGW) for 3G voice; - MNCC (Mobile Network Call Control derived from GSM TS 04.07); - SMPP 3.4 (Short Message Peer-to-Peer); - The Osmocom typical telnet VTY and CTRL interfaces. Find OsmoMSC issue tracker and wiki online at https://osmocom.org/projects/osmomsc https://osmocom.org/projects/osmomsc/wiki