It really doesn't make sense to share the event list betwen those for
several reasons.
First, because ech of those FSM relate to different things:
* smscb_message_fsm: Handling/scheduling of 1 smscb towards all peers
* smscb_peer_fsm: Handling/scheduling of 1 smscb towards 1 peer.
The former has higher level interface used by the REST
API, plus some mid level interface used by smscb_peer_fsm.
The later has a mid level interface used by smscb_message_fsm to
interact, and a lower level interface used by the SBcAP/CBSP links to
talk to.
Furthermore, this makes it a lot easier understanding which events are
sent from one to another FSM.
Change-Id: I909474d1ff4ec7ed20aff0981da47074397df6cb
If cause != accepted, submit a NACK to the upper layers.
In that case, in the upper layers we don't want to parse the PDU IE
"Unknown Tracking Area List" since it shouldn't be there. 3GPP TS
29.168 4.3.4.3.6 states:
"""
This IE shall only be included if the Cause IE indicates Message accepted, which means the MME will proceed with the
request for Tracking Areas that are known to the MME. The Cause IE indicating Tracking area not valid is used when
all Tracking Areas in the Request are invalid.
"""
Change-Id: I0a4d5bdbb6c4fd3870a4f4ebf226668b70fea06a
Delay allocating the structures until really needed.
First do checks agains the opened connection, and if an issue is
detected simply close the fd.
Next, fetch or allocate the related peer.
Finally, create the link from the fd.
This makes it easier to add early extra checks later when peers will
contain info on link_mode (client|server|disabled) later on.
Change-Id: Id4f83ec6b0b14e556b1caa9c80e7f68d062fec57
Pau Espin