Some changes to the gsm_transaction data model

[Harald Welte]

Hi!

For finishing proper SMS support, I need supoprt for transactions. Similar
to Call Control, SMS can also have a number of different transactions
active of any time.

Before my changes, the transactions were tied to call control, which is
obviously not good if that code is to be reused from SMS.

Also, the transaction was linked to the gsm_network as well as the gsm_lchan.
I think both are somehow wrong.

Why are they not a property of the network?  Because a transaction always
belongs to a 'MM entity' (gsm spec language), or a gsm_subscriber in openbsc
terminology.  That subscriber then is part of a gsm_network.

And why are they not part of a gsm_lchan?  Because a transaction can be
initiated on one lchan and then move to another lchan, e.g. in case a SMS is
sent just before a call is made, where we start on an SDCCH and might continue
on a SACCH.  I will keep the lchan pointer in the meaning of 'current lchan
through which we transmit messages to the remote MM entity'.

Tying the transaction to the subscriber neatly addresses both of those
issues.

Regards,
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)