| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This reverts commit 55a0716da7d06860addfba1812c309eac6d82f1a.
Using a TCH/H, TCH/F for paging purpose any will break the MT-SMS
case because this needs a SDCCH to establish SAPI=3. The On Waves
BSC Master branch has support for early assignment now so this hack
is not needed anymore.
|
|
In case we need to handle speech but we are currently on a SDCCH
we need to assign a new channel and close the old one. This
implementation should have the correct flow of things but we might
need to fix some error situations properly.
It is implemented by keeping a secondary_lchan pointer that will
be swapped into the lchan pointer after the assignment complete
message from the MS. The old lchan will be deactivated (the SACCH
should stay open). We have to manually remove the subscr from the
lchan structure to properly close things down.
|
|
Use switch/case, switch/case for the subsys and signal
to prepare to handle more signals in the future.
|
|
Specify how we intend to use the assigned channel. This is
needed to make CC with early assignment work properly.
|
|
Change the signature to take the lchan were the message is supposed
to be sent and the lchan which is supposed to be assigned.
|
|
If the lchan has AMR as speech codec we also need to send the
multirate config IE in the channel activation. This is already
done for the RSL Channel Modify message.
|
|
The same concept as with the previous patch, make the reject method
work on the source local reference instead of passing it the header.
|
|
Separate SCCP UDT parsing and handling into two methods. This
way the parsing can be reused by the BSC NAT.
|
|
I want to reuse the SCCP code for header parsing in the BSC
NAT to identify data and patch the source local reference. To do
this the current handle_* methods will be changed into two parts
one is strictly parsing the other is handling the parsed data.
|
|
Send a Paging Request to the BTS every two seconds. This way it is
unlikely that a phone will try to respond to two paging requests as
it is currently happening.
|
|
Start the SCCP IT timer only after the MSC has confirmed the SCCP
connection. It is safe to call bsc_del_timer even if it was never
started. This could happen on a connection refusal.
|
|
|
|
The MSC is asking us to enable ciphering and then immediately
sends a DTAP msg for SAPI=3. We handle this correctly by attempting
to establish SAPI=3 but we never get an establishment confirm
for this SAPI.
Attempt to fix it by not sending any DTAP message when we receive
the Cipher Mode Request and unblock the queue when the ciphering
is confirmed. The unblocking currently works by taking all messages
out of the queue and then submitting them again. This will attempt
to establish the SAPI=3 and such automaticaly.
And the MSC stopped sending me SMS so this needs to be verified at a
later time.
|
|
Is that right?
|
|
In the case of ipaccess we are doing a ++output but then still
try to write 23 bytes into it and on my system this is leading
to a stack corruption.
|
|
Make the compiler happy by checking the write error and printing
a message to the console.
|
|
The first part is to analyze the IP Access Header and only forward
SCCP messages for now. In the future we might want to do MGCP
signalling through this protocol and connection as well and need to
update this then.
|
|
In plain forward mode we don't have DLCX which will clean
and reset the configuration. We will need to remember the
last GSM BTS port and send data to it.
|
|
* Do not only check the IP but also the port to figure out
where to send the data
* Do not memset the endp->remote inside the bind_rtp but from
inside the crcx as this will be modified by the MDCX
|
|
|
|
|
|
Rename the variables to refer to the fact that they are
the ports of the remote.
So we have:
rtp_port as the local address we are binding to
net_rtp for the network rtp
bsc_rtp for the bsc rtp
|
|
This way the mgcp will allow anyone to be the BTS..
in the future we might need to communicate things
properly between BSC and MGCP.
|
|
|
|
Add a small helper to determine the type of a message
|
|
|
|
|
|
|
|
First code to simply forward the data, no filtering or patching
is in place. This will need to happen soon.
|
|
|
|
|
|
|
|
|
|
Use the connect_to_msc method to connect to the MSC and
create structure to handle and forward messages to the
real BSC.
|
|
|
|
Harald actually pointed out that this feature is just NAT. We want
to connect n-real BSCs to one BSC Mux. We will talk the ip.access
protocol and SCCP over of this link.
The mux will drop certain GSM messages (like the reset), it will
replace source local reference (NAT functionality) and it will handle
some GSM08.08 specially.
Get the thing started...
|
|
Currently "write memory" will not store the rtp_base_port of the
network. Fix that by writing it out in write_net. Also set it to
4000 by default in the MGCP and in the BSC.
|
|
|
|
The LAI generation wants to have 16bit unsigned, just keep
them like this already. This means the int32_t will be truncated
inside the get_*_code methods which is better than doing it
somewhere else.
|
|
-1 is assigned in case the variables are not set. This means
it must be a signed type (as the comment says), now really use
a signed type.
|
|
We want to use the real number on the Um... Using the core
network code is totally wrong in this scope...
|
|
* Be able to have a country code in the air but use a different
country code when talking to the core network.
* Now both country and network code can be different on air and
on the MSC communication.
|
|
This is partially reverting 0603c9d9e58b5d29105361a89ab8cb295da29366,
it is true that the ip.access Wireshark dissectors differentiate
TCH/H from TCH/F but in my test I'm unable to send RTP on to the
BTS. It might be that the RTP payload provided in the MDCX is not
the one it will accept with the 0x05 mode. More work needs to be
done to understand this, that is the reason it is comitted to the
on-waves's branch instead of master.
|
|
* Make it possible to have a different MNC in the RSL traffic
than in the core network.
* Introduce the "core network code NUMBER" variable. If it is
set this network code will be used in traffic with the MSC.
* Use the core_network_code number when sending a packet to
the MSC
* Regenerate the LAI (this is where I could have a bug) when
sending packets to the BTS.
* Add size checks.
This is not tested, I might got something wrong.
|
|
* It is the same as local endpoint port
|
|
* Add the new forward audio option
|
|
|
|
With forward IP in the config and early bind on we will
simply forward RTP data on the endpoints from BTS to the
forward IP address.
This is implemented by disabling MGCP functionality when
a forward IP address was specified, setting the forward IP
in the endp->remote and assigning a ci != CI_UNUSED.
Early bind will make sure the sockets are created, the BSC FD's
are registered and then the normal dispatch code will
do the forwarding.
|
|
* For half rate we also need to set the 3rd bit to one
* See GSM08.08 §3.2.2.51 and then §3.2.2.11
|
