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.
i currently use "transaction" in osmocom-bb for call control and later sms and supplementary services. i think that the sms code should be re-usable in osmocom-bb, so the "operation" instance should be equal (defined in libosmocore) and the sms function sould be available in something like a "libsms", like the "libvty". note: osmocom-bb is at a point where SMS could be sent and received, if a shared sms library would be available.
andreas
On 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...
On Tue, Jun 15, 2010 at 04:15:58PM +0800, Holger Freyther wrote:
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...
sure. The current SMS implementation was always only a quick hack to make it work at all.
At some point, new code should be written with MAP SMS semantics in mind, i.e. anticipate that SMS are sent from an external process by procedures that resemble the SMS-MAP as defined in Section 4 of 03.47. I'm not referring to the actual encoding, but by the flow of events / procedures, i.e. : * Forward MT SMS * Forward MO SMS * SC Alert
This basically means an external entity (the Service Center SC) sends a SMS to the MSC, identifying the subscriber by its MSISDN. The MSC needs to decide if there is already a radio channel or if it needs to do paging. It does the paging (if needed), delivers the message and if everything works fine, it reports back to the SC. The timer at the SC side is specified between 15 to 180 seconds in total.
MO-SMS is relatively similar, but in inverse direction.
The SC Alert seems to be used for notifying the SC that a MS (that previously was unreachable or had a memory-full condition) is now available again.
-
Andreas.Eversberg -
Harald Welte -
Holger Freyther