| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Spotted by Ciaby while debugging an audio issue. Do not
send anything to port==0 to the BSC/NITB. Look at the
upper bits of the speech_mode to determine if sending is
allowed. 0x1 means recv_only and all other modes allow us
to send.
Manually verified with a single phone call with LCR bridge
mode to send a CRCX early but a MDCX sendrecv later. The
audio starts to flow after the MDCX message. Virtual Addr
space didn't increase over 10 calls. The l1p_msg is freed
by the caller.
The code might not re-set speech_mode from one call to
another but if it is ever != 0 it can be expected that
the BSC will always set it. This is because we do not
(and don't want to) allocate the lchan dynamically on
every usage.
Fixes: SYS#2111
|
|
tch.c: In function 'l1_to_rtppayload_amr':
tch.c:247:29: warning: unused variable 'amr_mrc' [-Wunused-variable]
struct amr_multirate_conf *amr_mrc = &lchan->tch.amr_mr;
^
tch.c: In function 'rtppayload_to_l1_amr':
tch.c:335:10: warning: unused variable 'amr_if2_core_len' [-Wunused-variable]
uint8_t amr_if2_core_len = payload_len - 2;
|
|
We need to patch the CMR due wanting to support systems that still
have Audiocodes hardware in their chain. I have manually tested
and could listen to my own voice on:
TCH/H & AMR 5.9 & PTSN & BSC
TCH/F & FR1 & Other subscriber & NITB
TCH/F & EFR & Other subscriber & NITB
TCH/H & HR1 & Other subscriber & NITB
TCH/H & AMR 5.9 & Other subscriber & NITB
The tests were done using the Nokia E71, a Blackberry curve and
for the PTSN a HTC 8S were used.
|
|
For LCR and other systems without out-of-band information we need
to indicate the CMR. Not every air message will include the mode
and we sent a stream that had the CMR set and not-set. This lead
to the AudioCodes MGW only playing every second frame.
Remember the last used mode and initialize it to _NONE when we
receive the multirate config. In case of a real error we will
still use AMR_CMR_NONE.
The initial patch is from Harald. I have added the initialization
and moving of the defines to amr.h.
Manually verified by enabling AMR5.9 and looking at two RTP
packages in sequence. In both cases the CMR was 2. I have looked
at "amr.nb.cmr != 2" in wireshark and only found the MGCP dummy
packet.
|
|
Enable the previously commented-out logic to set the CMR (Codec Mode
Request) in AMR RTP frames based on the CMI (CMR Index) of the AMR
speech frame on the Um interface.
This is of course anyway the right thing to do, but also required for an
AMR receiver which doesn't have out-of-band information on the codec
mode, and which also doesn't determine the AMR codec mode based on the
size of the AMR frame (such as lcr as of current master).
We also move the entire CMR generation into the #ifdef section
which is only compiled-in if we do _not_ use the RTP mode of L1.
|
|
The sysmoBTS takes quite a bit of CPU time for the vfprintf that
is used by osmo_hexdump. Do not dump every single frame to improve
the performance a bit.
|
|
this allows the BTS to loop-back any incoming data on a TCH
|
|
In L1 RTP mode, the L1 already does all the bit-shifting and re-ordering
required for the RTP formats (which have different bit/nibble order than
the ETSI/3GPP encodings, for some odd reason).
We don't enable it by default yet, as only HR/FR/EFR work with it, but
AMR has some yet to be debugged problem.
Enabling USE_L1_RTP_MODE would save some CPU cycles on the ARM side.
|
|
|
|
Attempt to catch all functions that allocate a msgb and didn't
check the return value of the allocation.
|
|
|
|
|
|
repeating the last SID frame is required during 20ms intervals where we
don't get a new SID update (SID RTP frames are valid up to 160ms)
|
|
|
|
* parse AMR multirate config form 04.08 IE into easier format
* CMR, CMC and CMI on the L1 side are an _index_ into the current
mode array
* Fix conversion of AMR SID frames from RTP -> L1
|
|
We have to make sure that a phone cannot request codec modes which are
not part of the active set...
|
|
We don't really know if the HR encoding is compatible with other
equipment, but it _should_ follow Chapter 5.2 of ETSI TS 101 318.
Please note that RFC5993 also specifies a way to encode GSM-HR into RTP,
we do not try to be compatible with that. The only difference seems to
be one additional TOC octet at the beginning of the payload field.
|
|
Using osmo-bts-sysmo and this code, it is now possible to do FR and AMR
based voice calls on TCH/F.
A lot of CPU is wasted in the conversion between the RTP formats and the
L1 specific formats for the codec frames. All data needs to be shifted
by four bits, and the order of bits needs to be reversed in every byte.
|
|
|
