aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc
AgeCommit message (Collapse)AuthorFilesLines
2020-01-09deprecation: s/osmo_sockaddr_str_from_32n/osmo_sockaddr_str_from_32hNeels Hofmeyr1-1/+1
Change-Id: I5a6797b92e7e84666b399e4a21e2968ea45d7f73
2020-01-09logging typo 'extected'Neels Hofmeyr1-1/+1
Change-Id: I6ebdf3aa49bc27544414be1a4a0334e28faa83aa
2020-01-08sms-over-gsup fixupsNeels Hofmeyr1-10/+17
Change-Id: I9b03a7db839731aee6db3b0b7a525d7502a2c373
2020-01-08Fix duplicate SMS when SMPP returns to same MSCNeels Hofmeyr1-4/+14
Change-Id: I8c9b61dc05bda6f2b09cbc1890de1f2702f7abc8
2020-01-06add full SDP codec information to the MNCC socketNeels Hofmeyr11-198/+1283
This way osmo-msc can benefit from the complete codec information received via SIP, which was so far terminated at osmo-sip-connector. osmo-sip-connector could/should have translated the received SDP to MNCC bearer_cap, but this was never implemented properly. Since osmo-msc already handles SDP towards the MGW, it makes most sense to pass SDP to osmo-msc transparently. To be able to send a valid RTP IP:port in the SDP upon the first MNCC_SETUP_IND going out, move the CN side CRCX to the very start of establishing a voice call. As a result, first create MGW conns for both RAN and CN before starting. The voice_call_full.msc chart shows the change in message sequence for MO and MT voice calls. Implement cc_sdp.c, which accumulates codec information from various sources (MS, BSS, Assignment, remote call leg) and provides filtering to get the available set of codecs at any point in time. Implement codec_sdp_cc_t9n.c, to translate between SDP and the various libosmo-mgcp-client, CC and BSSMAP representations of codecs: - Speech Version, - Permitted Speech, - Speech Codec Type, - default Payload Type numbers, - enum mgcp_codecs, - FR/HR compatibility - SDP audio codec names, - various AMR configurations. A codec_map lists these relations in one large data record. Various functions provide conversions by traversing this map. Add trans->cc.mnccc_release_sent: so far, avoiding to send an MNCC release during trans_free() was done by setting the callref = 0. But that also skips CC Release. On codec mismatch, we send a specific MNCC error code but still want a normal CC Release: hence send the MNCC message, set mnccc_release_sent = true and do normal CC Release in trans_free(). (A better way to do this would be to adopt the mncc_call FSM from inter-MSC handover also for local voice calls, but that is out of scope for now. I want to try that soon, as time permits.) Change-Id: I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f
2020-01-05libmsc/gsm_04_08.c: fix: verify MI before calling vlr_subscr_rx_id_resp()Vadim Yanitskiy1-0/+36
During the last congress, we have noticed that OsmoMSC crashes on receipt of malformed MM Identity Response messages: BSSAP Message Type: Direct Transfer (0x01) Data Link Connection Identifier 00.. .... = Control Channel: not further specified (0x0) ..00 0... = Spare: 0x0 .... .000 = SAPI: RR/MM/CC (0x0) Length: 11 GSM A-I/F DTAP - Identity Response Protocol Discriminator: Mobility Management messages (5) .... 0101 = Protocol discriminator: Mobility Management messages (0x5) 0000 .... = Skip Indicator: No indication of selected PLMN (0) 01.. .... = Sequence number: 1 ..01 1001 = DTAP Mobility Management Message Type: Identity Response (0x19) Mobile Identity - Format Unknown Length: 8 .... 1... = Odd/even indication: Odd number of identity digits .... .111 = Mobile Identity Type: Unknown (7) <-- This makes OsmoMSC crash [Expert Info (Warning/Protocol): Unknown format 7] [Unknown format 7] [Severity level: Warning] [Group: Protocol] The value '111'B is not a valid Mobile Identity type, and shall be considered as reserved according to 3GPP TS 24.008, section 10.5.1.4. Later on it was discovered that '000'B also crashes OsmoMSC in the same way. The crash itself is provoked by OSMO_ASSERT(0) in vlr_subscr_rx_id_resp(). Let's keep that assert in there, and make sure that: - on receipt of MM Identity Response, Mobile Identity type matches the one in MM Identity Request; - on receipt of RR Ciphering Mode Complete, Mobile Identity contains IMEI(SV) if present. Change-Id: Ica4c90b8eb4d90325313c6eb400fa4a6bc5df825 TTCN-3 test case: I62f23355eb91df2edf9dc837c928cb86b530b743 Fixes: OS#4340
2019-12-19libmsc/gsm_04_11_gsup.c: fix SM-RP-OA encoding for MO SMS over GSUPVadim Yanitskiy1-6/+12
We shall not include additional BCD length octet into the value part of SM-RP-OA (Originating Address) IE. Instead, there should be ToA/NPI header (1 octet). Since we do not get ToN/NPI fields from the VLR/HLR, let's assume the following default values: 1... .... = Extension: No extension .001 .... = Type of number: International (1) .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1) Change-Id: I0f32e2af0ed2d2fea6addf45efbdfee120c2425d TTCN-3 test case: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9 Related: OS#4324
2019-12-19libmsc/gsm_04_11_gsup.c: do not init a buffer in gsm411_gsup_mo_fwd_sm_req()Vadim Yanitskiy1-1/+1
Because there is no real need for that. Change-Id: I19d4d0de0d5a46bf1de194b966f18ea8a84ced94
2019-12-12sms log tweakNeels Hofmeyr1-1/+1
Change-Id: I77e7a1501f74b9045f032c5b6c2322025a11fd59
2019-12-12sms db: when storing an SMS, retrieve the IDNeels Hofmeyr1-0/+3
seemed like a good idea, but not sure if we need it at all. Change-Id: I5fa55307a6abb8bbfe56619235d7b79fbbda6caf
2019-12-02libmsc: fix potential NULL-pointer dereferences detected by GCC's LTOVadim Yanitskiy2-1/+9
Change-Id: Ib7ba8909dce64d1b8ff3a53495fe3eefc446ed8e
2019-12-01Check for osmo_fsm_register() error return valueHarald Welte2-2/+2
Change-Id: I4cce3d6798fe3184a3085d114b749b4645620978
2019-11-28MNCC v6: add optional SDP to the socket protocolNeels Hofmeyr1-8/+30
Add a char buffer of 1024 characters length as space for SDP to pass to / receive from MNCC. Actually support receiving MNCC without such an SDP tail. The main reason for this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would stop working for older osmo-msc. Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged (save the protocol number bump) without having to implement SDP. The SDP part in the MNCC protocol will be used in upcoming patch I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f. This patch must be merged at the same time as osmo-sip-connector patch Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching MNCC protocol version number. Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
2019-11-28add sdp_msg API: SDP parsing/compositionNeels Hofmeyr2-0/+577
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP messages. Obviously, libosmo-mgcp-client already contains similar code, but that is unfortunately heavily glued to the actual MGCP implementation. The simplest solution is to create this separate implementation, copy-pasting from the existing libosmo-mgcp-client code as is convenient. This API is added here to probe whether it works well. When it does, the intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our MGCP client and MGCP server APIs using this same API. Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
2019-11-28fix incoming call while PagingNeels Hofmeyr1-10/+2
Do not free the CC transaction when an MT subscriber is already being Paged. Instead, invoke another paging request, which paging.c will correctly add to the list of pending paging response callbacks to run. A ttcn3 test is linked in the related patch (s.b.). Related: OS#4240 Related: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46 Change-Id: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
2019-11-28msc_a CC: add some basic sanity testsNeels Hofmeyr1-0/+10
Change-Id: I9d7d7d4073282abc6c02a6a297c807dc70c5154c
2019-11-28fail on invalid RTP address from MGWNeels Hofmeyr1-0/+6
When the CRCX OK returns an invalid RTP address, abort the call; fixes MSC_Tests.TC_invalid_mgcp_crash. The original crash happened when adding this error handling without this commit I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require new fsm deferred dealloc, check for term"). With this error handling added, even though avoiding a crash, the test does not pass yet, because instead of rejecting the call, it currently composes an Assignment Command without a Transport Layer Address. Fix that. Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
2019-11-19Fix some typosMartin Hauke12-20/+20
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-05BSSMAP: decode Codec List (BSS Supported)Neels Hofmeyr1-0/+30
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete Layer 3 Information and the Assignment Complete messages. An upcoming patch improves codec negotiation and requires the BSS supported codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great lengths to compose those IEs). Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
2019-11-05cc trans: remove unused tch_rtp_createNeels Hofmeyr1-14/+0
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover support, I forgot to remove it. Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
2019-11-01CC: add error handling for CRCX responsesNeels Hofmeyr1-3/+3
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the MGW providing (or failing to provide) an RTP port for the RAN side. From an earlier stage of the code, the cleanup for this situation was extremely complex, and hence the choice was to simply wait for the call to time out and fail. But since we have implemented safe deallocation of nested FSMs in libosmocore, the situation has become rather trivial: simply free the CC transactions, and all the rest will immediately release, and terminate correctly without crashing. A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP message ends up causing a failure in the on_success() branch of mgcp_client_endpoint_fsm.c. Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
2019-11-01use osmo_sockaddr_str_is_nonzero()Neels Hofmeyr6-19/+19
Also regard an RTP port as invalid if the IP address is 0.0.0.0. Achieve this by using osmo_sockaddr_str_is_nonzero() instead of osmo_sockaddr_str_is_set(). Depends: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550 (libosmocore) Change-Id: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd
2019-11-01rtp_stream: sanely cancel MGW endpoint FSM notifyNeels Hofmeyr1-0/+1
libosmo-mgcp-client recently introduced osmo_mgcpc_ep_cancel_notify() to cancel notification if a notify target FSM deallocates. Use it for sanity in rtp_stream FSM cleanup, the notify target for endpoint FSMs. Depends: I41687d7f3a808587ab7f7520f46dcc3c29cff92d (osmo-mgw) I14f7a46031327fb2b2047b998eae6ad0bb7324ad (osmo-mgw) Change-Id: I351bb8e8fbc46eb629bcd599f6453e2c84c15015
2019-10-29send MNCC REL only if MNCC has actually startedNeels Hofmeyr1-3/+8
Change-Id: I07b2b6c0ee33f5d3e0a060c10cf36d5c7c9f0d9b
2019-10-29log: ran_msg_a: tweak a message nameNeels Hofmeyr1-1/+1
Change-Id: I691025cb957e9b87c8af2dc8eb741dcba6ca26e2
2019-10-29log: RANAP encode: use RANAP message names instead of BSSAPNeels Hofmeyr1-2/+5
Change-Id: Ib0e0630d775a28958ea86802f70cbeec07087f91
2019-10-29BSSMAP log tweakNeels Hofmeyr1-1/+1
Before: RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3 After: RAN decode: BSSMAP: COMPLETE LAYER 3 This caught my attention while I was writing up a script to parse osmo-msc logging to produce ladder diagrams. Change-Id: I387dde8f2eb3edb35d22ce52dc0ed580978dea36
2019-10-29also log MNCC_SETUP_REQNeels Hofmeyr1-0/+3
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early return so far skipped logging of that MNCC message. Add this logging. Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
2019-10-21log: drop duplicate MNCC logNeels Hofmeyr1-2/+0
Change-Id: I46055a4f7a6ae517772c6794faad8c775454974a
2019-10-21log which DTAP messages are sent to RANNeels Hofmeyr1-2/+5
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP message, which is in fact a very interesting detail when reading osmo-msc logs. Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
2019-10-21LOG_TRANS for CC: always log CC stateNeels Hofmeyr1-0/+16
For all CC type transaction logging, log the current trans->cc.state string for all LOG_TRANS*() logging. Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
2019-09-26paging: Send SGsAP-SERVICE-ABORT-REQUEST on paging timeoutPhilipp Maier2-0/+26
When pagig for a CS-Call via SGs times out, the MME expects to be informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this message is sent, but only for CS-Fallback calls. Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877 Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a Related: OS#3614
2019-09-24sgs_iface: Accept messages with unknown TLV elementsPhilipp Maier1-4/+2
3GPP TS 29.118, chapter 7.5 states that unknown TLV elements should be ignored rather than that the whole message is discarded a STATUS message is sent. Lets turn the returncode check of the tlv_parse() call into a log message and continue normally. Change-Id: Ic6714451ad970043d4765f8420d753daf5294a44 Related: OS#4214
2019-09-18fix error on BSSMAP Cipher Mode Complete L3 msg IENeels Hofmeyr2-11/+15
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second time, but instead point to it from the ran_msg.cipher_mode_complete struct. When the MSC-A decodes the Ciphering Mode Complete message, it always wants to also decode the enclosed DTAP from the Layer 3 Message Contents IE. However, when the MSC-I preliminarily decodes messages, it often just wants to identify specific messages without fully acting on them, let alone dispatching RAN_UP_L2 events more than once. So leave it up to the supplied decode_cb passed to ran_dec_l2() implementations to decide whether to decode the DTAP. In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher Mode Complete's Layer 3 Message Contents IE. Particularly, the previous choice of calling the decode_cb a second time for the enclosed DTAP caused a header/length parsing error: the second decode_cb call tried to mimick DTAP by overwriting the l3h pointer and truncating the length of the msgb, but subsequently ran_a_decode_l2() would again derive the l3h from the l2h, obliterating the intended re-interpretation as DTAP, and hence the previous truncation caused error messages on each and every Cipher Mode Complete message, like: DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message This error was seen a lot at CCCamp2019. Modifying the msgb was a bad idea to begin with, the approach taken in this patch is much cleaner. Note that apparently many phones include the IMEISV in the Cipher Mode Complete message even though the BSSMAP Cipher Mode Command did not include the Cipher Response Mode IE. So, even though we did not specifically ask for the Cipher Mode Complete to include any identity, many MS default to including the IMEISV of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using a Samsung Galaxy S4mini. Related: OS#4168 Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
2019-09-16vty: fix access to wrong argv in paging response-timerPau Espin Pedrol1-1/+1
Fixes: 2ff5bcdc387a7eb5135e5a54d55027502952c86b Change-Id: I667cf4c8e3e7b6e77ea6ed8ae603727ad22a2ee2
2019-09-03msc_a fsm: ignore state chg to same stateNeels Hofmeyr1-2/+8
We sometimes see errors like libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted! i.e. changing state to the state msc_a is already in. Ignore re-entering the same state for most state changes. However, there is one state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary to start the timeout. Hence add msc_a_state_chg_always() and use that for re-entering MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes. This should silence all no-op state change error messages for msc_a. Related: OS#4169 Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
2019-09-03ran_dec logging: log message sizes on errorsNeels Hofmeyr1-3/+7
Change-Id: Id08e4ee5a4dbf552dbb107d8f0519110664f6acb
2019-09-03Implement a global switch on the network to disable call waiting.Keith Whyte2-3/+47
Add a network -> callwaiting VTY command as boolean. When this is enabled (default) there is no change to operation previous to this commit. When this switch is disabled with "no call-waiting" in vty then when a call arrives, we will check if we have an active call transaction for this subscriber, no matter if it is establishing, established, or alerting, in any of these cases we will return USER BUSY to the calling party. Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
2019-09-02msc_a.c, CC trans: change a comment to a debug logNeels Hofmeyr1-1/+1
Change-Id: I5a3cc6219080910119b0c9ff11fc2b9eb96a06e5
2019-09-02gsm48_tch_rtp_create(): check against NULL mgcp_infoNeels Hofmeyr1-1/+4
osmo_mgcpc_ep_ci_get_rtp_info() might return a NULL mgcp_info, guard against that. Fixes: CID#203651 Change-Id: I98fe5860c49751ade1af10d99487aba259504f23
2019-09-02log, cosmetic: add "RR" to "Ciphering Mode Complete"Neels Hofmeyr1-1/+1
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer BSSMAP Cipher Mode Complete message in the DEBUG log. Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
2019-08-29tweak CC cause for incoming call to unattached nrNeels Hofmeyr1-1/+1
So far we sent CC cause "Unassigned Number" But the MSC doesn't trivially know whether the HLR has the number assigned or not: any handset that is currently switched off would cause "Unassigned number" to be displayed on the caller's handset. Rather send a temporary failure cause code. Send this cause code for all cases, because claiming that an assigned number is unassigned is worse than rejecting an unassigned number with a temporary failure. Change-Id: Ia3d4f67b53fcc2654ff048fbc338e92cb763a095
2019-08-29fix segfault: don't send CC REL on NULL msc_aNeels Hofmeyr2-2/+19
Apparently, if a conn disappears during an ongoing call, the CC code tried to send a CC REL on a NULL msc_a during cleanup, which lead to a crash (cccamp2019). Guard against that. Crash: #0 msc_a_tx_dtap_to_i (msc_a=0x0, dtap=0x55a4bf2fa0f0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1565 #1 0x000055a4be1bb03c in trans_tx_gsm48 (trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, msg=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:82 #2 gsm48_cc_tx_release (trans=trans@entry=0x55a4bf2d52a0, arg=arg@entry=0x7ffdd731a0e0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1101 #3 0x000055a4be1bee65 in _gsm48_cc_trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:278 #4 0x000055a4be1ab654 in trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/transaction.c:170 #5 0x000055a4be1bd091 in mncc_tx_to_gsm_cc (net=<optimized out>, msg=msg@entry=0x55a4bf2d3b68) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1971 #6 0x000055a4be1bf1e5 in mncc_tx_to_cc (net=<optimized out>, arg=arg@entry=0x55a4bf2d3b68) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:2049 #7 0x000055a4be18ed63 in mncc_sock_read (bfd=0x55a4bf2563b8, bfd=0x55a4bf2563b8) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:121 #8 mncc_sock_cb (bfd=0x55a4bf2563b8, flags=1) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:189 #9 0x00007fcfad607ce1 in osmo_fd_disp_fds (_eset=0x7ffdd731a9a0, _wset=0x7ffdd731a920, _rset=0x7ffdd731a8a0) at ../../../src/libosmocore/src/select.c:223 #10 osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:263 #11 0x000055a4be17dd56 in main (argc=3, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:723 Change-Id: Ia1bb0410ad0618c182a5f6da06af342b6d483eff
2019-08-29cc trans: make sure bearer cap is emptyNeels Hofmeyr1-0/+4
Change-Id: I147f10f9258fc8685f2f666878dd2a655b8e4583
2019-08-29memleak on cc setup errorsNeels Hofmeyr1-0/+2
Change-Id: I3333b90064575b270627721ace7e07d085f4ad43
2019-08-28mncc: send payload type matching chosen codecNeels Hofmeyr1-13/+25
Change-Id: Id32f32d77d24b753adb96b5393c0363439e312c2
2019-08-23smpp_openbsc.c: check acl before deref itAlexander Couzens1-1/+1
All other calls check acl before deref because in a setup with no access policy, there won't be any acl structure Change-Id: Ibe0256535b40351594d79baa05a0147a9f89dc26
2019-08-19msc_a: switch RAN type back to SGs when a CSFB-Call is clearedPhilipp Maier1-0/+5
When a CSFB call is over the MS changes back to LTE after the call is cleared. However, at the moment the MSC does not change the cs.attached_via_ran flag. This may cause problems with the next call. Lets make sure that if there is an SGs association present, the ran type is set back to SGs when the call is cleared. Related: SYS#4624 Change-Id: I104adecb0645b81b90ee230c57bf8b463c9e7045
2019-08-16sgs_iface: do not use SGsAP-MO-CSFB-INDICATION for CSFB returnPhilipp Maier1-4/+4
When the VLR/MSC receives an SGsAP-MO-CSFB-INDICATION message it sets the RAN type back to SGs. This is wrong, the message SGsAP-MO-CSFB-INDICATION has just an informative character. It informs the VLR that the UE has initiated an MO CSFB call (service request). Change-Id: I625574fc42fc915ba483db3bb406922ad6df370d Related: SYS#4624
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr3-8/+53
Recently, the ability to run UTRAN without encryption was added, but the config for it was tied to the A5 GERAN encryption configuration. This affected osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3 test suite sets A5 to 0 (no encryption) but still expects Iu to enable air encryption. Fix this "regression". Add a separate vty config option for UEA encryption, even if it does not provide full granularity to select individual UEA algorithms yet. As a result, Iu default behavior remains to enable encryption regardless of the A5 config. UTRAN encryption can be disabled by the new cfg option "encryption uea 0" alone. Even though the new vty command already allows passing various combinations of the UEA algorithm numbers, only '0' and '1 2' are accepted as valid combinations, to reflect current osmo-msc capabilities. Revert most changes to the msc_vlr test suite in commit "do not force encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new net->iu_encryption instead of net->a5_encryption_mask. Adjust/add to test_nodes.vty transcript tests. Related: OS#4144 Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-25 01:16:42 +0000