patch: 12_application

This interface is introduced to allow other applications than bsc_hack to be used with libbsc. The built-in application for call forwarding from mobile to mobile calls has been moved out of gsm_04_08.c to mncc.c and stays part of libbsc. The most messages on this interface begin with MNCC_ and end with _REQ (layer 4 requests) _CNF (layer 3 reply) _IND (layer 3 requests) _RSP (layer 4 replies). Other messages are used to control TRAU traffic or channel modification. More commands may be added in the future. The handling of messages from the mobile side (MMCC) and from the application (MNCC) is done by a state machine. (See Fig. 5.1b TS 04.08) The "datastate" list handles messages from the mobile side. The "downstate" list handles messages from the application. The timers are handled by a special timeout function. When a message is received, the downstate list or datastate list is checked for the current state and the message. If there is a match, for a current state and a message, it's handler called. Inside this handler, timers can be started and stopped, states can be changed, messages can be forwarded and replied, and so on. All information elements are parsed or created in gsm_04_08.c. A special "upqueue" is used to forward messages from gsm_04_08.c to the application. The dequeue function is called by the application in the main loop (before select function). If the application sends a message to BSC, it calls the "mncc_send" function of gsm_04_08.c. The process of this maessage in gsm_04_08.c may result in messages back to the application. The queue prevents libbsc from calling the application's "mncc_recv" function, while the application calls the "mncc_send" function. The upqueue makes sure that messages created by gsm_04_08.c during "mncc_send" is processed AFTER the application has finished it's processing. The call instance of the application is called "gsm_call". This has moved out of gsm_04_08.c into mncc.c. The gsm_04_08.c uses a "llist" of transactions: "struct gsm_trans". The transaction can be associated with a logical channel: "lchan". The use-counter of lchan is increased for every transaction assoicated to. After freeing of transaction, the use-counter is decremented. If lchan breaks down, all transactions are released. The application receives a "released indication" message. Multiple transactions for an lchan provide the ability to hold a call and receive/make another call. This has been successfully tested on LCR application and is not yet implemented in mncc.c, but very easy todo. A message between libbsc and application consists of a message type (mgs_type), a call reference (callref), and information elements within the same structure. Each information element has an additional flag, to indicati if it exists in the message. The message is defined in mncc.h The A transaction can have a logical channel (lchan) or not. At least it has a subscriber (subscr). If a transaction is created, the subscriber is checked. If no transaction with this subscriber exists, paging is started. If another transaction exists with an lchan, this lchan is also used for the transaction (already established). If another transaction of this subscriber exists, but no lchan, the paging is already stated, nothing is done until paging response. After a paging response, the transactions with the same subscribers are associated to the lchan. If paging failed, all transactions associated with the subscriber are released. (no user responding).