This was reported by Kevin when he was testing handover. The problem
is the order of the signal handlers for S_ABISIP_CRCX_ACK. Right now
the handover signal handler is called before the one inside the libmsc
gsm_04_08.c. This means S_HANDOVER_ACK is signalled _before_ there is a
rtp socket created for the channel. The result is that the MDCX will
never be sent and the called will not be properly switched _after_ the
handover detection.
I do not want to play with the order of signal handlers, remove the
CRCX ack handling from the handover_logic.c and force the NITB (and
later the BSC) to check if the lchan is involved with a handover and
do the switching in there. This means right now we do what two signal
handlers did in one.
Reproduced and tested with the FakeBTS Handover test.
Log message:
<0004> abis_rsl.c:1954 (bts=1,trx=0,ts=3,ss=0) IPAC_CRCX_ACK ...
<000c> gsm_04_08.c:1400 no RTP socket for new_lchan
<001a> rtp_proxy.c:533 rtp_socket_create(): success
<001a> rtp_proxy.c:615 rtp_socket_bind(rs=0x48703c8, IP=0.0.0.0): ...
In case of handover (but probably on RACH) we would send a RLL for
SAPI=0 even if this SAPI was never established. After we have released
all SAPI>0 locally check that SAPI=0 is established and if not release
the rf channel directly.
T3109 is started when the SACCH is deactivated. It is stopped when
the phones sends the DISC/UA/UM on LAPDm for the main signalling
link. In case of timeout the abnormal release procedure will be
initiated. Make sure to not issue the SACCH Deactivate twice to
avoid confusing the equipment.
This is still not fully spec compliant. In case of a timeout the
abnormal release handling will be started which involves starting
T3111+2. The error handling should be split out of the rf channel
release method, e.g. lchan_release should be called and check if
the channel release was already initiated.
If the CHAN ACTIV is NACKED we set the state backto NONE. This is
problematic as our channel allocator will allocate from the front
or from the back and if the channel is early in the list it might
cause permanent failures. Introduce a BROKEN state and use it when
the channel activation is failing for an unknown reason. Copy the
cause so it can be inspected later.
* Release all channels with SAPI > 0 with the "local end release"
(as of NOTE 1 of GSM 04.08).
* No need to wait for all SAPIs to be torn down and the normal
REL_IND/REL_CONF will call rsl_handle_release and the channel
should be released.
* Update the documentation
MGCP is used over UDP and a response might be lost. The MGCP RFC
asks for keeping a list of responses and then using the previous
response to answer a duplicate request. I tried to conserve memory
and just wanted to remember the last transaction identifier and
result-code and re-generate the result from that. This made the
code look bad and this is why the entire response will now be stored.
It sadly increases the memory usage but can not be avoided at this
time.
Remove the msg->l3h pointer for the RQNT callback as strtok has
modified the content of it.
Rebased, tested and fixed by Holger Freyther. Release the transaction
only once the SMC is asking for the release and set the cb's to NULL
to catch a use after free early.
This has been rebased and fixed by Holger Freyther. The change of
the debug area was split out in a previous commit and the is_mt was
put back into the transaction code.
The transaction is now freed from the RELEASE_REQ sent by the SMC
layer and not inside the error path. When clearing the SMC instance
we also clear the callbacks.
This is more a work around and one still needs to implement a
proper dispatch on the opening of the connection. If there is no
operation left, no transaction and no silent call, close down the
channel.
Move to the control command handling out of the main file into
a dedicated module. There are still some calls embedded into the
main code but it will be moved soon.
Use a usec timestamp for the local time. The seconds to usec will
swap over to the lower bits but this appears to be correct. The
CLOCK_MONOTONIC is used to fulfill the RFC 3550 requirement even
if it is a bit slower than the gettimeofday.
Make sure to initialize transit in a way that the first transit
time will be 0. Otherwise the jitter will contain the difference
of the localtime and the remote time.
Calculate the expected packages and packet loss as of RFC 3550.
The values should be clamped but our packet loss counter is 32
bits and not 24 and we should clamp at other values but I am
waiting for some issues first before dealing with that.
This is missing the probation and the dealing with a remote
restart. For the remote restart we will simply write a log
statement as this is unlikely to happen during a call or if
it does happen the call will be taken down by the BSC anyway.
Align the naming inside the mgcp_rtp_state with the naming inside
the 'source' struct of the appendix. Make first_seq_no/base_seq
a uint16_t. This is removing rules for alignments and reduces the
struct from 40 bytes to 36.
Count the received octets. This is encouraged by the MGCP specification.
Use a 32bit counter that is good enough for more than 12 hours of a EFR
call. This limit is good enough for the current configuration.
The RFC 3435 specifies a different formula for calculating the lost
packages. It involves the number of received packages and the delta
of the sequence number.
The previous code didn't work as expected. The trx and dst pointer
are located in an union and in the case of the Abis code the dst
is used to point to the signalling link timeslot and not the TRX.
The is_ipaccess_bts always returned false because the dst was casted
to a trx while it was no trx.
This fix was tested with the nack_test/NACKTest.st of the test repo.
I saw the old copy of the "Appendix J" code too late and I have
discovered some quirks and I am more familar with my implementation.
Most noticable 'w' only needs to be as big as the input arfcn but
requires the 'w' to be initialized. The power_of_2 implementation
differs as well (mine matches the output of wirehsark).
The f0 could be chosen in a better way but right now picking
the lower bound is the easiest. It is not clear if to use
modulo if the range is chosen in the middle. This can be improved
in the future. Right now I have no bit fiddling for range128, 256
and 1024 as I was running out of time.
The first fields are still the location up to the height.
The next field is "operational" if any of the trx are operational,
otherwise "inoperational"
The second to last field contains "locked" if all of the trx are in the
admin state, otherwise "unlocked".
The last field represents the rf policy currently in effect. It is one
of (on|off|grace|unknown).
<tstamp>,<valid>,<lat>,<lon>,<height>,<oper>,<admin>,<policy>