A client may know the IP address during CRCX but not yet the port, or it
may simply want to hint an initial IP address so that the MGW can better
guess when allocating a local IP address.
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote port is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any address or port.
An osmo-mgw client (eg. osmo-hnbgw) may wish to initially set a remote
IP address as a hint during CRCX, hence the IP address may already be
set while the port may be unset.
We have proper IuUP support and everything about this legacy hack should
The purpose of this function is to validate that RTP is coming from the
expected address and port. To allow that legacy IuUP hack, which is no
longer needed, we punched a hole into this validation, by adding this
special case for loopback mode (suddenly we don't care who or what sends
RTP and bounce it back to anyone). So let's get rid of this hole that
was only needed for very early 3G voice hacking.
Instead, we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote IP address is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any remote address if the remote IP address is not yet known.
If we refuse the IuUP Initialization, a 3G RNC may fail to set up a RAB.
We will know the remote address only *after* assigning a RAB succeeded.
So the IuUP Initialization must be allowed before knowing all addresses.
At the time of writing, CRCX for IUFP are sent to osmo-mgw in either
LOOPBACK or in RECVONLY mode:
- current osmo-msc: recvonly
- osmo-msc <= v1.10.0: loopback
- osmo-hnbgw: loopback
IuUP Initialization should work regardless of that.
See also next patch I158dd046fdfcb10392cde3de8cc88dd095a05b40
IuUP is one layer below the loopback/send/recv decision for RTP; IuUP is
always terminated at the MGW, while the AMR payload carries through.
Related: alternative patch Idd833997abce46886e9664505b2776fa5dadc8db
A typical OS imposed limit is 1024 open FD, which can bee too low when
there are hundreds of concurrent voice calls.
In systemd service file, set a super high limit of 65536.
In osmo-mgw's user manual, add section 'Configure limits' describing
this in detail.
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
A user reports crashes of osmo-bsc upon EV_MDCX. It turns out that there
is a lot of error reporting and a distinct possibility to get a NULL
return value because of external input. Terminate the FSM instead.
FSM termination is the proper way to report a bad error, it signals the
parent_term_evt to the FSM parent, which will then be able to act on the
failed MGCP operation.
CONN: (1226/rtp, id:0xD94316AD, ip:127.0.0.2, rtp:2344 rtcp:2345)
CONN: (1226/rtp C:D94316AD r=127.0.0.2:2344<->l=127.0.0.1:4002)
While changing that string, also include these changes for consistency
- use the same r:...<->l:... format as osmo_sock_get_name().
- Instead of 'id:0x' use the actual MGCP format 'C: 9B686BE3'.
- drop the commas
- drop RTCP port: it is always RTP+1 and always an odd number.
The CONN pairs associated with each endpoint show remote RTP
ports. When osmo-mgw is being used by both BSC and MSC, one
side of the pair is showing the internal loop connection inside
osmo-mgw, while my intuition suggested this connection pair
is showing me the RTP port tuple of a single RTP stream. Adding
the local port to the display makes it more clear, IMHO.
Seeing the local port can also help to correlate the MGW vty
dump with a capture of RTP.
I first tried directly using osmo_sock_get_name_buf() on
conn->u.rtp.end.rtp.fd, but that might hide already known information
when the fd is not actively used yet (before SDP): the local address and
port would then be shown from the fd, not from
conn->u.rtp.end.local_addr/_port == hidden before the fd is set up.
Patch-By: whytek, nhofmeyr
The mgcp client may first configure the connection to use RTP-AMR, but
after setting up another call leg may find out that both legs are IuUP
and hence want to forward the IuUP between the 2 connections instead.
In that case, an MDCX with codec VND.3GPP.IUFP would be set.
Until now, osmo-mgw didn't take that scenario into account, and it was
only upgrading the rtp conn to iuup internally during CRCX.
As a result, in the mentioned scenario osmo-mgw would continue to
output RTP instead of IuUP after the MDCX with VND.3GPP.IUFP, which is
For each RTP packet that is received from a connection, the mode is
checked whether receiving is allowed or not. If not it is discarded.
In case of "confecho" mode, the RTP is also sent by the receiving
Then a loop is used to send RTP to all sending endpoints except the one
that received the packet.
Because we have a loop that allows to have 1..n connections, we have no
maximum number of allowed connections anymore.
The new mode "confecho" is similar to "sendrecv", except that it also
echoes back RTP towards the sender. This is required for voice group or
broadcast calls. Talker and listeners use the same timeslot, so that
audio must be echoed from the talker to the listeners.
It is different from "loopback", because a loopback only echoes back RTP
towards the sender, but does not forward audio through the endpoint to
the other connections. Also it does not forward RTP from senders of
The current implementation of MGW does not support transcoding and
mixing. This means that a sending connection must not send RTP that has
been received by multiple receiving connections. The application that
uses the MGW has to set the connection modes, so that only one
connection receives RTP in case of a conference.
In the "L: a:" header, read the first codec name only up to the ";"
separator, and ignore the rest.
According to RFC-2705, the "L: a:" header may include multiple codecs
like "GSM-EFR;GSM" in:
L: p:20, a:GSM-EFR;GSM, nt:IN
osmo-mgw can handle only a single codec here. Since recently, osmo-msc
is our first client that may actually send more than one codec. This
uncovered a bug that leads to failing voice calls:
* osmo-mgw parses the entire list "GSM-EFR;GSM" as a single codec name,
* puts that into the ptmap without scrutiny,
* and even sends it back in the OK response, in the *SDP* part, as a
single "GSM-EFR;GSM" codec entry.
We do not care very much about the "a:" codec list, because we always
establish codecs via SDP later. So all we need to fix this is: parse the
first codec done correctly, and ignore the rest.
This way if keepalive becomes disabled for an MGW, it can be selected
again (otherwise it would become non-selectable forever, and we already
have a "blocked" config for that).
In the previous logic, if "keepalive request-interval" was disabled
(value 0, default), then if the client was configured to send a DLCX on
startup it would end up in state UP or DOWN depending on whether the MGW
answered to that request.
As a result, an MGW that wouldn't answer would be left forever in DOWN
state since it would have been selected no more and there would be a
keepalive configured to re-mark it as UP.
The `keepalive` feature in libosmo-mgcp-client allows scheduling periodical
queries on the MGCP layer in order to make sure it is reachable and hence
obtain information on the state of the MGCP link.
This patch only uses it to print the status on the VTY, but it will be used
too in a follow-up commit by the MGW Pool when picking an MGW from the pool:
MGWs whose link is considered to be DOWN are skipped.
The feature consists of:
- A `keepalive request-interval` which will trigger a transmission of an MGCP
AuditEndpoint command targeting endpoint with name `keepalive request-endpoint`.
This interval is updated every time any message is transmitted in the MGCP
link, meaning the MGCP AuditEndpoint message is only triggered if no message
has been transmitted since `keepalive request-interval` seconds ago.
- A `keepalive timeout` considering the MGW to be non-reachable (link DOWN) if
no message is received over that amount of time.
The `keepalive` parameters are to be preferrably configured so that
"keepalive request-interval" * 2 < "keepalive timeout".
Example VTY configuration of `keepalive` feature in libosmo-mgcp-client:
keepalive request-interval 20 <1>
keepalive request-endpoint null <2>
keepalive timeout 50 <3>
<1> Transmit an MGCP AuditEndpoint message to the MGW if no message has been
sent to it over last 10 seconds
<2> The MGCP AuditEndpoint targets the `null` endpoint. This is a special
endpoint available at OsmoMGW for those purposes, but any available
endpoint can be configured and used instead.
<3> Consider the MGCP link to be DOWN if no message is received from the
MGW over the last 50 seconds
NOTE: The `keepalive` feature is disabled by default, and must be explicitly
configured in order to enable it.
This is a special endpoint which can always be audited. This is useful
for clients who wish to submit requests to osmo-mgw periodically to find
out whether the MGW is still reachable. This endpoint will be used by
libomso-mgcp-client as default target endpoint to implement such
This "null" Endpoint is osmo-mgw specific, not described in MGCP specs.
So far, the users of the old non-pooled API were in charge of allocating
the struct mgcp_client_conf by themselves, then init them using
mgcp_client_conf_init(). This causes a major problem, since it makes it
difficult to extend the struct mgcp_client_conf structure to add new
features, which may happen frequently.
The MGW pool API doesn't have this problem, because the struct
mgcp_client_conf is allocated as parts/fields of private structs defined
in internal headers. Only pointers to it are used in public headers.
Since it still has to internally initialize the conf fields, we still
need the API to initialize it internally, and hence why is it marked as
DEPRECTED_OUTSIDE instead of DEPRECATED.
While some programs already moved to the new MGW pool infrastructure,
they still use the old APIs to accomodate for old config files in order
to be back-compatible, hence most users of libosmo-mgcp-client are
Introduce an API to allocate the conf struct internally, which, while
still breaking the ABI, allows for a more relaxed update path where it's
possible to extend the struct mgcp_client_conf at the end.
Eventually the non pooled API should be gone and the struct
mgcp_client_conf can then be moved to a private header, but for now
let's add this small feature to avoid major ABI breakage.
Some payload type numbers are defined in 3GPP TS 48.103, let's put the
spec reference between all of those so that it is immediately clear
where those numbers come from.
When two codecs are checked for convertibility we insist that
subtype_name and rate are equal since normally when those are different,
we assume a completely different codec that will require a transcoder,
which we do not have yet.
However when IuFP is used, the call agent will always negotiate IuFP as
VND.3GPP.IUFP with a rate of 16000, even though the IuFP payloads
contain regular AMR at a rate of 8000.
This means that if we detect IuFP on one side of the call leg and AMR on
the other side of the call leg, we must not insist on equal subtype_name
This fixes the following TTCN3 testcases:
When a call leg is set up, then the call agent (e.g. BSC, MSC, etc.)
will also negotiate a codec along with a payload type number. When
sending RTP packets, each RTP packet must also contain the negotiated
payload type number. To prevent the emission of RTP packets with an
incorrect payload type number, ensure that no packet is sent when
Unfortunately OsmoMGW was never really tested with multiple different
codecs on either side of the connection. While OsmoMSC and OsmoBSC only
assign exactly one codec on each side this has never been a problem,
however it might become a problem when a call agent assigns multiple
codecs on one side. This has been observed in a setup where OsmoMGW had
one leg towards an external call agent. Also due to recent upgrades to
the TTCN3 tests we are now able to simulate different codecs on both
sides to pinpoint issues.
Testing has shown that OsmoMGW has difficulties with multiple codecs.
The reason for this is that the function that makes the codec decision
was not fully finished. So let's finish the codec decision function and
let's also use that decision when patching the payload type of outgoing
In a follow up patch we intend to fix mgcp_codec_decide, since the
fixed version of mgcp_codec_decide will use some functions below its
current position let's move it down before fixing it to make reviewing
the changes easier.
- do not msgb_free() within these functions. Just return error, and move
the msgb_free() to the caller.
- when failing to write to the msgb, directly return error.
Check if the private struct mgcp_client_pool has an empty member_list.
Clients that support both the legacy config and the pool config can
use this to properly exit with error if pool members are configured,
but no connection to any of the pool members can be established.
Currently clients can't distinguish a config without pool members and a
config with pool members that is broken and will fall back to using the
defaults of the legacy config in both cases.
in mgcp_codec.c we have a function mgcp_codec_pt_translate that is used
to find the equivalent payload type number on an opposite connection.
This is quite specific and the resulting payload type number may still
belong to a codec that might require some form of conversion.
Lets refactor this so that the function just finds a convertible codec
for a given connection. This also opens up other usecases. The payload
type conversion like we did it before can then be done with a few lines
The function mgcp_codec_pt_translate is very strict when comparing the
codecs to each other to find a matching payload type number to be used
on the egress side.
This poses a problem when one side uses AMR in bandwith-efficient, while
the other side uses AMR in octet-aligned payload type format. To the pt
translate function the difference in the payload format will appear as
if the codec were different and eventually the payload type number
cannot be translated.
since osmo-mgw offers conversion between the payload type format it
would be no problem to ignore the payload type format when making the
translation decision. The only exception here would be if one side would
announce AMR two times, the first time with octet-aligned and the second
time with bandwith-efficient format. Then we would have to use the
payload type number from the exact match. (and skip any formatconversion)
To archive such an optimized decision we will first go through the codec
lists and perform an exact match. If we don't get a match we go through
the codec lists a second time, but this time we ignore the payload