aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2019-04-19Revert "fix inter-BSC-HO-incoming for AoIP (1/2)"Daniel Willmann1-3/+3
This reverts commit 94c9324fe07cd0ba1277278270c8979d949e49ec. Multiple ttcn3 handover tests were broken due to this commit. Let's merge this once all the other commits pertaining to that fix can be merged as well. Fixes: OS#3942 Change-Id: I01d93778fb19c601c21f99ec4d2a3ab8a4a48f67
2019-04-17gsm_data.h: Remove unused variable from OpenBSC timesDaniel Willmann1-1/+0
This variable does not seem to be used anywere in OsmoBSC, seems to be a remnant from OpenBSC times. Change-Id: I5e4aa352fa5f16f6ff64738f25afd1a844fa4fcb
2019-04-15Drop unused old osmux leftover codePau Espin Pedrol2-42/+0
Let's better clean up old stuff before doing new implementation. Change-Id: Id4e254a1c24831afaba9ab7b330d4e09a2474c8e
2019-04-08fix inter-BSC-HO-incoming for AoIP (1/2)Neels Hofmeyr1-3/+3
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is done establishing. For AoIP, the local RTP address towards the MSC already needs to be known before the Handover Request Acknowledge is sent, so the AoIP Transport Layer Address IE can be included. This patch only modifies the handover FSM, a subsequent patch adds the IE. Change-Id: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff
2019-04-08Handover Request: also parse Chosen Algorithm IE, pass to lchan activationNeels Hofmeyr1-0/+4
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the Handover Request message. Actually parse this Chosen Encryption Algorithm IE. Place the chosen algorithm and the CK into lchan_activate_info->encr so that the new lchan will use the same ciphering on this new BSS as it did on the old BSS. Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
2019-04-08lchan activation: add explicit encryption info to activationNeels Hofmeyr1-0/+1
For intra-BSC handover, the previous encryption is copied from the old lchan, which of course is not available during inter-BSC handover. Hence the lchan activation info needs to include an explicit encryption information, and we must not rely on the presence of the previous lchan to copy encryption information from. Add struct lchan_activate_info.encr to allow passing encryption info through lchan_activate() without requiring a previous struct gsm_lchan to be present. Instead of copying from the old lchan, always copy encryption info to lchan_activate_info, and during activation, just before sending the Channel Activation, copy the lchan_activate_info.encr to the new lchan. This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which obtains the encryption information from an intra-BSC-incoming Handover Request message. Related: OS#3842 Related: I5b269f50bd2092516bfdf87746196983d3ac49d1 Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
2019-03-19AMR: Signal usage of octet-aligned or bandwith-efficient mode to MSCPhilipp Maier1-0/+1
MGCP/SDP provides fmtp parameters in order to signal which of the two available AMR framing modes (octet-aligned or bandwith-efficient) should be used on the link between BSS and core network. osmo-bsc currently does not set up this mode which means that the RTP packets from the BTS are forwared without inspection/modification, which may lead to malfunction when a BTS is using a framing mode that is not supported by the other end. - Add VTY option to setup the framing mode - Generate related fmtp parameters in SDP Depends: osmo-mgw I622c01874b25f5049d4f59eb8157e0ea3cbe16ba Change-Id: If6d40b2407b87aad2227ea7f15533ef01a3771b3 Related OS#3807
2019-03-14Revert "assignment_fsm: Properly support assigning signalling mode TCH/x"Neels Hofmeyr2-11/+8
This commit breaks voice channel assignment. It results in the Assignment Complete sent to the MSC for a voice lchan lacking AoIP Transport Layer Address, Speech Version and Speech Codec. Hence the MSC cannot complete the Assignment for a voice call. Let's revisit this patch, test thoroughly and re-merge later. This reverts commit 4d3a21269b25e7164a94fa8ce3ad67ff80904aee. Reason for revert: <INSERT REASONING HERE> Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
2019-03-14Move msc related code from gsm_data to bsc_mscPau Espin Pedrol2-2/+3
This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-14Move LCLS references from gsm_data to osmo_bsc_lclsPau Espin Pedrol2-13/+17
This commit aims at better ordering of content in order to get rid of sigtran stuff in gsm_data. This way we can avoid requiring libosmo-sigtran when building ipaccess utils. Change-Id: I8941f059d6e4eb21a971d48d2b66c29ec3355a6d
2019-03-14assignment_fsm: Properly support assigning signalling mode TCH/xSylvain Munaut2-8/+11
To support the 3 possible preferences, the changes needed were: - Replace 'full_rate' bool with a 3 option enum to represent the channels types for signalling - Switch from _pref/_alt to using an array sorted in preference order Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-03-04cosmetic: drop unused struct mgcp_ctx shadowNeels Hofmeyr1-1/+0
Change-Id: If9c705e9fe6dba9225f7dec045e790af7a875ee8
2019-02-21assignment_fsm: fix channel allocator preferencesPhilipp Maier2-7/+28
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may ask for a TCH/H and a TCH/F at the same time and tell which of the two types it prefers. The process of channel allocation currently selects, based on the BTS, MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H) and then tries to allocate it. If that allocation fails, there is no way to try the second choice and the assignment fails. For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the channel allocator will try TCH/F and if it fails (all TCH/F are currently in use), then TCH/H is never tried. Since the BSC currently only trys the first best codec/rate that is supported it also ignores the preference. Lets fix those problems by including the preference information and both possible codec/rate settings into the channel allocation decision. Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51 Related: OS#3503
2019-02-06comments: clarify usage of conn.assignment and .handover scopesNeels Hofmeyr1-2/+13
Change-Id: I7ef602c3ce086aecbc3ae3ae6d3fd33ad2b9f85c
2019-02-06handover_fsm: do not access conn->assignment.req, it may be outdatedNeels Hofmeyr1-0/+2
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current lchan's AMR configuration. However, conn->assignment.* values are only valid during an ongoing assignment. Those values may be overwritten by any failed Assignment attempt, at any time, and hence do not reflect the currently assigned conn->lchan. Those realms must be kept separate. The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most sense to store these values in struct gsm_lchan once the lchan activation succeeded. Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during lchan_activate(). In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*. Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
2019-02-05Implement CSFB "Fast Return" Handling at RR RELEASEHarald Welte1-0/+3
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE, it lets us know that the to-be-released connection related to a CSFB call. We as the BSC then subsequently should include the "Cell Selection Indicator after release of all TCH and SDCCH" IE in the RR RELEASE message sent to the MS/UE. This IE contains the LTE neighbor cells that we're configured to broadcast in si2quater. That in turn will make sure the MS/UE can return very quickly to the LTE cell. Closes: OS#3777 Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755 Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646 Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07 Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
2019-02-05gsm_data: Add gsm_bts_name() just like we have gsm_{trx,ts,lchan}_name()Harald Welte1-0/+1
Change-Id: Icd7fd6273396026c5fe2da600f35631b1bac1614
2019-01-28LCLS: use libosmocore function to add statusMax1-2/+0
* use gsm0808_create_ass_compl2() to add BSS Status IE to Assignment Complete message * drop local helpers Depends-on: (libosmocore) I547c6b8707123aa8c1ef636db88908df112d90a4 Change-Id: I6916928391667cd9c345becf00e7c8561846c295 Related: OS#2487
2019-01-21LCLS: constify helper parametersMax1-1/+1
Related: OS#2487 Change-Id: I341f4ea172432b94e8e96919926a5fb6870c2a30
2019-01-17chan_alloc: remove references to lchan_alloc()Philipp Maier1-3/+0
The function lchan_alloc() does not exist anymore, however there is still a prototype definition in chan_alloc.h and a comment in abis_rsl.c. Lets remove those. Change-Id: I36227ea306d28587ac70acbe596c7756b23d88c7
2019-01-03IPA: log OML/RSL link drop reasonMax1-2/+2
There could multiple reason for OML or RSL link towards BTS to be dropped: ctrl command, vty, new link etc. Introduce "reason" parameter to corresponding functions and log it on link drop to simplify troubleshooting issues with more complex setups. Change-Id: I8c8d8132ba67c31e40dbecdfe2e09be08c744899
2018-12-21comments: describe some lchan detailsNeels Hofmeyr1-0/+3
(requested by pespin) Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
2018-12-21make sure early lchan act failure resets the lchanNeels Hofmeyr2-18/+14
Fix crash after AMR configuration fails. The crash is due to an assertion that finds a non-NULL conn in the lchan, when re-using an lchan that has failed in AMR configuration earlier on. That is because the AMR config still happens in state UNUSED. DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE ... DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED ... ... DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324) Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491 The FSM design idea is that when returning to the UNUSED state, all lchan state is cleared. However, when calling lchan_activate(), a failure may happen still in state UNUSED, so that we don't transition *back* to UNUSED properly. So, first transition out of UNUSED before failures can happen. (Other ways to solve this would be to invoke lchan clearing even if already in UNUSED, but semantically, transitioning first makes more sense.) Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to UNUSED and clear the lchan. Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter(). Also, there is a bit of duplication of members of the lchan->activate (lchan state) and the lchan_activate_info (passed to lchan_activate()) structs. The fix for this also removes the dup: Add struct lchan_activate_info as child struct at lchan->activate.info, drop the other lchan->activate members that would dup .info.*. Move struct lchan_activate_info declaration to gsm_data.h. Apply the new '.info' member struct throughout the code. Related: OS#3737 Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
2018-12-18LCLS: update parameter representationMax1-2/+2
* use osmo_lcls struct from libosmocore * use enum values instead of magic numbers Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858 Related: OS#3659
2018-12-14Add VTY option to avoid sending empty Full BCCH Info for disabled SIPau Espin Pedrol1-0/+3
According to 3GPP TS 08.58 ยง8.5.1 BCCH INFORMATION: "If the Full BCCH information element is not included this indicates that transmission of the indicated SYSTEM INFORMATION message shall be stopped." However, some ipaccess nanoBTS firmware versions are known to not support some SI elements and also to dislike receiving BCCH Information for those SI, even if received with empty BCCH Information meaning they should not be used. Upon receival of this kind of message, nanoBTS sends a Failure Report with following text: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149 **** ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (325). **** This kind of issue only appears with some fw versions, since it's known to work fine in other ones, so let's not disable this kind of mesage by default on all BTs of type "nanobts". Instead, add a VTY command that allows disabling this kind of message in order to be able to operate those nanoBTS units. Fixes: OS#3707 Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
2018-12-05paging: Add VTY options to calculate T3113 timeout dynamicallyPau Espin Pedrol2-1/+2
The idea is to have a base static value which is set like before "timer t3113 [seconds]", but now have a part of this timeout calculated dynamically based on BTS channel configuration and channel load. This patch only implements initial support to calculate based on channel configuration, but doesn't include code to calculate based on channel load. To implement the later part, we probably need to keep track of BTS paging queues per paging group, which we don't do nowadays. Dynamic calculation is enabled by default, and default static base value is decreased accordingly. This way, in a typical setup were the default 10 seconds were used, now the calculated final value is 11 seconds. That's intended because it was observed experimentally in osmo-gsm-tester with a similar channel setup that sometimes paging response can arrive slightly later than 10 seconds. Related: OS#3680 Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
2018-12-05bsc: Add define for ts_as_pchan_for_each_lchan with ts->pchan_on_initPau Espin Pedrol1-0/+13
It will be used further in follow-up patches. It also provides a place to document its (intricate) logic around it and its possible uses. Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
2018-11-29bsc: ts_for_each_lchan: Improve documentationPau Espin Pedrol1-2/+4
Change-Id: Id7c050087c14aae3f01c6d41d21cf861ff53621c
2018-11-29bsc: ts_as_pchan_for_each_lchan: reorder and improve documentationPau Espin Pedrol1-9/+12
It is moved prior to its user in the header file. Change-Id: I59f52401ba37b351ba3848e8e9ffb3b24c259496
2018-11-27send Immediate Assignment Reject only before Immediate AssignmentNeels Hofmeyr1-0/+1
Set flag lchan->activate.immediate_assignment_sent to true when sending, and omit a reject after that. lchan->activate gets completely zeroed in lchan_reset(), which sets that flag back to false whenever an lchan becomes inactive. Related: OS#3709 Change-Id: I9ad094d272254d7aee9b0a676201d4ed8cd727ca
2018-11-22LCLS: add bts-loop variantMax1-1/+1
Add LCLS variant where the loop is closed on BTS level instead of MGW. The main difference is the handling of connection-related messages (we use IPA RSL instead of MGCP), the configuration and correlation logic remains the same. Change-Id: I7e8379f31037f2c48da69a01919701919a3066a2 Related: OS#3659
2018-11-22RSL: restructure MDCX functionsMax1-0/+1
In preparation for upcoming LCLS changes we have to split IPA RSL MDCX generation into separate function with the ability to set destination explicitly instead of just using the value from lchan which will be used in follow-up patches. Change-Id: Iffe2f4f10e841fc36965cce02b4e5f017a5ae6c8 Related: OS#3659
2018-11-21abis_nm: Introduce new signal S_NM_GET_ATTR_REPPau Espin Pedrol1-0/+1
This signal can be used for tools willing to request and parse Attribute Response and do something with the information. ipaccess-config tool will use this signal in later patch Change-Id Ida416a969a3309868d6f4e50f34b34f224c32dd6. Related: OS#3624 Change-Id: I9a121bbfe1b96904d4e16845abc90bb6ef20d2c9
2018-11-20bsc: Enable force-combined-si on nanoBTS by defaultPau Espin Pedrol1-0/+4
Some nanoBTS firmwares (if not all) are known to not work properly with SI2ter. If BSC enables SI2ter through RSL, SI3 bit announcing SI2ter available will be forwarded by nanoBTS to MS, but will still only send SI2 message instead of expected SI2ter during TC=5 (see GSM 05.02 sec 6.3.4 "Mapping of BCCH data"). As a result, some MS won't allow registering to the network. To avoid this kind of scenario, enable force-combined-si by default on nanoBTS while still allowing to overwrite the feature through VTY. Other BTS models are kept with force-combined-si disabled by default as usually, since they seems to be working fine when SI2ter is enabled. Related: OS#3063 Change-Id: Ide6e8967de0eedc9e2bcaf4414aaa537b009d72d
2018-11-14cosmetic: lchan: introduce sub-struct lchan->release.*Neels Hofmeyr1-15/+17
Put all lchan release related flags and settings in a sub-struct named 'release' to better indicate what those fields are for. There is no functional change. Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
2018-11-14lchan release: always Deact SACCHNeels Hofmeyr3-3/+2
If an lchan is being released and had a SACCH active, there is no reason to omit the Deact SACCH message ever. All of the callers that passed do_deact_sacch = false did so for no good reason. Drop the do_deact_sacch flag everywhere and, when the lchan type matches and SAPI[0] is still active, simply always send a Deact SACCH message. The do_deact_sacch flag was carried over from legacy code, by me, mainly because I never really understood why it was there. I do hope I'm correct now, asserting that having this flag makes no sense. Change-Id: Id3301df059582da2377ef82feae554e94fa42035
2018-11-14fix: send RR Release (e.g. after BSSMAP Clear Cmd)Neels Hofmeyr3-2/+3
After commit [1], the code makes sure to disassociate lchan and conn before invoking the lchan release. However, we only send RR Release if a conn is present, which clearly is nonsense after [1]. [1] commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb "subscr conn: properly forget lchan before release" Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db Manage sending of RR Release via a flag, set during invoking lchan release. Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care whether a conn is still associated (because it won't ever be since [1]). That way we can intelligently decide what release process makes sense (whether the lchan terminates the subscriber connection or whether the connection goes on at another lchan), and still disassociate lchan and conn early. BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the f_expect_chan_rel() don't care whether an RR Release happens or not. This is being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845. So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear. Related: OS#3413 Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
2018-11-09abis_nm: Add support to parse OML IP and Unit Id in Get AttributesPau Espin Pedrol1-0/+2
Change-Id: Ia05e0b8fe3e28aaf2b2253d018f0614e83e23caa
2018-11-09gsm_data: make cgi_for_msc available for other modulesPhilipp Maier1-0/+2
The function cgi_for_msc() provides an easy way to get a cell global id for an msc/bts combination. This function is currently statically defined in gsm_08_08.c. Lets move it to gsm_data.c and make it publicly available. Change-Id: I301fac6e83a429ae59b5c586aa283ad7ba54053d Related: OS#3645
2018-11-08LCLS: expand logging to print the name of the mode in useMax1-0/+7
Change-Id: I56b57936ae82984e84896228da5a83115a78bbd7 Related: OS#3659
2018-11-07constify rsl_tx_ipacc_*cx() parametersMax1-2/+2
Change-Id: Ib34c8e3fb51d067581aefa1c80f8be1f6db9512e
2018-11-07Make IP address helper accessible via header fileMax1-0/+2
Change-Id: I4bc157bf296e28678de6d9c9823f91810132a58c
2018-11-06vty doc: drop "(HO algo 2 only)" stringsNeels Hofmeyr1-9/+8
These indicators are a legacy of early handover_decision_2.c work, where there were no separate handover1 and handover2 config commands. No need to restate the abundantly obvious anymore. Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
2018-10-30vty: add 'show rejected-bts'Oliver Smith1-0/+11
Print IDs and IPs of recently rejected BTS devices. Example output: OsmoBSC> show rejected-bts Date Site ID BTS ID IP ------------------- ------- ------ --------------- 2018-10-25 09:36:28 1234 0 192.168.1.37 Related: OS#2841 Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
2018-10-24gsm_04_08: improve gsm48_multirate_config()Philipp Maier1-1/+2
The function gsm48_multirate_config() generates the multirate configuration IE, that is sent via RSL to configure the active set of AMR codecs inside the BTS. The function already works, but it does not check the input data for consistancy. Lets add some consistancy check to make sure that inconsistant parameters are rejected. Also allow the output pointer to be NULL, so that the function can be used to perform a dry run to be able to verify parameters. - Check for invalid / inconsistant configuration parameters - Perform a dry-run when lv pointer is set to NULL Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4 Related: OS#3529
2018-10-23codec_pref: also check amr codec rates in check_codec_pref()Philipp Maier1-0/+4
The function check_codec_pref() currently only does a basic check over the general codec configuration of bts and msc. However, it does not yet check if the amr codec rate settings for the BTSs contradict the allowed/forbidden amr codec rates of the MSC. When the two settings do contradict AMR would not work, even when everything else is correctly configured. We need to check this on startup to spot configuration problems quickly. - Add function to calculate intersections of struct gsm48_multi_rate_conf variables. - Calculate the intersection between the multi rate config of each BTS with the one of the MSC Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710 Related: OS#3529
2018-10-08codec_pref: check codec configuration before startPhilipp Maier1-0/+2
In networks with a couple of different BTSs it may be likely that one accidently sets up a codec configuration (codec-support)) that will be mutually exclusive towards the codec configuration for the MSC (codec-list). We need a check that validates the configuration before start to catch such configuration flaws quickly. - Add a check that checks each MSC codec-list against each BTS codec-support setting. Change-Id: Ice827896bab1a2330741e0fccc731a04f1a07d38 Related: OS#3625
2018-10-05codec_pref: handle S0-S15 in ASSIGNMENT REQUESTPhilipp Maier3-3/+5
Opposed to all other codecs that are common in GSM, AMR requires a codec configuration that is expressed by a bitmask (S0 to S15) in the speech codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those configuration in the ASSIGNMENT COMPLETE message. At the moment osmo-bsc ignores all incoming configuration bits. The bits in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded. - Store the configuration bits while parsing the ASSIGNMENT COMPLETE - Create an intersection with the configuration that is actually supported by the BSS - Return the resulting (chosen) configuration bits with the assignment complete message. - Use the (highest of the) agreed codec rates in RSL channel activation. Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737 Related: OS#3529
2018-09-24codec_pref: Add Codec List to COMPLETE LAYER 3 INFORMATIONPhilipp Maier1-0/+6
The COMPLETE LAYER 3 INFORMATION message lacks the Codec List (BSS Supported) information element. This information element is mandatory for networks that use an IP based user plane (AoIP). - Add function to generate the speech codec list from the current codec settings (Available codecs) - Generate and embed information element in L3 Compl. message Depends: libosmocore I4e656731b16621736c7a2f4e64d9ce63b1064e98 Change-Id: Id6f2af3fdab45bf05f06aec03e222734d7a4cf70 Related: OS#3548
2018-09-18Implement RR Classmark EnquiryNeels Hofmeyr1-0/+1
If the MSC sends a BSSMAP Classmark Request, send an RR Classmark Enquiry to the MS. (The reverse direction, i.e. sending a BSSMAP Classmark Update back to the MSC, is already implemented.) Related: OS#3043 (A5/3 encryption) Related: osmo-ttcn3-hacks Idaab4d568cf986b4897ba008f6262c839d1592fb Change-Id: If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-16 21:56:46 +0000