This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther zecke at selfish.orgOn 06/15/2010 03:43 PM, Andreas.Eversberg wrote: >> 1.) kill the transaction... >> 2.) generalize it with the "operation". Right now we do have two >> operations, one for LU, one for AUTH, we should have them for USSD, SMS >> and CC as well. > > hi holger, > > the "transaction" represents the instance of calling party / called > party / sms sender / ... will the states of it be moved to the > "operation"? (e.g. call state, transaction_id, callref, protocol) in > this case the call control / sms must use "operation" instance instead. Sure, we will keep the state, either inside the MSC per (SCCP) Connection state, or inside an operation. In any case "operation" or "transaction" are just two different names... the main reasons for change are 1.) Make sure all code using transaction/operation has a clear Success, Failure, Timeout semantic (the SMS code is failing here). 2.) Make sure that when the last transaction on a connection is done, the connection is cleared (all resources allocated at the BSC will be released). If we want to stick with the "transaction" name and code we should.. 1.) move the list anchor into the subscriber_connection.. 2.) plant some timers... like we do for the LU and AUTH(i didn't check) 3.) make trans_free check if the transaction list is empty and send a clear request... at which point no more transactions can be created on that connection... Regarding new (SMS) code, the main lesson to learn is probably: Have Success/Failure/Timeout in mind and free the channel in any of these states...