we now have the full path from the MS into the database (SUBMIT), as well as
back from the database to the MS (DELIVER). The database gets correctly
updated once a SMS has been successfully delivered.
What's still missing is the periodic scan over all undelivered messages,
trying to deliver them to the respective MS. So far, you have to manually
trigger this on the telnet interface with 'sms send pending 1'
So far, we immediately disable the RF channel without following a proper
RLL RELEASE procedure. This patch changes this.
If we locally terminate the connection, the channel allocator now triggers a
RLL RELEASE REQuest, which is responsed by the MS with a RLL RELEASE CONFirm,
based on which we send the RF CHANnel RELease to the BTS.
If the MS terminates the connection, we receive a RLL RELEASE INDication,
based on which we trigger RF CHANnel RELease to the BTS.
This helps us to detect the frequency error of BS-11 if it is located
next to the nanoBTS 900.
If 'ipaccess-config -l' is called, it will produce a report like
<0020> ipaccess-config.c:85 TEST REPORT: test_no=0x42 test_res=0
<0020> ipaccess-config.c:108 ==> ARFCN 220, Frequency Error 22
<0020> ipaccess-config.c:108 ==> ARFCN 1, Frequency Error -37
<0020> ipaccess-config.c:108 ==> ARFCN 10, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 20, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 53, Frequency Error 5
<0020> ipaccess-config.c:108 ==> ARFCN 63, Frequency Error -4
<0020> ipaccess-config.c:108 ==> ARFCN 84, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 101, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 123, Frequency Error -52
where in this case the ARFCN 123 is the BS-11 with a frequency error
larger than all the other (regular) BTS in the vicinity.
* we only need one piece of code to calculate rsl_ie_chan_mode from
our run-time data structures (gsm_lchan)
* add some more channel modes for TCH/H and data
* use enum's to make the compiler warn us about unhandled enum values
* make sure the caller determines the (signalling,speech,data) mode
Up until now, we only supported direct RTP streams between ip.access BTS.
With this commit, the user can specify '-P' to the command line to enable
a RTP/RTCP proxy inside OpenBSC. The nanoBTS will then send all their voice
data to OpenBSC, which will relay it to the respective destination BTS (which
can be the same BTS).
The default behaviour remains unchanged. Without '-P' on the command line,
RTP/RTCP is exchanged directly.
The rtp_proxy.[ch] code is intended to be used as a transparent
RTP/RTCP proxy, relaying the media streams from one ip.access BTS
to another. In an 'ideal' network, this is obviously not needed,
since the BTS's can send those streams directly between each other.
However, for debugging, 'lawful interception', transcoding or interfacing
a TRAU/E1 based BTS, we actually need to process those RTP streams
ourselves.
There were many places in the code where we had to explicitly
reference the transaction_id and put it into a packet. By introducing
and optional gsm_trans parameter to gsm48_sendmsg(), we can implement
this code once rather than dozens of time.
since a subscriber is an element of the gsm_network, we have to ensure
subscr->net is always set correctly. We do this by using gsm_network
as an argument to all functions that resolve or create a subscriber.
Since a transaction is associated to a gsm_subscriber, and the subsciber
is part of a network, we don't need to have a dedicated transaction->network
pointer.
This changeset factors out gsm_transaction as something independent
of call control in preparation to re-use the code from SMS. A
transaction is uniquely identified by either its callref, or by
a tuple of (transaction_id, protocol, subscriber).
Since a transaction is associated to a gsm_subscriber, and the subsciber
is part of a network, we don't need to have a dedicated transaction->network
pointer.
This changeset factors out gsm_transaction as something independent
of call control in preparation to re-use the code from SMS. A
transaction is uniquely identified by either its callref, or by
a tuple of (transaction_id, protocol, subscriber).
since a subscriber is an element of the gsm_network, we have to ensure
subscr->net is always set correctly. We do this by using gsm_network
as an argument to all functions that resolve or create a subscriber.
Currently we send the attribute changes in a send and forget
fashion. But sometimes the nanoBTS is sending us a NACK, e.g
with a invalid unit id. Start handling the NACK and provide
an error message to the user. The error message is not yet
describing the cause of the error but this is a slight progress
to the previous silent failure.
For further evaluation/analysis, this patch stores the classmark 1, 2 and 3
values of every equipment in the SQL database. We can use this non-volatile
data to determine the supported features for each handset that we've ever
seen on our network.
Harald Welte
Harald Welte