| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously we were sending a generic "Resource unavailable" cause code making
it impossible to distinguish real error cases from a regular radio link failure.
This was the reason for many "unknown" call errors we've seen at Rhizomatica
installations. Now they are properly classified as non-erroneous call failures.
|
|
|
|
|
|
Before:
<command id='osmux dummy (on|off)'>
<params>
<param name='osmux' doc='RTP multiplexing' />
<param name='dummy' doc='Enable dummy padding' />
<param name='on' doc='Disable dummy padding' />
<param name='off' doc='(null)' />
</params>
After:
<command id='osmux dummy (on|off)'>
<params>
<param name='osmux' doc='RTP multiplexing' />
<param name='dummy' doc='Dummy padding' />
<param name='on' doc='Enable dummy padding' />
<param name='off' doc='Disable dummy padding' />
</params>
</command>
Note the 'null' string in 'off'. Reported by Holger.
|
|
|
|
Mike's patch included clean-ups I want to apply separately and
change them a bit. If we return from an else we don't need to
put the else.
* Try the E1 trunk first
* Then try a local virtual trunk
* Fail if none of the above returned
|
|
Remove the host portion of the endpoint Id. This requires less
configuration and we are probably fine to trust that MGCP only
received messages designated for it.
|
|
|
|
In the 1900 MHz PCS band, we always generated neighbor cell lists
consisting of only a single neighbor cell, rather than al the
configured BTSs.
|
|
|
|
|
|
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.
|
|
The spec unfortuantely uses both terms and has no consistent spelling,
but in our logging output we can at least try to be consistent.
|
|
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.
|
|
|
|
|
|
|
|
The same radio link timeout value is used for BTS and MS side.
|
|
|
|
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]
|
|
We want the port and IPv4 address to be extracted but don't
expect any change in audio codecs.
|
|
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.
|
|
This struct was removed when we switched to strtok_r for
parsing the data. Remove the left-over.
|
|
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
|
|
For debugging it is nice to know how many requests are
pending. Simply count it and print it besides the paging
part.
|
|
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 SMPP payload didn't include the right fields we
would leak the subscr reference count.
|
|
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.
|
|
So in case somebody is starting paging from within a paging
expired callback we would dispatch the paging request right
away with the same failure.
|
|
|
|
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);
|
|
Signed-off-by: Max <max.suraev@fairwaves.co>
|
|
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]
|
