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
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 unix select function returns a set of file descriptors to be
handled. the result-loop (the loop after the select()) is called again,
if more than one descriptor is removed by the callback funtion. this may
lead to a another call to the callback function, because the bits of the
FD_SETs do not change and still set.
i think we must clear these bits, if they are handled, so the handler
will not be called twice in case of a "restart" of that loop.
The way the VTY configuration sytem works is that it first registers a
BTS of type GSM_BTS_TYPE_UNKNOWN and then sets the type correctly (after
encountering the type statement). This makes sure that registering a BTS
of type UNKNOWN succeeds.
In 39315c4798 we introduced
per-bts OML attribute parser definitions and disallowed
a BTS of type unknown.
However, the VTY code first allocates a BTS with unknown type.
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.
Some NM attributes are defined differently depending on
the BTS type. Having one big nm_att_tlvdef[] table for
all BTS types is no longer sufficient. This patch
* introduces 'struct gsm_bts_model' to describe a BTS model
* adds definitions of gsm_bts_model for BS-11 and nanoBTS
* changes the abis_nm_tlv_parse() function: include a bts pointer
Currently starting with the opencfg.cfg.nanobts and writing it out
and then trying to start again will not work. The network reject_cause
is initialized to 0 which is not a valid reject reason and when writing
this to the config file and trying to parse it will fail.
Pick roaming not allowed as a harmless option to those phones
accidently trying to connect to the BTS.
These commands let you change the PLL set and work values. Many thanks
to Dieter Spaar for figuring out how to do this!
Now you can just reset your PLL work value if it drifts away due to your
E1 card.
Use it like this: bs11_config pll-workvalue 1000
Whether this function changes the set or the work value depends on your
type of login. In FACTORY login it changes the set value, in FIELD login
it changes the work value (which is what is used by the BS11 to tune the
frequency).
This is useful information to know and actually fixes a segfault
in rllp.c where lchan is accessed even tough it could be NULL in
case of failure.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
At least some nanoBTS 139 send the last even (going online) as
'enabled' 'unlocked' but no avail status IE (which I guess mean an empty
set, the doc 12.21 isn't that clear about that).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Follow up on 424c4f0e29. As pointed out
by Sylvain on the mailinglist I need to remove this here as well.
Do not call db.c code from code that is located in libbsc.a
vty_interface.c is part of libbsc.a but it started to use code
which is found in db.c recently. Fork the subscriber dumping and
provide more information on the layer3+ (MSC) commands. This
is restoring the separation again.
Holger Hans Peter Freyther
Harald Welte
Sylvain Munaut