When using multiple interfaces on a system one can now configure
which will be served for the BTS ports and which will be served
for the network. The direct usage of source_addr is now only to
initialize the MGCP receiving port itself.
Make it possible to bind the call-agent to a specific IP address
and the network and bts end to different ip addresses. Begin by
clarifying which source ip address we want to have.
Use the existing ulaw encode/decode to support PCMU as well.
The MERA VoIP switch has some severe issues with the GSM codec
and it appears easier to enable transcoding for it.
The mera switch doesn't appear to cope with codec change
between a SIP 180 trying and the 200 ok connection result.
Inserting the codec is touching too many places. Ideally we
should have the transcoding function as pointer in the struct
as well but the arguments differ.. so it is not a direct way
forward.
Iridium is a satellite network which operates a GPRS-like that allows you to
get speeds up to 128kbit/s. However, it takes from 5 to 6 secs to get the
bandwidth allocated, so the conversation is garbled during the time.
This patch uses the new dummy padding support in libosmo-netif that is
controlled through the osmux osmux_xfrm_input_open_circuit().
This includes a new VTY option for osmux.
I guess none of our users knows what a mi_type=0x02 is, but most would
know what an IMSI or a TMSI is. So let's use the newly introduced
gsm48_mi_type_name() function to fix this.
For some odd reasons the XID is not a separate SAPI but has been kludged into
the GMM SAPI. This means we ahve to be careful not to dispatch XID frames into
GMM. We do this by introducing an explicit check for UI frames before the
dispatch to GMM.
The previous code already was doing "the right thing" but printed occasional
messages like "gprs_gmm.c:2082 Unknown GSM 04.08 discriminator 0x01: 01 00 0e
00 32 11 03 16 01 90 63 28 0b". Those should be gone after this patch.
Traffic cannot sent to BTS, if there is (currently) no logical channel
associated with the transaction.
This happens, if TCH traffic is received from upper layer, but there is
no lchan available before completing immediate assignment, handover or
assignment process.
[hfreyther: The code has not been moved to tch_frame_down
but the issue looks similiar]
The NAT sends an incomplete SDP file for the purpose of informing
the BSC about the remote IP/PORT early. The case of an incomplete
SDP file was not considered. Check if there is a codec and if not
skip it.
TODO: We need to have a better end-point life cycle test.
Move forward while preserving the legacy handling. Beging to
extract SDP rtpmap information and select codecs atfer this.
It is a foundation we can now build further and better check
ons.
We have a lot of legacy that I am afraid to break. We have
everything in place to make a good codec selection (e.g. if
we can avoid transcoding, pick the one with best quality or
the lowest speed). Right now I have a specific case where
from all options I want to pick GSM. Guard the codec compat
check behind the disallow transcoding option to make sure
to not break legacy application.
First collect everything we know and the mapping. E.g. a genuis
could remap "3" to "AMR" so we only know the codecs once we are
at the end of the SDP file. Once we have collected everything we
can select the audio codecs. The current code is compatible in
that two codecs will be selected regardless of if they make any
sense or not.
mgcp_set_audio_info could re-use some of our codec information
but then the caller in the MGCP protocol needs to be updated as
well as we use the "I: GSM" information to derive the codec from
there.
The SDP file handling will get more complicated in terms of
codec selection so let's remove it from the protocol handling
before we start blowing it up in size.
The parsing code assumed that there will be a single payload
type and this assumption is clearly wrong. Forward all of the
payload types. The code is still only extracting the first
type from the list. The variable name has been renamed to
reflect this.
Using the talloc leak report we see that there are some msgb's
that are allocated for SMS but we don't have transactions or
SMS around. We need to improve the name of the messages to
uniquely dscribe where they are from but the obvious leak does
occur in this routine.
The no available transaction id is most likely the case where
we leak memory. This should not occur and shows another issue
with the smsqueue/smpp handling. It doesn't explain the subscr
reference count issue either.
Extract of the leak report:
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x2517dc0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x24b56e0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x23e7930
At the rhizomatica sites some unauthorized subscribers have a
last used from long time ago but a bigger reference count. This
means that we have an unbalanced subscr_get/subscr_put that we
need to investigate. These two fixes are genuine fixes but are
unlikely to fix the issue I am not understanding yet.
In case the subscriber is currently busy we would omit the
subscr_put. This seems to be very hard to hit as the subscr
need to be active and at the same time be selected for the
purge operation.
Various paging clean-ups. I couldn't re-produce the assert that
was hit by Rhizomatica in the subscriber code. Let's clean things
up a bit to avoid some of the potential issues this code had.
Always stop paging regardless of where the subscriber is at the
time of the cancellation.
As the comment says we should not rely that the paging
occurs on the current LAC. We might page at more BTS.
Walk all the BTS to stop paging. No callbacks will be
issued by this stop operation.
In case we can't page on a BTS then stop it everywhere. The
callers of paging_request assume that this is kind of an
atomic operation and we should help with that.
Coordinate with the normal subscriber channel requests instead
of going to page ourselves. This might lead to getting a channel
that is of a different type though.
vty_interface_layer3.c:584:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=]
sizeof(subscr->extension)-1, VTY_NEWLINE);
When two phones use the same TMSI and no A3A8 is possible
we could end in a hard to detect issue. Assume that the IMSI
will not clash and we have issues for foreign simcards.
In case foreign simcards are used we can not do authentication
and ciphering. In case a TMSI is re-used too early and we do
page using TMSI we can't know which of the two MS is responding
to us. We could change the "secure channel" routine to ask for
the IMSI and only then stop the paging.
As we don't have ciphering there is not much use in using the
TMSI. Add a mode "no assign-tmsi" that will not assign the TMSI
during LU. Now CM Service Request and Paging Response will
work using the IMSI. There can't be a clash with that.
[ciaby fixed the vty write to use the right name]
When we can't find the TMSI then the subscriber is not in our
VLR. We have not consulted with the HLR and it is better to not
use such a severe error code.
in_address is not 'accidently' included by FreeBSD when we include
the osmocom/core/select.h header file. We need to include a bit
more.
In file included from mgcp_protocol.c:38:
../../include/openbsc/mgcp_internal.h:134:21: error: field has incomplete type 'struct sockaddr_in'
struct sockaddr_in forward;
List needs to be executed from within the right configuration
node to see if it is available or not. list on the toplevel
will uncoditionally show "smpp" as part of the logging config.
Struct osmo_msc_data contains int core_ncc, which is actually the
MNC part of the PLMN, not to be confused with the Network Colour
Code.
The following patch renames this field for clarity and consistency
with the standards.
If we have tried SMPP first and it was not routable, and then
tried the local delivery there is no point in trying SMPP with
the same parameters again. Leave early and return unknown sub
to the caller.
default-route would only be looked at after there has been
no subscriber in the local database. Depending on the setup
this is not what one wants. This has been discussed at the
OsmoDevCon and there have been hacks in some branches. Let's
introduce a VTY command to select if SMPP should be consulted
first and then fallback to the current behavior.
Holger Hans Peter Freyther
Harald Welte