When receiving MGCP responses, so far libosmo-mgcp-client completely
ignored a=fmtp: parameters (like 'octet-align'). Add fmtp parsing to
pass the fmtp string to the caller as-is.
Since the responses so far never included the octet_aligned flags, do
not bother to parse fmtp to populate the legacy items. New callers
should use the fmtp string.
Change-Id: If8ca5c3880cad9e41b80e9d1c821439b0d7b7e23
Remove the limit of having only one AMR octet-aligned fmtp parameter per
MGCP message. Instead allow any arbitrary fmtp options, one per every
codec.
Deprecate all use of struct mgcp_codec_param. Instead, store and pass
plain fmtp strings.
Provide legacy shims that still act correctly for any callers that may
pass the old struct mgcp_codec_param. (I'm not sure if we need to keep
this, but we can always drop it in another patch.)
Adjust one mgcp_test.c: instead of returning only the octet-aligned
parameter, now osmo-mgw keeps and returns all the fmtp parameters that
the user provided. So add the missing "mode-change-capability".
Related: OS#6171
Related: osmo-msc Ief9225c9bcf7525a9a0a07c282ffb8cc0d092186
Change-Id: If58590bda8627519ff07e0b6f43aa47a274f052b
Add new noinst-library libosmo-sdp.la.
It will be used by
- osmo-mgw
- libosmo-mgcp-client
- callers of libosmo-mgcp-client may use SDP message parsing (osmo-msc)
The API will, with upcoming patches:
- parse and compose SDP fmtp strings
- manage SDP codecs and codec lists (like 'AMR:octet-align=1#112')
- parse and compose entire SDP messages
In this patch: parse and compose SDP fmtp strings.
Add libosmo-sdp build fu.
Add sdp/fmtp.h and sdp/sdp_strings.h.
Add tests/sdp/sdp_fmtp_test.c.
Change-Id: I6128852f4d249e90319f43d6cd6ed0a9a2ed0430
.la libs aka LTLIB can include library dependencies.
Rationale: An upcoming patch adds noinst libosmo-sdp, used by both
osmo-mgw and libosmo-mgcp-client, and the cleanest way to link that is
via a library dependency. Prepare for that.
Change-Id: I5302d56e571d0da9061c275ce13d4f085c044671
Before this patch, when an CRCX+MDCX wants to set a codec list that has
no match with the codecs for the other conn of that same endpoint,
osmo-mgw returns an MGCP "FAIL" response.
When a client wants to change the codec, it has to do that one RTP port
at a time. So osmo-mgw *must* allow to configure an MGCP conn with a
codec choice that mismatches the other conn.
This is crucial to allow codec negotiation in osmo-msc: if MO has
already assigned a specific codec, and later wants to re-assign to the
codec that MT has chosen, the codec needs to be changed at osmo-mgw.
This patch is the minimal fix required to get re-assignment to a
different codec to work (via osmo-msc). There is more work to be done
about this bit of code in osmo-mgw, but keep that to a separate patch.
In detail, before this patch, we fail both
- when a side has no codecs,
- or when there is no single match between codecs of the two sides of
the endpoint.
Remove only the second condition; after this patch, still fail when a
side has no codecs -- this allows mgcp_test.c to still pass.
Related: OS#6293
Related: osmo-msc I8760feaa8598047369ef8c3ab2673013bac8ac8a
Change-Id: I3d1163fe622bdd7dc42a485f796072524ab39db9
We already did a lookup from conn_src[i] and found a matching
codec_conn_dst, no need to do another reverse lookup to end up at the
same conn_src[i] codec.
Change-Id: Iecc7f22c551fd17b23db434fdb177266407d2621
There is considerable code complexity in place for this ancient hack.
It dates back to 5ea1bc77a3
"
mgcp: Allow to freely control the a=fmtp line for experiments
In case of AMR one can specify the available codecs out-of-band. Allow
to configure this line statically in the configuration file.
"
Looking in mgcp_test.c output, the fmtp-extra tests do not even make
sense: they result in fmtp for pt=126 being added, even though there is
no payload type 126 listed in the SDP...
Related: OS#6313
Change-Id: Icee0cd1f5a751fa760d5a9deca29089e78e7eb93
It seems to be a remnant from early openbsc_mgcp. There is only the
default implementation for this callback and it simply returns two
pointers. Simplify that.
Change-Id: I18dfd44c931540caf4ac360c08ed10e5f65b2165
Removing the duality of codecs[] and ptmap[] in structs mgcp_msg,
mgcp_response and mgcp_conn_peer has removed the need to "map" from
codec type enum to payload type number. They are stored together now.
Remove functions that are no longer used.
None of our osmocom users of libosmo-mgcp-client call these functions.
Change-Id: I84e5285831397c992af59deee12dea8458d16cc6
So far we allow only MGCP_MAX_CODECS-1 entries, because the parsing exit
condition hits only after the array size check. Instead, check the array
size a bit later, just before actually adding a valid entry.
This is verified to work as expected in upcoming patch
I842ce65a9a70f313570857b7df53727cc572b9e6 that adds a new
mgcp_client_test.c section for this.
Change-Id: I9a28da85e437f118026ea71a5a708e5758fff623
codecs[] is an array of enum osmo_mgcp_codecs.
ptmap[] is an array of { enum osmo_mgcp_codecs, unsigned int ptmap }.
MGCP lists first a bunch of payload type numbers and then specifies them
again for details, like the numbers 112, 96, 3 in this example:
m=audio <port> RTP/AVP 112 96 3
a=rtpmap:112 AMR/8000
a=rtpmap:96 VND.3GPP.IUFP/16000
a=rtpmap:3 GSM-FR/8000
So far we keep these lists in two separate arrays:
- codecs[], codecs_len stores the 'm=audio' list
- ptmap[], ptmap_len stores the 'a=rtpmap' list (and may omit some
elements present in codecs[])
This applies to both struct mgcp_response and struct mgcp_msg.
These are semantically identical, and the separation leads to checks,
conversions and dear hopes of correct ordering.
So let's keep only one list with both codec and payload type number in
it. The 'm=audio' list establishes the order of the pt numbers, and the
'a=rtpmap' list adds codec information to the established entries.
In the internal API structs mgcp_msg and mgcp_response, just drop the
codecs[] entirely.
In public API struct mgcp_conn_peer, keep the codecs[] array, mark it
deprecated, and provide a backwards compat conversion: if any caller
invokes mgcp_conn_create() or mgcp_conn_modify() with codecs[] still
present in the verb_info arg, then move codecs[] entries over to the
ptmap[] array in a sensible way.
(BTW, even mgcp_conn_create() and mgcp_conn_modify() are never called
from outside of libosmo-mgcp-client in any of our osmo-cni programs;
users call osmo_mgcpc_ep_ci_add() and osmo_mgcpc_ep_ci_request(), which
in turn may pass user-provided codecs[] lists on to mgcp_conn_create() or
mgcp_conn_modify().)
Tests for parsing the MGCP response are mostly missing. They will be
added in upcoming patch I842ce65a9a70f313570857b7df53727cc572b9e6,
because they will be using only the new ptmap API.
Related: OS#6171
Change-Id: I798e02c6663376d3d52f4a74fc4b32411ce95bed
As was pointed out during code review of a previously merged patch,
whenever we write something to the tailroom, we must use msgb_put().
Change-Id: Ibe1605631a94088bfd1f603f7043322ed5585ffe
We need to be able to terminate the received string in case it was
not nul-terminated by the sender (see mgcp_msg_terminate_nul()).
Change-Id: Icc878af7f671213bb516af62cb601914d86ff808
Fixes: CID#272990
The current statement:
msg->l2h + msgb_l2len(msg)
looks as follows, if we expand the msgb_l2len():
msg->l2h + msgb->tail - msg->l2h
so this is basically equal to msgb->tail alone.
Change-Id: I4f4b0f792bbeef94a5449c4a5843628a703a3d54
Related: CID#272990
There is an upcoming modification of structs mgcp_msg and mgcp_response.
When it is public API, it needs to be kept backwards compatible.
But no libosmo-mgcp-client caller (in the osmocom-cni world) has used
these structs in years and years. Everyone should use the higher level
osmo_mgcpc_* API only.
Move this legacy API to a private header, so we no longer need to worry
about compatibility there.
Related: OS#6171
Related: I798e02c6663376d3d52f4a74fc4b32411ce95bed
Change-Id: I6d8bdda5c2ffa236e94a0b6111de4dbfac923187
end.codec may be NULL, depending on whether a single matching codec
could be found or not, i.e. based on external input. So let's not crash
if an RTP packet arrives while end.codec == NULL.
Change-Id: I9bfb55a343b3f2b1459e0aba4ee71a6133b992b3
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.
Related: SYS#6657
Change-Id: I30165dbac5e484011d0acf46af36f105954a501d
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.
Related: SYS#6657
Change-Id: Idd833997abce46886e9664505b2776fa5dadc8db
We have proper IuUP support and everything about this legacy hack should
be purged.
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
Related: SYS#6657
Change-Id: I158dd046fdfcb10392cde3de8cc88dd095a05b40
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
Related: SYS#6657
Change-Id: I6c365559a7bd197349f0ea99f7a13b56a4bb580b
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: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I46512517bc3b5bb90cac7643e7ac73afba398d36
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.
Related: SYS#6632
Change-Id: Ia5d8a9aff565399a85a5b116d7029fedcab234e0
Before:
CONN: (1226/rtp, id:0xD94316AD, ip:127.0.0.2, rtp:2344 rtcp:2345)
After:
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
and readability:
- 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.
Rationale:
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.
Implementation:
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
Change-Id: Ib89a6779e1d68c6600f00699d4303f6c0ee07132
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
wrong.
Related: SYS#6578
Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2
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
connection.
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.
Change-Id: Ic99a55ab5a3a6170e940403fadd52697e99f2f3a
Related: OS#4853
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
other connections.
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.
Change-Id: I0639c663e119d85bef1010c7aa45e2f133a9daf0
Related: OS#4853
Instead of calling strlen() for every loop iteration, just use strchr()
to find the position of '/'.
Change-Id: Ifc7302b6c5f9288a622e33c3e8b5fe0e7037dbdc
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.
Related: OS#6081
Change-Id: I0342e85b32ed89f3a1fdb6131c3c8ded8f47a455
Abort with error log when map_str_to_codec is -1, instead of writing it
as unsigned integer into ptmap[i].codec.
Related: OS#6074
Change-Id: I08b91c849d810fe3cdb72c0f6f2a558b7377deab
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).
Fixes: 563386e8bb
Related: SYS#6481
Change-Id: I263d23885a1a967f844033f9810b96691b8e3b30
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.
Fixes: 563386e8bb
Related: SYS#6481
Change-Id: I290f7436f48418ee25179951359c76208796e279
This way the user ends up picking a working MGW instance instead of one
which is not reachable around the time.
Related: SYS#6481
Change-Id: Ia3f451d3cd97851f65074408812b1ddc68f67056
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:
----
mgw 0
...
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.
Related: SYS#6481
Change-Id: I3dc74c78548d017f272da863d5282dc5e0020ca3
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
feature.
This "null" Endpoint is osmo-mgw specific, not described in MGCP specs.
Related: SYS#6481
Change-Id: Ia409b16e9211e6261e2e0f21288544289d6f3733
This is a preparation commit for follow-up one, where some of these
functions need to be used in other static functions.
Related: SYS#6481
Change-Id: I3a00d8c47ec773390d9626364c4c75ca579f1508
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
affected.
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.
Change-Id: Iba0853ed099a32cf1dde78c17e1b34343db41cfc
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.
Change-Id: Ie9d949ee72286ee4de7590c99acc740011208466
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
and rate.
This fixes the following TTCN3 testcases:
MGCP_Test.TC_two_crcx_mdcx_and_iuup_rtp
MGCP_Test.TC_two_crcx_mdcx_and_iuup_rtp_rfci_unordered
Related: OS#5461
Change-Id: I6bc1e6022efe21cb893ef213f3da35017960357d
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
mgcp_patch_pt() fails.
Change-Id: I013a24c1e0f853557257368cfab9192d4611aafa
Related: OS#5461
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
RTP packets.
Related: OS#5461
Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
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.
Related: OS#5461
Change-Id: I2f2538ff912eae4d80d3b74b766e18c4da94d6b6
add_sdp(), add_lco():
- 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.
Change-Id: I904d56f56053952c2ebbbe5dca744fafa32b333e
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.
Related: OS#5993
Change-Id: I009483ac9dfd6627e414f14d43b89f40ea4644db
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
in mgcp_network.c
Related: OS#5461
Change-Id: I085260a2ca8cfecdb58656b7a046c536189e238d
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
format.
Change-Id: Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d
Related: OS#5461
This reverts commit e0058b7207. The reason
for this revert is that the solution in the reverted patch does not
cover a situation where the other side announces both payload formats at
the same time.
It could be that the end facing to a transit network announces both
formats under two different payload types. In this case no conversion
would be necessary. Depending on the input format the output would be
send to the transit network under the payload type that matches and no
conversion would happen at all.
This revert re-intruduces the problem that was fixed in the patch
before. Therefore it must be merged together with the follow up patch
(Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d) that contains the proper fix.
Change-Id: I0b2854ef2397f38606fab3425be586a3d0ca27d1
Related: OS#5461
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I4bc03bdc1f2de2574558e2ad753e116486993a7f
While adding CSD, this failed for me in add_lco without a descriptive
log message, so add more error messages.
Related: OS#4393
Change-Id: I4873a2db95525aab3e13046b645dd8f90e951466
At the moment we open an E1 timeslot when needed, but we never
close it even when it is not needed anymore. This may block other
entities from using it. Lets add some logic to detect whether the E1
timeslot is still needed and make sure that it is closed when it is no
longer needed.
Depends: libosmo-abis.git I073cfaba0d5073447842f22665e213135ea3f635
Change-Id: Ie6a32abbc5cd984f6d72a384e3b47c1b82ce7058
Related: OS#5198
It is more logical to move the function mgcp_endp_release to the end
since it is used to release the endpoint when it is no longer needed for
any transmission. (Also the follow up patch requires the function to be
moved)
Change-Id: Id3166a6a817ddb9ce36ff1b375ff8ed3598a00c2
Set 120 as payload type, as specified in 3GPP TS 48.103 table 5.4.2.2.1.
Related: OS#4395
Related: https://www.rfc-editor.org/rfc/rfc4040#section-5
Change-Id: I55f9fe241a405935dbedc3947b0a4f4986acd5cb
the comment that explains the AMR frame format check is a bit difficult
to understand, lets rephrase it.
Change-Id: I07f12c03449e1e8eda8bdd3edad6d1007f5ba48d
This is the only user outside libosmo-abis using this define, which
meaning is not clear at all. Let's simply use the related API to clearly
check the FT.
Related: SYS#6161
Change-Id: I40c7ed2e7f6a99a33b467734e33acf3d5befac0d
Before this patch, the free CID with the smallest number was always
selected to be used. This caused more or less the same subset of CIDs to
be used all the time, while the CIDs with bigger numbers were mostly
unused.
Let's distribute the use so that all CIDs are used roughly the same.
This has the advantage, among others, that the same CID will not be
re-used immediatelly after being freed if a new call is established.
It is useful to leave the CIDs unused for some time since the other end
peer may know of the call being tear down with some delay.
Hence if a new call is established immediately after the CID was
released, the same CID would be allocated and passed at the peer, which
would then detect that the old call (in its view still active) would
already make use of that remote CID.
Change-Id: I9dfbcc5e4b4c61ce217020e533d68fbcfa6b9f56
Related: SYS#6161
This sets lowest realtime priority which still takes precedence over any non-realtime service.
Related: OS#5687
Change-Id: Ib1705a164b04b876f129a17c4e8353b9ddcc538e
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I98a3c0d5cfda2c4b020652efb4f445f8288342b6
For IuUP -> AMR, we log a message like
Convert IuUP -> AMR OA:...
Do the same for the direction AMR -> IuUP.
Related: SYS#5092
Change-Id: I525685a7dedb6d5d1deecbd026844cbe23193fac
The Osmux implementation in libosmo-netif expects to work with RTP AMR
in octet-aligned mode. Therefore, if the peer connection received RTP
AMR in bandwidth-efficient mode, we need to convert it to octet-aligned
before feeding the packets to the osmux layer.
Related: SYS#6161
Change-Id: Ifeec44241079f7a31da12745c92bfdc4fb222f3a
The new prefix now matches other related functions acting on an osmux
connection.
Pass the msgb to it so simplify new msgb copy.
Change-Id: I8c0121485d0c96f70fe8bcbdb150793d428183ff
The previous name is misleading since the function is not really sending
stuff over a socket, but rather handling/dispatching the incoming
message internally (and finally later it may be sent over a socket under
some conditions).
Change-Id: Idaf791997b8438a4aede50f614afa0d55ad41faa
First validate the origin of the message, then later the content
of the message and finally execute whatever triggers are necessary.
This way contents from unknown senders are not even parsed or acted
upon, avoiding useless potential harm.
Change-Id: I011a6d7d705768c32a35cec5cd7169725a21a670
The previous naming was quite confusing, since the function is not
really checking whether a conversion is needed, but rather whether the
codec has the AMR RTP mode defined explicitly and hence forced.
The previous naming didn't harm because the amr_oa_bwe_convert also
supports the conversion path OA<->OA and BE<->BE.
Hence nowadays the amr_oa_bwe_convert() function is called always if the
dst conn has its codec with AMR RTP mode explicitly set, no matter if
the src and dst conn have the same mode.
Related: SYS#6161
Change-Id: I8dce3038ebccf5e1e37e2908070a67d66693a96f
Enhance the existing log message
Convert IuUP -> AMR:...
to
Convert IuUP -> AMR OA:...
(or BE) to show wether emitting Octet-Aligned or Bandwidth-Efficient.
Related: SYS#5092
Change-Id: I3672d01d2879ae8820176a46454f26a4f5f584de
When converting IuUP to AMR/RTP, bridge_iuup_to_rtp_peer() sets the AMR
side's payload type number and then calls mgcp_send(). In mgcp_send(),
do not attempt to patch the payload type number a second time.
In mgcp_send(), skip patching payload type numbers if the source side is
IuUP. This matches exactly the case of converting IuUP to AMR/RTP.
There already is a check for IuUP, but for the wrong side. Drop that one
and explain in a comment why.
Move the comment about transcoding into the failure branch, where it is
relevant and doesn't clutter the new explanation of payload type
patching conditions.
Related: OS#5720
Related: SYS#5092
Change-Id: I7c722cd959f76bd104ae4941d182c77e5c025867
Fix the reversed logic when composing IuUP.FQC:
AMR.Q == 1 means the frame is good.
Without this fix, all frames on IuUP are marked as bad, and no voice is
heard on the IuUP side.
Related: SYS#5092
Change-Id: I29878dd27af9ba0c9e600324c528b22940cdcc30
When translating AMR to IuUP, when AMR data arrives before the IuUP side
has negotiated an IuUP Initialization, do not crash osmo-mgw, but return
failure and drop the AMR packet.
As soon as IuUP Initialization occured and RFCIs are defined, the AMR
starts to pass through to the IuUP side.
Related: SYS#5092
Change-Id: Id9efb7e523d8d9af988e4bf4f5e925839204f934
Recent commit dropped the 'mgw ' prefix in commands under the "mgw" VTY
node because it was redundant.
However, for old apps still not supporting the 'mgw' node, the commands
are still printed in another node and hence the 'mgw ' prefix must still
be appeneded to them, to avoid breaking backward compatibility.
Related: SYS#5987
Fixes: 8c138fe89c
Change-Id: Ifbfb71f8864b425c1b842cdee241ce279d17a8ba
Move the regular writing logic to a subfunction, and raise the flag only
on one of them.
This simplifies the code paths but not marking stuff true and false over
the same code path.
Change-Id: I070798863f2bdc253df004a63262d4bcd529348f
That command was already deprecated when the new commands without the
"mgw" prefix were dropped, so there was no need to create a new command
for it (since it shouldn't be used and it's currently implemented as a
NOOP).
However, the recent patch moved the install line out of the common
function, which meant the command was not available anymore on the old
node, and as a result old config files using it would fail to be parsed.
This commit moves the command back to the common function so that it is
still available for config files using the old node.
Related: SYS#5987
Fixes: 8c138fe89c
Change-Id: I800abcc9869ed097a9d28715269c42552f5aaf29
Previous existing ones are left marked as deprecated, to avoid breakage
with older configs.
Related: SYS#5987
Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
It is not a good idea to use a personal write_config function for the
MGW node, since it's not meant to be a 1st level (top) node.
During write-config the node function will be called at an
implementation specific time (based on the order defined by the app in
the node type enum), so there's no real way to control that the output
of the MGW node will end up under the parent configured in
mgcp_client_pool_vty_init(). As mentioned the order can be tweaked based
on how the node enums are configured, installed, etc. but that's really
a nightmare, so let's better not rely on that.
Therefore, this patch introduces a new API which the users (apps such as
OsmoBSc and OsmoMSC) can use to write the config at the required time
(when writing its own parent node).
A hack is introduced internally to detect older versions of the users
which didn't call this function to still print stuff (up to to the app
if the order is correct).
Related: SYS#5987
Change-Id: I7a620cf47886d8ecab30ce369cf123d98ab842c5
If the user (app) already supports the MGW Pool VTY command set
(mgcp_client_pool_vty_init() was called), then if single MGW mode is in
use it's because the config file was not updated to use the new MGW Pool
node. Let's convert it to the new format to help in transitioning to the
new VTY command set.
Related: SYS#5987
Change-Id: I2f6658cc66f8bcbd4a60ee2b932bb5dd65888233
Deprecate mgcp_client_connect2() and all the related messy system where
configured port is incremented until a free port is found.
Let's simply use local_port=0 by default and let the kernel take care of
doing all that.
The mgcp_client_connect2() is actually not being used anywhere outside
of libosmo-mgcp-client, so it's not a real problem deprecating it. We
could poitentially remove it too.
This helps in fixing a regression in recent refactoring commit
f48cd95bbc, which unified calls to
mgcp_client_connect() and in the process dropped the code path which was
setting the retry_n_ports=99.
As a result, since all libosmo-mgcp-client instances set local_port=2727
and addr=NULL by default, using MGW pooling or having several osmo-bsc
or osmo-msc processes would make creating the socket fail.
Change-Id: I5683bcf3b2c4e8058338433f2cd1b143753f6512
Let's advise all our users to migrate to the new pooled mode, the old
VTY interface should be dropped at some point to avoid making it
overcomplex to configure MGW. There's no need to maintain the same set
of commands under 2 different places.
Change-Id: I95f717a0fcd3c4ca622e3989baa28fac1f7ec1ca
Fix for:
[ 34s] In file included from vty.c:22:
[ 34s] /usr/include/osmocom/mgcp_client/mgcp_client_pool.h:18:1: error: unknown type name 'bool'; did you mean '_Bool'?
[ 34s] bool mgcp_client_pool_member_is_blocked(const struct mgcp_client_pool_member *pool_member);
Related: https://obs.osmocom.org/package/live_build_log/osmocom:master/osmo-bsc-nat/CentOS_8/x86_64
Change-Id: Ic3773f49160cbb8c6f53c4f0e17b897017dec98a
This will be used by osmo-bsc to implement MGW-pinning for specific BTS.
This is useful for instance to keep all BTS connections targeting the
same MGW in order to make use of Osmux trunking optimizations (AMR
payload of different calls filling same underlaying UDP packet).
Related: SYS#5987
Change-Id: I75ce3e04cd3f6d9cc20d7b4fc0f51083780786c8
Let's properly store backpointers so that it is easy to access all
relation chain (pool<->pool_member<->mgcp_client).
Related: SYS#5987
Change-Id: I5ec2465075da2e3c8eabca9df60681620a7db499
Move mgcp_client_pool up in the file as a preparation for next commit,
where pool_member will have a pointer to the pool added.
The related APIs on the object are also moved up in the file.
Change-Id: I9ff9c6e1e722690835c5d59b1fa87fb7d9e3120c
The second parameter of mgcp_client_pool_member_reinit_client() will be
removed in a follow-up patch after further refactoring.
Related: SYS#5987
Change-Id: I0ab59278629c0e7e7c62a68b54b4235df58a5d77
Having a list named pool inside an object already named pool is quite
confusing. Let's rename the field so that it makes sense immediatelly
when looking at it.
Change-Id: I4062af6b619317c48223ad4577eaaad05d4eec9d
* Move all of them to an anonymous "osmux" substruct to have them all
together.
* Rename some fields to clarify its meanings, similar to what
was already done in osmo-bts.
* Move the port VTY config next to the ip address ones.
Change-Id: Icc1c1ce3ab3a8beb941cda7c112485a0db882a90
It's basically the same code path (one function calls the other), but it
makes a lot more sense to have it in the init function itself.
Change-Id: I63d7dfff451870f708f7cb710d66f4ec786c27d7
Parameters passed to several functions are rearrange to make code
simplier to follow, as well as dependencies between the different
functions. As a result, some parameters can be marked as const while
doing the change.
Change-Id: Idebd4a66630c16548f557632a54d6b7e1b3906fd
It's checked in all code paths being called, which makes sense since
it's impossible to send anything if the remote address is not set. Let's
check it once in a unique to simplify the code.
Change-Id: I224dbfeda17c364b85166268e2ac1e019a87edb6
A new osmux bind-ip-v6 VTY command is added, similar to what's already
available for RTP. This way the user can decide whether to support IPv4,
IPv6 or both types of IP versions.
Both IP sockets are by default disabled, and must be explicitly enabled
by setting the bind-ip in the VTY configuration.
Change-Id: I446cd7da217e9f4a74995d7784ae55dcc60a29b7
Since recently the port is guaranteed to be placed at
CRCX/MDCX in the sockaddr, hence we can check it using the API instead
of checking manually only for the address part.
In osmux_send_dummy() we actually fix a bug where an in_addr was being
compared against a struct sockaddr.
Change-Id: I736e7f4c51e577d8eb0b96bc776f984f928b6d27
Let's use the port part of the struct mgcp_rtp_end->addr field instead
of keeping it separate. This makes it easier passing around and
using/checking the RTP remote address + port, and avoids confusion
having to check stuff outside of the address, with its port part
potentially unset.
Change-Id: I294eb5d85fae79bf62d36eb9e818426e187d442c
A commit refactored this code around one year ago, which broke osmux
detection of dummy messages. This commit partially reverts the earlier
commit and rearranges the existing code to make it more robust.
Fixes: b3d14eb552
Change-Id: Iedf085932c45af5d13e04e56a4cd1082de81d869
There's no need to separate between BSS and CN side nowadays, the
different types are used nowehere. This separation dates from
osmo-bsc-nat code days.
Change-Id: I65effeddf033eb1955553e8d659c593b4e67f7bc
Documentation of rtp_bridge_cb was outdated, and caused confusion when
adding initial osmux support. Let's clear all the mess.
Change-Id: I42d1f2e2919eae3b1555ca4929e571855960792e
This way we have no more access to internal osmux structures.
Moreover, we already have similar information in our rate_ctrs, so
there's no need to print those there.
Change-Id: I853e118f843070ea29b19e1b0fe56b52f267437a
Receiving an unknown CID (for which we don't have an active conn) is
totally expected at the end of the call, were some messages from the
peer may be send for a while, specially if latency is high.
If this occurs, we simply drop that batch and keep decoding the osmux
message in order to keep delivering content to other circuits.
Related: SYS#5987
Change-Id: I315949853bdcc07bef15d2e8579029cc72c427cf
This is actually quite common, since our peer may be sending some osmux
packets to us a while after we have closed the conn on our side,
specially if latency is high in the network (eg satellite links).
Related: SYS#5987
Change-Id: Idffd91b68d1f98ac906d78e7fbc0e6eaa1962f9e
Let's not delay allocation of rate counters until the osmux conn is
fully enabled, since we may want to count stuff before that point in
time.
Fixes crash accessing null conn->osmux.ctrg in
MGCP_Test.TC_two_crcx_and_rtp_osmux_bidir.
Change-Id: Ic31d3567f4d24e628f8983d8362e5c7c2f66ec02
During development of the counters, they were first added to the same
RTP counter group and later on split, but some places still used the
RTP related functions to increment the counters.
Let's add a seaprate set of helpers to update the correct osmux counter
group.
Fixes: 582c2bf7b0
Change-Id: Ia2e5601c7d476b79afd95032dbc019517f8209af
So far the implementation only allowed the remote CID being the same as
the one dynamically implemented internally.
Related: SYS#6138
Change-Id: I6b03eabc0305580c9788c529bec7dda9044a008f
This makes all lines operating on rate groups way shorter. The "ctrg"
naming is already used in tons of places in osmocom code.
Change-Id: I745eddbf66e7d811bb73c8ae9bb54ea93073c71b
struct osmux_handle, which is shared by several rtp_conn, is
attached to the trunk object, since the socket also attaches to it.
Related: SYS#5987
Change-Id: If4980424cdb8e3dc26a23e9ee419c0a38912f38f
It makes sense to handle one osmux socket per trunk. Since we only so
far operate one RTP/osmux trunk, let's stick to that only one for
simplicity.
Change-Id: I173266c4058d5db9479d773d7dec1304bc8f1f99
The struct osmux_handle is a shared structure which goes together 1-1
with libosmo-netif's struct osmux_in_handle, which is common to all CIDs
to be muxed together. Hence, it makes no sense to store a specific conn
object to it, since it actually manages several of them. Hence, all the
conn specific stuff must be handled beforehand, not at osmux deliver
time.
Related: SYS#5987
Change-Id: Ie739b556e9eb7d3133e798831a09728c7cc87135
This cleans up all the code, and makes it a lot easier to add IPv6 support
later on (mostly only a matter of adding an IPv6 bind address in VTY).
Similar changes were done to the Osmux code being added to osmo-bts.
Related: SYS#5987
Change-Id: I5a100fc654f88d29b2bcd85889a5a92aef3d576d
The local Osmux IP address (cfg->osmux_addr) was never applied in
generated MGCP messages. Instead, the RTP one was written into the
MGCP message.
Related: SYS#5987
Change-Id: I305f2501221e86d1eb0140446c03f36698f3194a
This way we don't need to worry about implementation details (struct
size) in the future in case they change (they will).
Related: OS#5987
Requires: libosmo-netif.git Change-Id Ie8df581f375c9a183a7af60b431561bda82f6e34
Change-Id: I2d0d8c152b8f1234ddfcd74d6cb04b1818b41510
By default systemd will execute service with root directory (or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I7696cd92953787591e7b4777ee79c2671326b972
Since libosmocore.git Change-Id
I5cb740702805693cc7f0a550e2e093f9bfdd507c, the IuUP stack can send INIT
event more than once, it sends one each time an IuUP Initialization
message is received.
This is done since potentially a peer could send an Initialization
message at any time with a different subflow size configuration. So
ideally we should update all osmo-mgw state regarding codecs, and
forward the Init starting the procedure on the other conn of the
endpoint.
However, this scenario is most probably not going to happen right now
and it would be a lot of work to implement and test,
and subsequent INITs we received will almost surely come from
retransmissions of the initial Initialization message, which means
content will not really change.
Hence, it makes sense to simply drop the receive message (the IuUP stack
already takes care of re-ACKing it) and let the endpoint state continue
with its ongoing procedures.
Related: SYS#4705
Change-Id: Ib97bc6f57d265622e24a776b96f0a82c25d33d39
The initially merged IuUP API and implementation in libosmocore assumed
that RFCI with ID was always in the position of its ID inside the list
of RFCIs. This was the case for messages sent by ip.access nano3g as well
as our own osmocom implementation. However it was noticed that other nodes
from other vendors actually use other order, as allowed by the IuUP message
format.
Hence, we need to break the assumption and provide explicit ID
information in the list.
NOTICE: This commit implies an API change when using libosmogsm.
However, the previous API was never available in any libosmogsm release,
and only available in both libosmogsm and osmo-mgw master, so we are
only breaking compatibility between different master versions, which is
acceptable.
Related: SYS#5969
Depends: libosmocore.git Change-Id Ib21cee2e30bf83dff4e167f79541796007af9845
Change-Id: I40ebf36ad37f5196751caf2297a340e538ad28bc
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I938669a78b4afa808ca4f741aee9919944aeb7f6
Make sure that RTCP packets do not enter the code path where AMR OA and BWE
is converted. The conversion will fail and the RTCP packet will be
dropped.
Change-Id: Ic850344d8b5f7710d12e4553a4033b733dced52b
Related: SYS#5902
AMR that has the payload format bandwith-efficient is the same codec as
AMR that has the payload format octet-aligned. Its the same codec, and a
comparison of the codec info with the function codecs_same() should
return true (=equal).
The affected function codecs_same() is used by mgcp_codec_pt_translate().
When the egress payload type number is looked up, the ingress and egress
codec information is compared. When one end is using AMR in
bandwith-efficient format and the other end is using it in
octet-alingned format. Then the codec still must be recognized as the
same codec. Othersiwse the payload type number translation would not
work, even though the codec is the same on both sides.
Change-Id: I64731570c287a75d39c79c10e1bc09a37bdd54d6
Related: SYS#5834
3GPP TS 25.414 5.1.3.3.1.6 specifies that IuUP can use RTP as transport.
The payload type is specified from 96-127, which shall be ignored on the
receiving end anyway.
The payload type number we use shall be 96 by default.
Change-Id: Ifd1210a897743396899f34457c96e6fd2109c6b3
Related: SYS#5152
Using "payload" there is misleading, the proper naming is payload type,
a well known term for RTP.
Change-Id: Ifcad63b0ba5068acd555960c71c3ad1489a2b870
Discovered while debugging wireshark CRC calculation and implementing
new IuUP code in libosmocore.
Change-Id: Ic8350d1f9a9e5dcefeb787462d267bfac08d778f
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I2a623f67e116d5e56091ae5860ca2a305c57e50a
When configuring osmo-mgw the user may choose an arbitrary trunk number
for the E1 trunk and sets a line number that must match the number of
the physical line that is used with the particular trunk. This is easy
to confuse, so lets add a note to the maual that mekes this clear.
Change-Id: I4b647a60d21cae99663a8258d6636ec8a7609d97
Related OS#5308
Change-Id: Ide27fda6d9ee2627bb544d21aa65161eace35a34
We don't really care about the kernel style after all and the linter
complains about proper formatting, so remove all for-like macros so
we don't accidentally apply kernel style formatting.
Change-Id: Ia1b5848b31470b694a2031ad83e84f3132212f94
Not entirely wait-free: allows waiting on a fd, and in general fd
notifications for poll-loop integration between threads.
Change-Id: I4f17042baf76d086ce6b20eb99402dc64c22c657
This was previously broken and a free endpoint was requirted to dlcx *,
additionaly globally handling this is difficult due to different
response
codes, so just do it in the functions, they know best.
Change-Id: I8cbbe5936067ea1caa7935e8d14908ac5c4010bd
Do not turn some compiler warnings into errors by default. This patch
was added before --enable-werror was available.
We build with --enable-werror during development and in CI. If the code
is built with a different compiler that throws additional warnings, it
should not stop the build.
This reverts commit 34f012639d.
Related: OS#5289
Change-Id: I6042f917a5a891dd13cb96d9477a45a45a7b35fe
There is no obvious reason why we would want to complicate the code by
caching pointers, since pointer traversal is probably not a performance
bottleneck, and if it is we should rather take a look at our dozens of
linked lists first..
Change-Id: I2456ba63598f76200d53e00223abf60bb36a49c0
Usually only one MGCP client per application is present. Then the log
lines from mgcp_client.c will be distinguishable without additional
information. When the application is using a pool of MGWs, then the
various MGCP Client instances become hard to distinguish.
- Add a possibility to set a description (name) for each MGW pool
member. When no description is set, use the domain name.
- Output the pool member name on each log line in mgcp_client.c
and mgcp_client_pool.c
Change-Id: I53ff5445c8e5faffa4ef908ffb1fdb1f47ea2904
Related: SYS#5091
there is no obvious reason why the endpoints that belong to a trunk would
have the (global) config as parent context, you can't really have endpoints
without a trunk anyway.
Change-Id: Id3d5fefc12b7d442c09c507b3a8b0231e46e3068
They are mostly not even as large as the talloc header used to
dynamically allocate them, and they are also not "shared" by anything.
Change-Id: I7b46d531c5d3b53984f2ce44538116973f6a074d
Trunk is safe, since it will not disappear sooner than the endpoints or
connections.
osmux still missing!
Change-Id: I15b01085f31e9a10a1ad381713ca2275356ca20c
No need to complicate audio codes with pointers, our "usual" string is
barely larger than a poointer, five times smaller than a talloc header,
and most importantly not really optional anyway...
Change-Id: Icc41643050a5e1ca3c66f307d60b6911ba1b8032
The test expects wrapping here, but the undefined sanitizer is not happy
with that, so disable it.
Change-Id: I59ec65519ea028d4628ba4b56c939aef70794abf
Clang and gcc have different names for this, but the check fails without
-Werror since clang only warns about unknown args.
The previous check led to a lot of "unknown arg" spam while compiling
with clang.
Change-Id: Iad6c16beed26d5fe8952d7d5a79a93845c391b48
The change I19f67db1c56473f47338b56114f6bbae8981d067 removes the
policy_cb and change_cb callback funtions, but it does not remove
the related ratecounters.
Change-Id: I53aa3c890555055466e86b09a359375a10d3be7b
The docstring in the VTY command that is used to remove MGCP client
instances lacks the NO_STR constant.
Change-Id: I53f3e763a77ed8be78c5a51b1472f4b70bade9d4
Related: SYS#5091
The interactive VTY commands to reconnect, block and unblock MGCP
clients from the pool are not displayed properly because the doctring
lacks the reference number.
Change-Id: I0367c33f5cd02978e3f14b1343dfaafa1ea62370
Related: SYS#5091
When the function mgcp_client_pool_vty_init is called with pool = NULL,
then it segfaults. Lets put an OSMO_ASSERT() on pool to make clear that
a pool must be present before initalizing the VTY on it.
Change-Id: I36893bf5341d4ad21161e92d2d25d284647f7d18
At the moment the MGCP Client only supports one MGW per application.
Depending on the requirements of the application one MGW might not offer
the performance needed. Lets add support for an MGCP Client pool that is
backward compatible to existing applications.
Change-Id: Icaaba0e470e916eefddfee750b83f5f65291a6b0
Related: SYS#5091
The function init_socket has an arbitrary retry count when opening the
socket. After each retry the local port is incremented by one. The
intention behind this is to find a useable local port in case the
configured port is used by another process.
The maximum number of retrys is hardcoded. The upcomming MGW pooling
patch requires to set the maximum retry count.
Change-Id: Ifd65511daa92fbe610f52da1c4c3b6a7c761d890
Related: SYS#5091
When the address is set to ANY, the address string is NULL. The log then
prints "(null)" where the address normaly would be. This looks odd, lets
print "(any)" instead.
Change-Id: I2ea138827ee5b9f40d352bf594364ee930520609
The vty always checks if global_mgcp_client_conf exists. (there is also
an assert This check about global_mgcp_client_ctx).
global_mgcp_client_ctx and global_mgcp_client_conf are populated before
the VTY commands are installed. Unleass the caller uses the API wrong
and calls mgcp_client_vty_init with NULL pointers there cannot be a
problem with unpopulated pointers. Lets remove the checks as they are
not needed.
Change-Id: I892d14c588573f76640453cb9c194594289b59f1
Related: SYS#5091
Depending on the usecase of osmo_mpcg_client it may be helpful to send a
DLCX to certain endpoints. Usually this would be a wildcarded endpoint
that resets the entire trunk to drop lingering RTP flows which may still
present after a restart/crash, but it might be also a group of specific
endpoints. The user may specify an arbitrary amount of endpoints where
the mgcp client will send a DLCX to. It does not matter if the endpoints
are wildcarded or not.
Change-Id: I47e7ff858d5067b46d52329be5f362ff61c0dff8
Related: SYS#5535
The rate counter and stats item groups, which are allocated in
mgcp_ratectr.c are freed using a talloc destructor that is set in the
context of the item we just allocated using the stats / rate counter API
functions. When we do that, we risk overwriting an already existing
talloc destructor. Lets instead implement own free functions and set
those as talloc_destructor from above (trunk and MGCP config)
Change-Id: Ifc5091e9f95cc721e58d1eb2e55b97102c497706
Related: OS#5201
The two callback functions policy_cb and change_cb are essentially dead
code. They also make the code more difficult to read and understand.
Lets remove them.
Change-Id: I19f67db1c56473f47338b56114f6bbae8981d067
We are currently counting events in rate counters, but there is
currently no way to get a sample of the current situation of the trunk
usage. In particular how many endpoints are currently in use.
This is a corrected version of:
Ib7b654168dc3512f55e45cc4755dc1f6f423d023
Change-Id: I6d3a74f6087512130d85002348787bffc672de81
Related: SYS#5201
The MGW domain name is usually checked while resolving the endpoint
after the trunk has been resolved. This was no problem before, but since
we allow wildcarded DLCX requests, which require only a trunk to work,
the check is not done correctly for wildcarded DLCX requests and invalid
domain names may slip through.
Checking the domain name earlier while the trunk is resolved makes sense
and it fixes the problem.
Change-Id: I9944a9103981fb5f4d0d8714ee2847ae020f76df
The logic when an endp pointer is guranteed and when we are able to
process the request without the endp pointer populated is qute complex.
This shows up as a bug to coverity.
Change-Id: I1d4221f2df13c43321d5466534485cf21f0d9010
Fixes: CID#237088
The request handler handle_delete_con currently rejects wildcarded DLCX
requests even though a wildcarded DLCX would be a valuable tool to
remove lingering connections from the trunk in case osmo-bsc has to be
restarted.
Change-Id: I5c2de6b2b61ee64ba9c0618fd20e8fc2fe6a5ed3
Related: SYS#5535
This reverts commit 6bad138c96.
Reason for revert: heap-use-after-free during 'make check'
in mgcp_test.c test_retransmission()
Change-Id: I96792a719c9c7273676ab9ffe0b9e2aae4c23166
Related: OS#5201
The function create_response_with_sdp calls add_params, which is rather short.
The code in there can also be put in create_response_with_sdp. The
decision whether the endpoint name (Z) should be added or not, should be
made by the caller.
Change-Id: I7e29c513f4386832646e96194ed6c2397405ed3b
Related: SYS#5535
There is not always an endp pointer present when mgcp_check_param() is
called but we always have a trunk pointer. Lets add a trunk parameter so
that the function can pick LOGPTRUNK when endp is not available.
Change-Id: I7327c5a105e7f0e20cabf64623ff9f36fd83bbb8
Related: SYS#5535
We are currently counting events in rate counters, but there is
currently no way to get a sample of the current situation of the trunk
usage. In particular how many endpoints are currently in use.
Change-Id: Ib7b654168dc3512f55e45cc4755dc1f6f423d023
Related: SYS#5535
At the moment the MGCP request handling and message parsing is not
clearly separated. The function mgcp_parse_header() in mgcp_msg.c is
also responsible for resolving an endpoint. This leads to unclear layer
separation. We eventually end up in a situation where we can not execute
any request handler without beeing able to resolve an endpoint, however
this is necessary if we want to implement wildcarded DLCX resquests.
In the current situation a wildcarded DLCX is not possible to implement
as we always have to resolve a an to get to the trunk which we need to
iterate. However, we just can't resolve a free endpoint in a situation
where all endpoints on te trunk are in use.
We have to refactor the request handler so that the parsing in mgcp_msg
only extracts us the endpoint name. The resolving is then done in
mgcp_handle_message() in mgcp_protocol.c. Then we are able to decide
what to do if we are unable to resolve an endpoint but still be able to
resolve the trunk.
This patch does not change the behaviour of osmo-mgw yet, but it lays
the foundation for request handler implementations that can still
perform useful actions if no endpoint but a trunk has been resolved. A
wilcarded DLCX is such a case. It does not need an endpoint, just the
trunk.
Change-Id: I9f519d8a0ee8a513fa1e74acf3ee7dbc0991cdde
Related: SYS#5535
the trunk_nr is in struct mgcp_trunk. The trunk number can not be
negative and there is no magic value that makes use of the fact that it
could be negative. Lets use unsigned int to make this less irretating.
Change-Id: I5d0e1d76adb8c92d84331a0aca2496908e41d621
Related: SYS#5535
the various types of MGCP requests are implemented in request handlers
functions. The function pointers to those functions are held in an array
that is used to find the right handler and call it then. The struct used
to model the array is defined somewhat away from the array definition
and there is also a macro in between that does not help to make the code
more understandable. Lets refactor this a bit to have it more distinct.
Change-Id: I2ef167b2ac179d2b0683a27a095f9662fda460bf
Related: SYS#5535
There is verbose debug logging on MGCP messages sent out to the MGW, but
none on received MGCP messages. Add Rx logging.
Related: SYS#5529
Change-Id: Id76230896aa87c1a12bd5ad87a62430c048a2873
To see state transitions and events on LMGCP DEBUG logging, actually set
the log_subsys of the mgcp_client_fsm.
Related: SYS#5529
Change-Id: I6e84d5f7b85752a7a54f17be1d074b01d1467f26
When the mgcp_client_endpoint_fsm terminates, do not directly pull each
conn FSM instance (mgcp_client_fsm) into oblivion as well. Those should
emit a DLCX and wait for the "OK" response before deallocating.
In programs using the mgcp client endpoint FSM (osmo-bsc, osmo-msc),
this gets rid of false LMGCP ERROR logging related to DLCX like this:
Cannot find matching MGCP transaction for trans_id 71998
Related: SYS#5529
Change-Id: I8fbfec5533e9be9cc7ea550df1e6639a0a215973
Upon mgcp_conn_delete(), we unparent the FSM instance. Instead of
setting the talloc ctx to NULL, place the deleting conn under the
struct mgcp_client talloc ctx.
Related: SYS#5529
Change-Id: Ia12749e0d7d520f24a967c2df9a4651267e1019e
osmo-mgw currently does only a very simple detection method for
wildcarded requests, but it makes sense to split this detection
off into a separate function so that it can be used from different code
locations and we still have it at one place only.
Change-Id: I27018c01afb8acabfcf5d435c996cc9806e52d6b
Related: SYS#5535
The function mgcp_rtp_end_config() takes an mgcp_endpoint as
parameter. The header file does not declare the mgcp_endp struct
and it also does not include mgcp_endp.h because that also would
cause problems. Since the endp parameter in mgcp_rtp_end_config()
is only a pointer we can simply forward declare it.
This patch will currently not change anythig, but it will prevent
compiler warnings when we remove the endp pointer from
struct mgcp_parse_data in a follow up patch
Related: SYS#5535
Change-Id: I07a4d6f9d5334b1f4cf4b262482b8a67b1384398
The rate counter group is currently only referenced by an index. In a
system with multiple trunks this makes it difficult to say which rate
counter group belongs to which trunk sinde the index that is used does
not necessarly corespond to a specific trunk.
Since rate counter groups can now get a human readable name assigned, we
should do that.
Also E1 specific rate counters only make sense for E1-trunks, so they
should not be present on the virtual trunk.
Change-Id: I5e7f0e9081a06af48e284afa5c36a095b2847704
The braces as put before this patch would read as {"is known", "is not
yet known"}, which is confusing the actual situation.
Change-Id: Icd1f22a9f4147a2758c2f068ecba46cf7f732604
The loop that resets all endpoints in read_call_agent() starts counting
at endpoint index 1, but it should begin counting at index 0
Change-Id: I82a385e547e54d82eff95213652317ed2fdaadd8
The logic in mgcp_keepalive_timer_cb() only sends dummy packets for
endpoints 1-N, leaving out endpoint 0, this is not correct it should
include all endpoints (0-N).
Change-Id: I99a9b572eac26780bc1286a8dd63c4c5652fda4f
On a deployed osmo-mgw with RTP traffic coming from a thirdparty
RTP source, it was usual to see log messages like following one from
time to time:
"The input timestamp has an alignment error of 159 on SSRC"
Doing a quick traffic analysis showed that the above mentioned RTP
source was generating traffic from time to time containing RTP packets
with the Marker (M) bit.
Those messages were logged because the verification & patching funcions
in osmo-mgw were not Marker-bit aware. Hence, this patch implements
support for Marker bit when handling RTP packets.
The Marker bit is usually used as a start of a talkspurt, and has to be
considered a syncrhonization point, where timestamp and relation to real
time don't need to match with last received RTP packet in the stream.
Related: SYS#5498
Change-Id: I1fb449eda49e82607649122b9b9d983a9e5983fa
use the recently new available API to check both remote address and
port, instead of only the port.
It doesn't make sense to configure a conn as sendrecv if we have no IP
address to send stuff to, similar to what was already being checked with
the port.
Change-Id: I6ce8cf52930d423d3db8c27251be8350a26a4ede
The following sequence of events was seen frequently in a osmo-mgw
instance running on the field with heavy traffic:
"""
endpoint:rtpbridge/1@mgw CRCX: creating new connection ...
mgcp_network.c:236 endpoint:rtpbridge/1@mgw CI:1C8CCFA9 Failed to send dummy RTP packet.
"""
Allegedly, that happens because at CRCX time the remote address may
still not be known, hence we end up trying to send a dummy rtp packet
to, for instance, host 0.0.0.0 port 0, which will of course fail.
Let's avoid sending it if the address is not yet known.
Similary, same issue could be seen during MDCX, since at MDCX we don't
necessarily need to have a valid addr+port (there could be several MDCX
and only last one set it).
Finally, the keepalive timer also needs the check, since it iterates
over all connections, and it could be that some is still not fully
configured.
Related: SYS#5498
Change-Id: I8ceafda691146823b12232b4a804b4ce74acbdc8
Several log messages showing "Failed to send dummy RTP packet." were
seen in a osmo-mgw on the field. Let's re-use the function to check and
provide more information on what's wrong to ease debugging.
Related: SYS#5498
Change-Id: Iee6ac1f4d24c131e3bf40c37e6fdc252e5208ec8
This is a preparation for next commit, where one of the function will
require an static function available before it in the file.
Moving the functions also make sense, in order to have the 3 mgcp send
functions together for more easy understanding.
This commit does small style changes to fix followint linter errors:
"""
src/libosmo-mgcp/mgcp_network.c:1036: ERROR:SPACING: space required after that ',' (ctx:VxV)
src/libosmo-mgcp/mgcp_network.c:1091: WARNING:BRACES: braces {} are not necessary for any arm of this statement
src/libosmo-mgcp/mgcp_network.c:1145: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
src/libosmo-mgcp/mgcp_network.c:1163: ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
src/libosmo-mgcp/mgcp_network.c:1204: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
src/libosmo-mgcp/mgcp_network.c:1226: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
"""
Change-Id: Iff8dab942182a0d909519acddb86be75d9cda7ae
The functions add_lco and add_sdp assert when the codec string can not
be generated. This is the case when an unexpected codec is addressed in
the input parameter mgcp_msg for mgcp_msg_gen(). Even though the API
user is expected only to use the codec identifiers in mgcp_client.h the
check should not be done with an assert. Instead mgcp_msg_gen() should
just return NULL imediately.
Also all generation functions should not use magic numbers as return
codes. Instead constants from errno.h should be used. It is also
problematic that the return codes from msgb_printf are added up.
Depending. It makes more sense to use an OR operator since msgb_printf
only returns 0 or -EINVAL, so the end result will be -EINVAL if one or
more msgb_printf fail and not just a random negative value.
Change-Id: Ibb788343e0bec9c0eaf33e6e4727d4d36c100017
Related: OS#5119
The constant MGCP_DUMMY_LOAD is used ambigously. Sometimes it is used as
initalizer for an array, sometimes it is used as a single byte. Also the
name is not very expressive. Lets refactor this.
Change-Id: I21d96cefeeb647958bfa1e22a0ea030884746fad
Related: OS#4005
Generated with spatch with this and similat snippets:
"""
@@
expression E1, E2;
@@
- &E2->ctr[E1]
+ rate_c
Change-Id: I53b75ea8a88bc1ae4ceb479ed272865054de9665
When mgcp_udp_send() is called, the memory where *buf is pointing to is
never modified. It should be marked as const.
Change-Id: Iac90de5beb19bf52586ac6ffeab9eb5152edf339
So far an mgcp_client user can get the RTP address+port information that
the MGW has returned upon a CRCX. Add this function to return the other
RTP end, i.e. address+port that the MGW was told to send RTP to.
This will be used to fix the MGCP in osmo-bsc, which so far mixes up the
two RTP ends and compares the MSC's RTP address+port with the MGW's one
and hence fails to skip unnecessary MDCX.
Change-Id: Ibb488925827d9dc0ccb1f8d6d84728745d086793
A call agent may send a CRCX to create a connection in LOOPBACK mode but
without specifiying the destination address. In those cases the MGW
should deduct the destination address from the first incoming RTP
packet.
Unfortunately this is currently blocked by an OSMO_ASSERT that checks the
current sa_familiy against the sa_family from the incoming packet. This
makes no sense since the current sa_family is still uninitalized, which
is expected and not an error since the code that follows will initalize
it.
It also makes sense not to access the osmo_sockaddr struct members
individually but rather copy the address as a wohle.
Since the event only happens once and since it is also somewhat special
it makes sense to log the event as well.
Change-Id: I2dbd6f62170a7f62e5287d04a4ee6716b8786c26
Related: OS#5123
Sending a DLCX upon FSM cleanup is not unusual. Move the log about that
DLCX to INFO, and also print the endpoint and conn identifier.
Change-Id: Id723d949f101b66fb75296d01489d9dac350c7c8
If the mgcp_client_fsm gets terminated in ST_DLCX_RESP, it has already
sent a DLCX to the MGW. So do not send a second one.
I noticed the duplicate DLCX for the same endpoint conn identifier while
running TTCN3 tests and watching the network trace of test teardown.
Change-Id: I35e415f67946b73c74408afe265618cfe4f72b0b
With just one E1 line, the 'show mgcp' command outputs
several hundred lines to the vty. Add a 'active' parameter to
only show endpoints that are active.
Change-Id: I23a26b4fdc03d8b2469d293dd6c06ed83ce739e9
This is useful for affecting the 802.1Q PCP value without any separate
external packet filter rules for classification.
Change-Id: I69136c6dd114c24b1dace034e75dba5157bac37e
Depends: libosmocore.git I89abffcd125e6d073338a5c6437b9433220e1823
libosmocore If22988735fe05e51226c6b091a5348dcf1208cdf introduces
an even more convenient mechanism for specifying the DSCP of
an IP socket via OSMO_SOCK_F_DSCP()
Change-Id: If0b11dea08716ed3952a25b546b2a9bd013857bf
We have VTY options that allow to set the DSCP value. However, we
then call a function to set the TOS bits in the kernel. This is
very wrong. The DSCP is only the upper 6 bits of the 8-bit TOS
value, and hence we are mussing that translation.
As libosmocore now has a helper function osmo_sock_set_dscp(),
let's make use of it and don't care about the low-level details.
However, this means we need to finally remove the deprecated
alias for "rtp ip-tos <0-255>".
Closes: OS#5137
Change-Id: I9c18c90273be97aedd2ad212b82f650e35c32851
Depends: libosmocore.git Ia4ba389a5b7e3e9d5f17a742a900d6fd68c08e40
In I64ff22193ab2a95a9a7d66e9957a875d096e23de the soversion was
chhanged, but the spec.in file was not adjusted accordingly.
Change-Id: I45d7321adb2db8e7b9ea41b6bcf0c6cc59984a0e
In change I55605ea083565b6950d0820e3f72c50c9dc19ffa, the default
number of endpoints was increased to 512, however the
configuration examples were not updated.
Change-Id: I449a612065a5208c9f70ae74f594e8d45eb344cf
Related: OS#4711, SYS#5262
The manual does not say much about the endpoint naming, even though
osmo-mgw is oriented at RFC 3435 the endpoint names are specific to
osmo-mgw. In particular the E1/T1 endpoints and their overlapping need
some explaination
Change-Id: I16265eb667221959a69f33701d024bd8d9b22040
The cunfiguration chapter does not say anything about E1 trunk
configurations, lets add a subsection that explains how an E1
trunk is added.
Change-Id: I4059771df0f115242398d1af499c837005a7dabc
The E1 trunk lacks the VTY commands force-realloc and rtp-accept-all.
However, the function that write the E1 trunk config includes those
commands. Also they would be applicable, so lets add those two commands
also for E1 trunks.
Change-Id: Ief2bc7502bb8d1e0f9c784d42edbe1aed5ffb728
When a trunk 0 is created (which is legal) than it is impossible to
write this trunk back to the config. The reason for this that there is
still a filtering in place from the time where trunk 0 was not allowed.
This filter needs to be extended to filter only virtual trunk 0 but not
E1 trunk 0 out.
Change-Id: Iad6b577b5a711c35f98c477351fde567d8c87298
The trunk 0 was reserved for rtpbridge in earlier versions of osmo-mgw,
this was due to internal technical limitations which no longer exist.
Change-Id: Ic322f7dcf28db827187a4537e2634a887bd7b13b
Add a graph similar to "OsmoMGW used with OsmoMSC" that shows the
integration of a legacy E1 BTS into a AoIP network
Change-Id: I71dc2f4a188fbc25e81050be3dd4c83e1797e63d
The graph "OsmoMGW used with OsmoMSC" shows a BSC entity that accepts
AoIP and RTP, however osmo-bsc has no RTP proxy functionality. It makes
probably more sense to remove the BTS from the graph and call "BSC" "2G
BSS"
Change-Id: I6c7d26b6e45d0f953b82bca3ae7b2f26600982b2
The graph "OsmoMGW used with OsmoBSC" shows an RTP and 3GPP AoIP going
to OsmoMSC, this is technically wrong since osmoMSC has no RTP proxy
functionality whatsoever. Since the graph is not so much about OsmoMSC
it makes more sense to label OsmoMSC with "core-network", then it makes
sense and correctly highlights the role of osmo-mgw on the BSS side.
Change-Id: If3550a101e1e3cc2a25e21dcfe5474134015a6a7
The limitations section is outdated. We now have support for osmux and
E1 timeslots with trau frames. However, we did not mention that we still
have no transcoding as well.
Change-Id: Ia0fe8be96bbf880cfcd9d18256f4ac23a6efae79
To make clear which configuration changes (configure terminal)
apply when, add appropriate user attributes to VTY commands.
Change-Id: I2d9487801b3b78f94577264b56d217c926ef76a9
Related: SYS#4937, OS#1601
The initialization of the E1 line in mgcp_e1.c is controlled internally,
there is no need to expose the function mgcp_e1_init(), lets make it
static and remove the prefix mgcp_
Change-Id: I6aba1c55c9b1d729709ee1fba2994c77bd848a9b
The VTY command "bind early" is deprecated but it prints an error
message and the DEFUN is not set to DEFUN_DEPRECATED.
Change-Id: I594a87d2f63826a9d7b4f6a380586b08b3b79518
There exist trunk_loop commands, which sets an trunk->audio_loop
variable, however all it does is to turn on a log message. There is no
actual implementation present. Lets set the VTY commands to
DEFUN_DEPRECATED and remove the variable.
Change-Id: I72b0f8b908e32643e6e3db6ac024371b13c074a1
The error message: "abrupt FSM termination with connections still
present, sending unconditional DLCX..." implies a more serious problem
than in actually is. Even when connections are present on the
mgcp_client_fsm while it terminates, normal operation is still possible.
Lets change the loglevel to NOTICE and remove the "aprupt" from the
phrase.
Change-Id: I9749c024e208835bd4188bace13f723008de54c8
Related: SYS#5082
libosmo-mgcp-client looks up this timer in a caller provided osmo_tdef
definition. So far, all of our libosmo-mgcp-client callers do not configure
such a timer, so that we always use the default timer value.
We have introduced X timers (negative numbers) to indicate Osmocom specific
timers, and reserve T timers for 3GPP specified ones. So now is still a good
chance to move this timer to the Osmocom X realm.
Remove a comment about this timer at an unrelated place. It is still described
at osmo_mgcpc_ep_alloc().
Change-Id: If097f52701fd81f29bcca1d252f4fb4fca8a04f7
It is currently done upon receival of RTP packets in rx_rtp for pure RTP
conns, but nothing similar is done for Osmux conns, which eventually
trigger a connection time out.
Change-Id: Id592d7db7b9399a497176e0d28cc826b3bce48c0
Otherwise some state is kept, like the previous CallId, which may then
provoke issues next time the endpoint is to be used.
Change-Id: I3ac4f4542c1c8c877127c64acce6c82b458f697f
MDCX may provide a new remote address, which means we may need to update
our announced IP addr and re-bind our local end. This can happen for
instance if MGW initially provided an IPv4 during CRCX ACK, and now MDCX
tells us the remote has an IPv6 address.
Change-Id: Iaed424e2c209e1753e1f579752fc684aaad7a512
It doesn't make sense to call the function several times since anyway we
are only binding during
allocate_port()->mgcp_bind_net_rtp_port()->bind_rtp()->mgcp_create_bind()->osmo_sock_init2().
Let's better calculate the local IP addr once and use that stored value.
THis is a previous step towards next commit updating the local IP addr
and re-bindng if encessary.
Change-Id: I803b99c5e5fe0f92a5bf6796d8c25df88d1608e6
This commit allows for fully IPv6 systems to work fine. However, if a
remote endpoint still wants to use IPv4, it will fail since at this
point osmo-mgw still doesn't re-bind the local end of the connection to
an IPv4 after having initially bound it to an IPv6 one. This kind of
scenarios get fixed in next commits.
TODO: really bind the socket if a different IP address is requested.
Change-Id: I8ed94bd3f674f498e6ba315f44a351fff9c1be15
This commit contains the bulky work of moving all address parsing to
support IPv6 together with IPv4.
Some specific patches required for full IPv6+IPv4 support requiring
behavioral changes come after this one.
Full Osmux IPv6 support is left out of the scope of this patch.
Depends: libosmocore.git Ie07a38b05b7888885dba4ae795e9f3d9a561543d (> 1.4.0)
Depends: libosmocore.git I59bf4b4b3ed14766a5a5285923d1ffa9fc8b2294 (> 1.4.0)
Change-Id: I504ca776d88fd852bbaef07060c125980db3fdd7
This is needed in case MGW changes the local IP address (for instance
because it initlaly offered an IPv4 address, and a client submitted a
remote IPv6 address, so MGW needs then to offer a local IPv6 address for
the RTP connection to be possible).
Change-Id: Ie964412b81fe6e10914790baaea724ca5f772adc
The API and related implementation fields are not used internally nor
externally, and only support IPv4. Let's simply deprecate the API and
drop all the uneeded implementation.
Change-Id: I905d4c4efabb6b4a4bc5c02e956808777243cadc
If "0.0.0.0", the default, is passed together with an IPv6 configured
address (ex: "mgw remote-ip ::1") in VTY, socket creation will fail due
to address version mismatch (because getaddrinfo() returns only an IPv4
address in the local result set).
If instead NULL is passed, then 2 entries are returned, one in IPv4 and
one in IPv6, and osmo_sock_init2 is smart enough to take one or another
when passed AF_UNSPEC.
Change-Id: I1be6f3b71486ce1782ba6b8c62f25145b42ec894
Existing mgcp_client_test code required the '.' to trigger the same code
path, since with this commit we do extra checks and without a dot the
address is not accepted as IPv4 by osmo_ip_str_type().
Change-Id: I936bf57d37f5f0607dfe7fc66c37e424c3793f9b
The VTY default for the number of endpoints is 32. This is sufficient
for small setups and lab testing, but for medium sized setupts the limit
might be reached soon. Lets increase the default to 512 virtual endpoints.
Change-Id: I55605ea083565b6950d0820e3f72c50c9dc19ffa
Related: OS#4711
The struct member trunk->e1.line is never set. Also it is always
possible to use e1inp_line_find() to get a pointer to the e1.line.
Lets remove it.
Change-Id: Id4ff52285917ce3885b8dad3a16270999c9da0aa
The E1 timeslot initalization may fail silently in the last steps. There
is an error code returned, but no log lines are printed. This can make
debugging difficult.
Change-Id: I9aab17fc1ba6666c81b14035a8f1f17e5a55adaf
In this example, we are using the first span (0) of the first DAHDI card
and use it as 'trunk 1' in the MGW.
Change-Id: I0a97da5163a94379b327403b1258696855836bad
Since osmo-mgw supports trau frames it requries a newer version.
The spec file already requires those newer version.
Change-Id: If6c7ecdde09c6e09ded7e0959b7765a01a31d702
It contained name from a different program, probably due to main.c being
copied over during project start.
Change-Id: I4bfa40eec0277705f5d3335d779bff35518470a8
Due to the internal handling of the trunks it was not possible to allow
an E1 trunk that has the ID 0. However this limitation is no longer
present, so we now can allow an E1 trunk with ID 0.
Change-Id: I302c2007628f607033686e277c407232351e66ad
Related: OS#2659
When endpoints become unavailable when MDCX/CRCX/DLCX are executed on
them a major problem may be the cause, lets make sure that those events
are logged.
Change-Id: I059b7e29f960e75a53bfb5dfb2b83ab3d79e84f3
The function e1inp_line_update() is called without assigning its return
code to the rc variable.
Change-Id: Ia72ea2dca210b038766151d547f66b7b7139a2c4
Fixes: CID#212160
Confusingly, in Debian the package is called libosmo-abis, but in
the CentOS/RPM it's called libosmoabis. Fixes a bug introduced
in I45717bda3ef7eba1ef59b993cc8a69bf2f92a29f
Change-Id: I97dfec72a99295148e84e60c1e5037381f736c03
In I6b93809b5ac7d01af55888347dd787b0bc997ae1 we introduced E1 support
to osmo-mgw, but failed to add it to the build dependencies of the
Debian packages, making network:osmocmo:nightly builds fail.
Change-Id: I45717bda3ef7eba1ef59b993cc8a69bf2f92a29f
The file mgcp_internal.h still contains mostly definitions and types
that are relevant for mgcp_network.c and mgcp_protocol.c. Lets give
the network and protocol module its own header files, also move stuff
that does not relate to protocol and network to the appropiate places.
Change-Id: I837eaad771ed7252304db4a81c37953b70766fff
Currently only the endpoint handling for E1 exists, but there is no
actual code behind it that handles the E1 traffic.
Change-Id: I6b93809b5ac7d01af55888347dd787b0bc997ae1
Related: OS#2659
The function allocate_port() has pointer a variable end, it even does an
OSMO_ASSERT on it, but it never uses it. Lets remove it.
Change-Id: I369361389c6276e5511c683ebd630093713bdd37
This problem was noticed while running several LCLS test cases from
ttcn3-bsc-test. Every test case makes osmo-bsc leak at least two
chunks named 'struct mgcp_response_pending'.
Here is the related osmo-bsc output with additional debug messages:
DRLL ERROR mgcp_client_fsm.c:525 MGCP_CONN(to-MSC)[0x612000016120]{ST_READY}:
MGW/DLCX: abrupt FSM termination with connections still present,
sending unconditional DLCX...
DLMGCP DEBUG mgcp_client.c:1010 mgcp_client_next_trans_id(id=35): new trans ID
DLMGCP DEBUG mgcp_client.c:918 mgcp_client_pending_add(id=35): allocated and queued
DLMGCP DEBUG mgcp_client.c:962 Queued 53 bytes for MGCP GW
DLMGCP DEBUG mgcp_client.c:725 Tx MGCP: r=127.0.0.1:2427<->l=127.0.0.1:2727:
len=53 'DLCX 35 rtpbridge/1@mgw MGCP 1.0\r\nC: 5\r\nI:'...
DLMGCP ERROR mgcp_client.c:704 Failed to read: r=127.0.0.1:2427<->l=127.0.0.1:2727:
111='Connection refused'
The MGCP client FSM enqueues a DLCX from its fsm_cleanup_cb(), and
terminates. Thus if the remote MGCP peer becomes unavailable (e.g.
due to a network failure), we would never get a response, and since
the FSM is already terminated, nobody would pop and free() the
response handler from the queue (mgcp->responses_pending).
As a simple workaround, let's avoid allocating dummy entries of
'struct mgcp_response_pending' without a response handler. The
only case where an MGCP message is sent without a handler is
exactly during the FSM termination.
Change-Id: I83938ff47fa8570b8d9dc810a184864a0c0b58aa
Related: OS#4619
Instead of numerous arguments (buf, len and context data), use a msgb, like
most other osmo programs do, with a msb->cb pointing at a context data struct.
This opens the future for adding/stripping IuUP header data from the msgb
easily.
(Checked to pass current ttcn3-mgw-tests.)
Change-Id: I3af40b63bc49f8636d4e7ea2f8f83bb67f6619ee
_talloc_zero_array is not supposed to be called by the API user. Lets
use talloc_zero_array instead.
Related: OS#2659
Change-Id: I27549585016a7998e9233c52f6d86429fc75f509
Some of the unit-tests initalize a second trunk (trunk2) but the test
never do anything with this trunk. Lets remove it.
Change-Id: I228aa45160152091baac9d9c2e6486b774278b6a
Related: OS#2659
At the moment the number of possible E1 endpoints (depends on the number
of E1 timeslots that should be used) is hardcoded and the configuration
of the number of virtual endpoints has an off-by-one problem.
For the E1 timeslots one might choose not to occupy all E1 timeslots of
once. A one TRX E1 BTS usually requires 3 E1 timeslots. One as D-Channel
timeslot and two to cover the voice channels. The voice channels
timeslots need to be set up in osmo-mgw, while the D-Channel timeslot
must not be touched. The VTY config needs to be able to reflect that.
Change-Id: I73b31e3c236a61ea0a6f76ef5ff98ce589f52c77
Related: OS#2547
The test assumes that the endpoint "rtpbridge/X@mgw" is at array
position X in many places. This does not necessarly have to match.
Accessing the array elements directly was the prefered way when the MGW
did use integer numbers and not strings to identify endpoints. Since the
endpoint name strings are used to access the endpoints the unit-test
should also reflect this.
Lets replace the integer variable last_endpoint with a string variable
and do related verifications based on strings.
Change-Id: Ic950c427f23be4a792af94972554637c2b0fbdf2
Related: OS#2659
At the moment, the trunk prefix is checked twice. Lets re-arange the
code a bit so that the check only happens once.
Change-Id: I91fb8cf6e3b077ba8f18fdbcd071275c6fd7cacd
Related: OS#2547
There are 15 possible subslots (not all at the same time) in one E1
timeslot. Lets use a define constant for that.
Change-Id: If7cb74e486946aff09e22abf8a8885bf0693f34e
Related: OS#2547
mgcp_client.h offers functions to generate endpoint names for wildcarded
request. This is used in osmo-bsc, lets now also add a function that can
generate e1-endpoint names.
Change-Id: Iec35b5bae8a7b07ddb3559f7114a24dcd10e8f14
Related: OS#2547
Move 'doc' subdir further down to "make sure" the osmo-mgw binary is built
before the docs.
Remove mgw_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-mgw --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: I526af21134087e2b43b9ada59c93f636ae242e24
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: Ia988ea1c3f5169bdb4d21f2f05933665711cfcbf
The function mgcp_trunk_by_num() is used to directly pick a specific
trunk that is known by its id number (sometimes called "index").
Traditionally the virtual trunk will reside under id number 0 and all
consecutively created E1 trunks will be created under number 1 to 64.
This works fine, but puts a limitation on us should we ever introduce an
aditional trunk type (e.g. T1). Since the numbers must be unique
regardless of the trunk type one could not have an E1 trunk number 1 and
e.g. a T1 trunk number 1 at the same time. So we should pick the trunk
not only by its number, but also by its type to allow different trunk
types to carry the same number. The trunks will still be distinguishable
by its type along with the respective endpoint prefix.
Change-Id: I7af1e9ce601babd4a51e88201a98319e03945f83
Related: OS#2659
RFC3435 requires an MGW domain name appeneded to every endpoints. When
defining endpoint names in Appendix E, the domain name is is not
mentioned for digital trunks, however, this does not mean that digital
trunks do not have a domain appended. Osmo-mgw currently violates the
spec because it explicitly checks if the domain name is _NOT_ present
for E1 endpoints.
Change-Id: Ibb800b689e090b97b58d0206959b660890acd967
Related: OS#2547
e1_trunk_nr_from_epname() returns a signed integer:
int e1_trunk_nr_from_epname(const char *epname);
mgcp_trunk_by_num() accepts a signed integer:
struct mgcp_trunk *mgcp_trunk_by_num(const struct mgcp_config *cfg, int index);
Change-Id: Id333a6ddcefd37d82d19f9378ab87d1c02ffd7e3
Closes: CID#211333
E1 endpoint names also represent different rates, this may mean that
some rate / subslot combinations are not possible because they overlap
within nthe timeslot. When the equipment (BSC) is properly configured,
this will be no problem, however invalid configuration may cause the
selection of overlapping endpoints and this needs to be prevented, and
logged. Also rate counters need to be in place.
Change-Id: I18e90b10648a7e504371179ad144645fc82e1c27
Related: OS#2547
The struct mgcp_conn is currently defined in mgcp_internal.h, however it
makes more sense to put the struct in mgcp_conn.h
Change-Id: Ibe9a356300ddb9567432fe48e37c956b7125c79c
Related: OS#2659
Add an endpoint typeset for E1 support, also lets add dummy callbacks
for the cleanup and rtp dispatch functionality.
Related: OS#2547
Change-Id: I68b719a906e8f7251f0ca8c74ceec73bc40376f7
The E1 trunk number is currently not parsed, whenever a trunk prefix is
detected that indicates an E1 trunk, then the entire request is
rejected.
Parse the trunk number and select the trunk accordingly
Related: OS#2547
Change-Id: Ifdaab953544151e73b58cc3e95d21afdb40765f4
The trunk_type variable in struct mgcp_trunk is specified as an int,
however there is an enum mgcp_trunk_type specified. Lets use the enum as
type for trunk_type instead of int.
Related: OS#2659
Change-Id: I8e8b0cf448cfe67ad3b7caab24f301708d2a515f
The enum mgcp_trunk_type, which is currently located in mgcp_internal.h
makes more sense in mgcp_trunk.h, so lets move it.
Related: OS#2659
Change-Id: I077121503c44fc112a33f1c946f368414e28f841
The define constants CONN_ID_BTS and CONN_ID_NET were used in mgcp_osmux
long time ago when osmux support was temporarly broken. Now those
defines are no longer used anywhere, so lets remove them.
Change-Id: I3d0b9d482ef0e2187bccace5779a7f8b9507c4e2
This function calls mgcp_client_pending_add(), that in its turn
allocates a 'mgcp_response_pending' and appends it to the queue.
In case of an error, it calls mgcp_client_handle_response() that
would free the 'mgcp_response_pending', but this structure would
still remain in the linked list (the queue).
Change-Id: Id94bb93a6b0ea7b7241cf7868112e9bec3e60f0b
Currently the endpoint name that is generated for an E1 endpoint is not
correct. Let's add an endpoint name generator function that derives a
full endpoint name for a given E1 index
Change-Id: I70e0c3f96aa3947165f9926666815ee5614c8f57
Related: OS#2547
When the trunk allocates its endpoints by using mgcp_endp_alloc()
ist passes the name for each endpoint as a parameter. In order to
generate the name endpoint specific knowlege is required.
This process can be simplified, since all what
mgcp_trunk_alloc_endpts() does is calling mgcp_endp_alloc() in a loop in
order to generate a consecuitve series of endpoints. The endpoint names
are generated from the index of the for loop.
When we just pass the index instead of the endpoint name to
mgcp_endp_alloc(), then we can greatly simplify the code since all the
knowledge about the name generation can go into mgcp_endp.c. The
endpoint will name itsself by the trunk properties and the index number
we pass with the allocator function.
Change-Id: I8dee07f1c63037d1f73113f69c612d1f2703cee5
Related: OS#2659
The virtual trunk is a pre-configured trunk that always exists. It is
kept separate from the trunk list using a separate pointer. This makes
thinks unecessarly complicated. Lets organize the trunk in the trunk
list like any other trunk, except that we automatically create it on
startup and assign it always the trunk id number 0.
Change-Id: I81934fbd211b225ab7920e78510729c8e22607b3
Related: OS#2659
The rate counter definition (enums) are still in mgcp.h.
Lets move them to mgcp_ratectr.h since it makes more sense
to keep them there.
Change-Id: Id37f66673bc20f9c2cc47a6b44cdfe75f728b936
Related: OS#2659
get rid of deprecated trunk parameters which seem to be leftovers
from the old osmo-bsc_mgcp implementation. This is in particular
audio_name and audio_payload in struct mgcp_trunk_config which
allowed the user to "hardcode" an andio name and payload type
via VTY configuration
The removal of the struct members above also require a change to
mgcp_codec.c. The code that is is never actively used and even
causes wrong behavior when activated (set the no-transcoding
flag in VTY). Since the code is removed also the unit tests
also require to be changed to match the new behavior.
Change-Id: Ia050ec3cd34b410dfe089c41b977ae3d5aed7354
Related: OS#2659
The trunk and endpoint handling in osmo-mgw is still very complex and
implemented in various places (mostly mgcp_protocol.c). Also we use
still integers for endpoint identification, which is not flexible enough
to address timeslots/subslots on an E1 trunk. Some refactoring is needed.
- get rid of integers as endpoint identifiers, use strings instead and
find the endpoint based on its string name on the trunk.
- identify the trunk based on the trunk prefix given in the endpoint
name.
- refactor trunk and endpoint allocation. Aggregate functionality in
in mgcp_endp.c and mgcp_trunk.c. Also remove non-reusable code that
relates to the still exisiting, but unfinished E1 trunk support.
- refactor rate counters, put them into a separate module and do no
longer allocate them per trunk. Allocate them globally instead.
Change-Id: Ia8cf4d6caf05a4e13f1f507dc68cbabb7e6239aa
Related: OS#2659
The config under the node mgcp is written with an indentation that has
one space too much.
Change-Id: I2aefeaf3d7ad4a98b7bfcdc7cbc1ce6ebcbe0537
Related: OS#2659
rename struct mgcp_trunk_config to struct mgcp_trunk and the related
symbol name "tcfg" to "trunk" in order to better match the reality.
Change-Id: I02889dbf8149e139b1bd0326e13ce4c1aec867d1
Related: OS#2659
When a trunk is selected that does not exist, a new one is created. In
this case the VTY would print an error message but the function exits
early. The code that would print the error is unreachable.
Change-Id: Ie8c3b083174eb8209df2c06f65db6d7bbfaa87f7
fixes: CID#210637
There were two code paths that were supposed to do exactly the same,
but then in Change-Id I3994af016fb96427263edbba05f560743f85fdd4 only
one of the two was modified, resulting in OS#4034
Let's
* dynamically allocate the virtual trunk
* rename mgcp_config.trunk to mgcp_config.virt_trunk to clarify
* as a result, abolish copy+pasted code for trunk initialization
Change-Id: I54762af6d417b849a24b6e71b6c5c996a5cb3fa6
Related: OS#4034
The logging defines LOGPCONN and LOGPENDP are currently located in
mgcp_internal.h. However, there are specific header files for conn
(mgcp_conn.h) and endpoint (mgcp_endp.h) related stuff. Lets put LOGPCON
into mgcp_conn.h and LOGPENDP in mgcp_endp.h
Change-Id: I25ff37ee8108c27d169d294fd16ddcdde9b00195
I wanted to use gerrit to merge v1 of
I8d58281e1ff898638293c9e8cb000329462c7a70, but gerrit merged v2
nevertheless :(
Change-Id: I7b16912e66e91f0c30716e4ea1181b39906bacc1
struct mgcp_config contains a function pointer realloc_cb, which is
never popoulated nor used anywhere in the code. Lets remove it
Change-Id: I8d58281e1ff898638293c9e8cb000329462c7a70
Remove OpenSUSE bug report link, set version to @VERSION@, make it build
with CentOS 8 etc.
Related: OS#4550
Change-Id: I1d03ac87a7d0c3c600d187f3e485cb2dab8838bb
Not having a second leg of an MGCP endpoint is a normal situtation
and can't be treated as an ERROR message, especially not as an ERROR
message logged on every RTP packet. This happens routinely at
the beginning of call setup and we get tens of ERROR messages in
the logs for every call.
Change-Id: If741a742208772bda4e59236345d7ae650368d5a
New define is available since libosmocore 1.1.0, and we already require
1.1.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: I9b6463af713f76c06a144bdbf202c0d91eef4d21
Right now a lot of errors with MGCP processing are invisible in rate
counters which makes them difficult to trace or even notice in
a production environment. E.g. reaching a limit of MGCP endpoints
is completely invisible even though it's a critical opertion alarm.
Change-Id: I6db68f044255c927dfd534fed880e405ec3ed4d6
Before this patch rate counters started right after trunk information
with no visual separation which was quite confusing. We're adding
a new line and a header to warn a user of the section change.
Change-Id: I3943def03ab821b05ac597f40bdfa4a3a71ddca3
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I2314ef45e6f588e88d5aab8213cc7b5cdef11325
The example config bind the MGW to a random ip-address, lets use the
loopback address here, this will suit cases where osmo-bts runs on the
same machine as the MGW (nitb). For all other cases were an external BTS
is used the ip-address still needs to be changed.
Change-Id: Iae52c671c48953ea6b52b18c5d77347343cde0df
Enlarge the MGCP client workqueue maximum limit by factor 100.
During Abis load testing, a BSC trying to DLCX 200 conns at the same time hit
the limit of 10 very very quickly, and everything broke down.
Change-Id: I8980cce37bae0757828b28455b25c77bcb6316d0
We used to update only the per-connection rx/tx packet/byte counters
on-the-fly, but not the per-trunk global counters. The latter would
only be updated at the end of a connection. As MGCP connections
can last quite long (think of a long phone call) this is maybe
not the best of ideas.
Note: The all_rtp:err_tstmp_in and all_rt:err_tstmp_out are still
only updated at the end of a connection.
Change-Id: Ib3866cb8149d3257fcf39733846c97c33881c4ee
Related: OS#4437
OsmoMGW has a lot of nice built-in statistics (rate_ctr,...) but it
seems the only way to look at them is via the VTY. While libosmocore
contains automatic exposure of all rate counters via CTRL, the CTRL
interface simply is not used by osmo-mgw so far.
Closes: OS#4441
Change-Id: I7ed6bdb9f4749c24ca11a5905a620546cfe42952
If a config file doesn't have a 'number endpoints' config line,
we would use -1 as unsigned integer and end up with
number endpoints 4294967295
if the config file is re-written
Change-Id: I05a3814117b1d6e0cdc30740da31709ce333df4b
Closes: OS#4034
libosmocore required version increased due to include used from
libosmo-netif including an include from libosmocore which in previous
versions misses including an include from a symbol used.
Change-Id: I1d5f14b1ad36b2ed94343fca71fdc622424403d3
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I48f4c2c520e8285aff5d6d65f95bd041c13466e8
This way we can avoid the runtime overhead of checking whether or not
it is initialized over and over again. It also brings this code more
in line with other users of osmo_fsm_register().
Change-Id: Ia73ba8e46c13d925e88203e08a8966839e573183
API doc: require osmo_fsm_set_dealloc_ctx().
mgcp_client during delete: do not reparent the FSM when it is already
terminating.
I have recently discovered a vulnerability: if an endpoint FSM deallocates
during event handling of a successful MGCP response, this causes a
use-after-free; and once that is fixed, a state change on the already
terminated FSM causes a pointer corruption by using already cleaned data
structures. osmo_fsm_set_dealloc_ctx() fixes the use-after-free, and
osmo_fsm_set_term_stops_actions() fixes the pointer corruption.
Related: Ib7fce7b7d54dfb87af97544796680919e5929a50 (osmo-bsc),
I08c03946605aa12e0a5ce8b3c773704ef5327a7a (osmo-msc)
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Change-Id: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3
SDP is an optional part of MGCP messages. Do not fail when there is no SDP part.
Practically this is useful to compose simpler MGCP responses from TTCN3 tests.
osmo-mgw itself always includes SDP, so there is no real impact on operating
libosmo-mgcp-client with osmo-mgw from osmo-bsc or osmo-msc.
Change-Id: I608001626459ea72415fb142f857550bbb90c683
If an API user only has access to the ci FSM (which is managed via an opaque
struct), provide this function to obtain the backpointer to the parent endpoint
FSM, mostly to be able to call osmo_mgcpc_ep_cancel_notify() on it.
osmo-msc's rtp_stream FSM will use this in
I351bb8e8fbc46eb629bcd599f6453e2c84c15015.
Change-Id: I14f7a46031327fb2b2047b998eae6ad0bb7324ad
There is a use-after-free problem if a 'notify' FSM as passed to
osmo_mgcpc_ep_ci_request() deallocates before the notify event has been
dispatched. To avoid that, add API to allow cancelling a notify.
Change-Id: I41687d7f3a808587ab7f7520f46dcc3c29cff92d
In case the ep gets deallocated during event dispatch, move all ci[] cleanup to
*before* dispatching a DLCX OK event. Afterwards, it might become a
use-after-free.
Change-Id: Ib2032e5566e465c02a9a525ccd38f9dcc84fb669
Upcoming patches introduce copying notify information. Prepare by combining
notify info into a separate sub-struct.
Change-Id: I47c0dd112011b8cb4dc88e8efd010466d4ba6308
If an MGCP operation on one conn of an endpoint fails, no longer carry out
other pending requests for that endpoint. Only allow pending DLCX to be sent.
If the caller schedules two CRCX at the same time, the first CRCX is sent with
a wildcarded endpoint name like "rtpbridge/*@mgw". Only when the OK for that
returns an allocated endpoint, will the second CRCX be sent, using that actual
allocated endpoint name. But, if the first CRCX fails, then we should not send
another wildcard CRCX, but rather assume both as failed.
Since a failed MGCP message means that the endpoint becomes unusable /
undefined and typically deallocates directly, we can actually discard all other
pending requests except for DLCX.
Change-Id: Icb1d485224bb486b84eff6329f0bd95932e63246
During FSM instance cleanup, a DLCX message composition may fail if a preceding
received MGCP message was missing parameters. If that occurs, don't crash, just
log an error and deallocate.
Change-Id: Ic1c3c4deeb4703b60e870af9d5d7be216a87fff8
Currently in handle_create_con(), mgcp_conn_alloc() is called with NULl
ctx. As soon as this ctx is changed to be part of the trunk's endpoint
array (tcfg->endpoints), test will segfault because some fds from
previous tcfg are still registered after the whole tcfg object was freed
with talloc_free() by previous test. That's because
mgcp_endpoint_release() must be called on all endpoints to make sure all
registered components are correctly unplugged.
Related: OS#3950
Change-Id: I813d52b518ed0bb8db4e42dff83e040b0891fee2
If a ptmap appears in the SDP, always store it in the ptmap array. No longer
attempt to drop entries if they match the conventional payload type number.
- One reason is that the past code only matched full explicit "FOO/8000/1"
strings, while the channel number "/1" can be omitted to imply 1; by simply
storing everything received in the SDP, there is no need to add complexity
to match both "FOO/8000" and "FOO/8000/1".
- The other reason is to rather parse exactly what was received, instead of
filtering entries, to take away a degree of implied magic.
Change-Id: I2a69c21e68c602daf804744212d335ab1eafd81b
- move the error logging up to the actual errors. Each appear only once, no
goto labels needed.
- instead of strstr("rtpmap"), use osmo_str_startswith("a=rtpmap:") to more
concisely trigger on the actual syntax of the audio parameters. Same for
"a=ptime:".
Change-Id: I730111e245da8485c1b5e8811f75d140e379cec6
There are allocated bits in conn->end.codecs[], free them.
This is not fixing a memleak, since mgcp_rtp_conn_cleanup() is currently only
called from mgcp_conn_free(), which soon after frees the conn; the conn serves
as talloc parent for the codec strings freed in this patch.
The rationale: it is better style to explicitly free them, to also guard
against future callers of mgcp_rtp_conn_cleanup() which might expect complete
cleanup.
Change-Id: Ic471107ce6e94d9ce582d887429c744ff93e3053
In codec_set(), for each 'goto error', log the specific error cause.
Also add a TODO and a FIXME comment about inventing dynamic payload type
numbers.
Change-Id: I0b44b574c814882b6f8ae7cd738a6f481cd721fd
In codecs_same(), do not compare the complete audio_name. The parts of it are
already checked individually:
- subtype_name ("AMR"),
- rate ("8000"; defaults to 8000 if omitted) and
- channels ("1"; defaults to 1 if omitted)
So by also checking the complete audio_name, we brushed over the match of
implicit "/8000" and "/8000/1", which otherwise works out fine.
As a result, translating payload type numbers in RTP headers now also works if
one conn of an endpoint set an rtpmap with "AMR/8000" and the other conn set
"AMR/8000/1".
It seems to me that most PBX out there generate ptmaps omitting the "/1", so
fixing this should make us more interoperable with third party SDP.
See IETF RFC4566 section 6. SDP Attributes:
For audio streams, <encoding parameters> indicates the number
of audio channels. This parameter is OPTIONAL and may be
omitted if the number of channels is one, provided that no
additional parameters are needed.
Also allowing to omit the "/8000" is a mere side effect of this patch.
Omitting the rate does not seem to be specified in an RFC, but is logical for
audio codecs defined to require exactly 8000 set as rate (most GSM codecs).
Add tests in mgcp_test.c.
Change-Id: Iab00bf9a55b1847f85999077114b37e70fb677c2
Instead of manually entering codec values, use mgcp_codec_add() to populate
test conns with codecs. The idea is to better test what actually happens when
parsing SDP codec strings.
Rewrite current test_mgcp_codec_pt_translate() from procedural to a data model
with human readable stdout logging.
This prepares to enable interpreting codec strings like "FOO/8000/1" as
equivalent with "FOO/8000": the SDP standard defines the final "/1", indicating
the nr of channels, as optional for a single channel, but osmo-mgw currently is
unable to match these two formats as identical. So prepare the
test_mgcp_codec_pt_translate() so that upcoming patches can incorporate strings
with and without the final "/1" by extending the struct arrays.
Change-Id: I888000d77512cfecb0f199b86ef6003e7fc0e6cb
The audio_name and subtype_name are allocated from talloc, so they need to be
freed before resetting the codec array. Use mgcp_codec_free() to ensure this.
Change-Id: I07f207dcb7ce66bbf3445a30af41e696677b384f
Both are used only in the same .c file, so make them static.
Move codec_set() guts into codec_add(): codec_set is only called by codec_add.
If codec_set were left separate, it'd look like the codec_init() is a bug and
lacks a codec_free() first. When looking at the entire context in codec_add(),
it becomes obvious that codec_init() should be called, not codec_free(),
because it is populating a previously unused entry.
Preparation to fix a memleak in a conn's codec list.
Change-Id: I120cab0a352a1e7b31c8f9c720c47b2c291311d7
If mgcp_send() runs a transcoder loop, break the loop if rfc5993_hr_convert()
or amr_oa_bwe_convert() return with error. Possibly fixes an infinite loop
situation for erratic packets? (Didn't check for that in detail.)
Change-Id: Iba115a0b1d74e7cefba5dcdd777e98ddea9eba8c
Remove various OSMO_ASSERT() on size of incoming packets. Doing an assert on
incoming data is a DoS attack vector, absolute no-go. Instead, return -EINVAL
and keep running.
Change some return values to be able to distinguish successful operation from
invalid RTP sizes. In rtp_data_net(), make sure to return negative if the RTP
packet was invalid.
Some of the error return codes implemented here will only be used in upcoming
patch Iba115a0b1d74e7cefba5dcdd777e98ddea9eba8c.
Change-Id: I6bc6ee950ce07bcc2c585c30fad02b81153bdde2
The name 'cmp' implies a return value of -1, 0, 1 to indicate smaller, match or
larger. Since this function returns bool, it should not be named with 'cmp'.
Change-Id: I2d41b1a32300e295551e85d3f9ab82dd2b0e86b8
Current code uses APIs like osmux_xfrm_output_init2() and osmo_amr_*(),
that are only available in libosmo-netif 0.6.0 onwards. Let's update
configure.ac accordingly.
Change-Id: I3bc0196bb6b5c5e5cf96935422fd56c4582ed7f5
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Icf4d18969488c9eacca7a597d4071828e649e772
Related: OS#4138
Return variable specified by strtoul() is "unsigned long int". If
"unsigned int" is used, according to Coverity the return value can never
be ULONG_MAX:
CID 202173: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
"pt == 18446744073709551615UL /* 9223372036854775807L * 2UL + 1UL */" is always false regardless of the values of its operands. This occurs as the logical second operand of "&&".
Furthermore, PT is 7 bit in RTP header [1], so let's avoid accepting
incorrect values.
[1] https://tools.ietf.org/html/rfc3550#section-5
Fixes: c5c1430a1c ("Catch unsigned integer MGCP parsing errors with strtoul")
Fixes: Coverity CID#202172
FIxes: Coverity CID#202173
Change-Id: Ice9eee6a252fab73dbab5ebf3cfc83c1b354fd08
There is unfortunately no way to suppres this witha pragma,
and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed
Related: OS#4123
Change-Id: Ib157bd2e110b271dbe5ac928c98251e016477f56
Mark osmocom/mgcp_client/mgcp_common.h as nodist, so "make dist" will
not try to include it in the source tarball. This caused "make dist" to
fail in a clean osmo-mgw source tree with:
make[2]: *** No rule to make target 'osmocom/mgcp_client/mgcp_common.h', needed by 'distdir'. Stop.
The file gets copied during make from osmocom/mgcp/mgcp_common.h (see
include/osmocom/mgcp_client/Makefile.am). Therefore it is not included
in the source tree and we don't need to distribute it.
Related: OS#4084
Change-Id: Ia1d7b051c0924a785b0f7ec0195192e3a852ed70
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I637cb20f0af4de33ebf6589b1aff260d57d03e7b
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: Ifc1b3bfe6ff6922df478cea89bbbb291b5fa5706
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I7d1e55faddafa3c3093d38513d4a434ecf5ea5bd
Otherwise it would not catch a duplicate if first the param is
introduced in upper case and later in lower case, or the other way
around.
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I254bfa3a2d2562441ca3a576cc8e1e7967d9c495
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I51dc1cdcbe2a5587769335fbecb5039ef22cae5d
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I4da93dfc69b5585a197a7e201a1afb72c2f97030
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I4f7b07b77c2946e9cd6f0eeca00011bd905126dd
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: I48252415f9d0cd985ad097f334aa4c1665f52511
MGCP RFC3435 (https://tools.ietf.org/html/rfc3435) states almost all
text has to be handled in a case-insensitive way, except SDP parts.
Related: OS#4001
Change-Id: Ic28a5eacc4c441d68e8a20d2743956ab2e01125d
It can be used together with LCLS, just make sure to also enable
keep-alive packets.
In OS#3429 it was pointed out, that during LCLS the media path remains
active but is not used. Without any traffic flowing, this looks like a
timed out connection and so it will be killed if conn-timeout is set.
However, OsmoBSC and OsmoMSC have an option to enable RTP keep-alive
packets (through libosmo-mgcp, originally intended to keep connections
behind NAT open). If that option is enabled, the keep-alive packets
should also prevent the conn-timeout.
Related: OS#3783
Change-Id: Ib4d19104d558a26a444a80fb36f4b7b33bc5cc59
VTY command to disable conn-timeout again, after it has been enabled.
conn-timeout was introduced in [1].
[1] Change-Id I18886052e090466f73829133c24f011806cc1fe0.
Change-Id: I7dee7dafaaf4bb93fd692ea06b52b9e012beac6d
Move code in RTP specific path to generic dispatch_rtp_cb. This way
loopback logic is applied both for Osmux and RTP connections.
Change-Id: Ia30f5a14f150e4d151eac4d1046ea834f1685a5f
That MGCP_DUMMY_LOAD is an old hack prior to Osmux spec update, and it's
not nice since it cannot be 100% distinguished from a usual AMR ft
frame.
Let's use the correct DUMMY ft type and build it according spec. Allow
handling differently the old format for a while until we are sure no old
implementations (like bsc-nat) exist sending that kind of message.
Change-Id: Ib17d20b87b28aade49ba60519b56a96e694819af
Remove old BTS/NET no longer in use and meaningless. Use new osmo-mgw
APIs to inject payload RTP<->Osmux on the correct socket and conn.
Change-Id: I60b6ba3ffdc74efff945ba13a0b736798bdf5d8c
Previously the local one was used but nobody cared because probably
everybody was using default 1984 on different IP addresses.
Change-Id: I01e590465fa247185d74103578681e9041249099
During MDCX state is already changed to ACTIVATING but we still want to
send the local CID back to announce that we still use same local CID.
Change-Id: If182a48743ebe03f97caf9034e49b9947014bdf9
We also update code to allow setting up RTP related fields to succeed
during CRCX. We also update code to allow setting up RTP related fields to
succeed during CRCX.
Change-Id: Ia6e723d9a28ba38fc3382a4fb35ea6e5bab30c09
This is going to be useful to know if a conn is to use Osmux without
looking at implementation details. Currently we have some duplicated
information (type, osmux.state, etc.) which we may want to refactor
later. This will allow changing implementation details without caring
much about rest of code.
Change-Id: Ib5a239fdbc319bcb16317f5e959d9a724b7a444a
* remove tons of old cruft from openbsc.git that doesn't exist here
* actually add the osmo-mgw binary and .la file that we're building
Change-Id: Ic0e27c05e3ab368c195f9f9961fa70feb077a5e0
Recent commit moved mgw_endpoint_fsm from osmo-bsc.git here as
osmo_mgcpc_ep_fsm. Some API name changes were applied to avoid
collisions, but FSM was kept and it is registered during startup with
__attribute__((constructor)). As a result, with old osmo-bsc (+tests)
try to allocate its copy of mgw_endpoint_fsm, it fails because that name
is already registered.
Fixes: 538d2c53d9
Change-Id: I694ce58baa43f536b7e594b003edc891f029aa4a
osmux_xfrm_input_open_circuit returns 0 on success and -1 on error.
Confusion comes from that function being implemented by calling
osmux_batch_add_circuit which returns NULL on error.
cherry-picked from: openbsc.git ac1b03c8e59408336d07527e2597171cb99ed654.
Change-Id: Iba018aa57901642ea4c486526a973fe6023e10cf
In certain cases the endp can be NULL. LOGPENDP will dereference the
pointer to retreive the endpoint number.
Fixes: 8a893442a1e9 ("mgcp_internal: LOGPENDP: ensure *endp is not NULL")
Change-Id: Ie9b5ecf08f69533ccb2fbd7fbbb529105e0c922f
The first CRCX responds with the actual MGW endpoint name that is assigned (at
least for rtpbridge/*@mgw requests).
If multiple CRCX are scheduled at the same time on a fresh MGW endpoint, both
get fired with a '*' and each creates a separate MGW endpoint.
Make mgcp_client_endpoint_fsm avoid this, and schedule only one CRCX at first,
and the rest once the MGW endpoint name is fixated. It is thus possible to
safely issue two osmo_mgcpc_ep_ci_request() at the same time.
Change-Id: I92a9944acc96398acd6649f9c3c5badec5dd6dcc
Move mgw_endpoint_fsm from osmo-bsc here as osmo_mgcpc_ep_fsm. Apply various
renames for consistency. Use osmo_tdef from libosmocore instead of osmo-bsc's
(so far) local T_defs API.
Change T23042 to T2427001, which is a slightly less arbitrary number and
slightly more extendable in the future (2427 corresponds to the default MGCP
port at osmo-mgw, 001 is the first MGCP timer and so far the only one).
Change-Id: I9a3effd38e72841529df6c135c077116981dea36
* Cleanup naming to make it far more clear
* Drop 2 variables holding CID values (allocated_cid, cid), in favour of
1 value holdinf the value and one bool stating whether the value is
used.
* Change conn_osmux_allocate_cid to allow allocating either next
available CID or a specific one, in preparation for forthcoming patches.
This commit can be merged straight away because anyway osmux cannot be
enabled in current status (blocked by vty config) and
(conn_)osmux_allocate_cid was/is not called anywhere. However, it helps
improving code base for future re-introduction of Osmux as it is
envisioned.
Change-Id: I737a248ac6c74add8e917fe2e2f36779d0f1d685
In previous code, 2 blocks were handling osmux inclusion one after the
other under same osmux.state. However, first block changes osmux.state
so second block can never be true and X-Osmux is never added.
Change-Id: Iceee8b64978651f1fe6bb883923561b081f73d9b
Let's define macro once and use it everywhere instead of passing endp
information in different ways everywhere. Furthermore, use conn whenever
appropiate to have more information.
Change-Id: I1c49b1eb16bc5f1010376da5cf407ca6e31d81f2
This way we prepare it to add more endpoint types in the future (osmux)
and also make it clear that E1 endpoint specifics allocation is still
missing.
Change-Id: I7633b5287a436c11f0bbbdbaef1cf59a051a2471
* Get rid of string define containing printf statements
* Split name from rest of checks to easily add new names later
Change-Id: I46e05a7a3432733976760bbf1c5deb4f7610db11
RFC3267 specifies two framing modes for AMR packets. An octet aligned
mode is specified where all fields of the AMR packets are aligned to
octet boundaries. The second framing mode is the bandwith efficient mode
where the fields are directly packed one after another.
- add paring/generation functions for related SDP fmtp parameters
- add conversion function to convert AMR payload
Depends: libosmo-netif I5b5a0fa644d8dbb1f04f9d7e35312683c7b3d196
Change-Id: I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Related: OS#3807
The callback function mgcp_get_format() is used to request the codec
parameters for a specific connection. This function returns the
parameters as idividual pointers. Since there is a struct that holds all
important codec information among the ones which are currently returned
by mgcp_get_format, lets just use this codec struct as single return
value.
Change-Id: I348f9141eb59ed1a986447b96ab4a24ddf326936
Related: OS#3807
The if construct that takes care for parsing the a= parameters is
unnecessary complex. Lets handle each of the possible parameters
seperately on the same level.
Change-Id: Ifc801a757e9beb6b3974863d5ee99fc7c194559e
Related: OS#3807
The header file mgcp_sdp.h is not included by mgcp_sdp.c. Lets include
it here as well in order to be complete.
Change-Id: I3d9f28d6e7ca027b1be25d775a6a75d0fc491a50
Add conn_mode to struct mgcp_conn_peer, to allow setting an explicit connection
mode instead of implicit MGCP_CONN_RECV_ONLY / MGCP_CONN_RECV_SEND depending on
remote RTP port presence. Default to old behavior if this is left unset.
Rationale:
For IuUP Initialization, osmo-msc currently still uses a hack at osmo-mgw to
echo the IuUP Initialization back to the sender as an ACK. For sanity checking
reasons, this is done iff the CRCX created the CI in loopback mode. So, in
order to be able to switch to the mgcp_client_fsm in osmo-msc instead of
"manual" MGCP message composition and yet still be able to support IuUP and
IuCS, we need to be able to set the conn mode upon CRCX to loopback.
If we merged the IuUP patch (which is already on a branch somewhere) to
osmo-mgw, we wouldn't bother with this patch, but adding this conn mode choice
has these benefits:
- post-IuUP-fix osmo-msc versions can interop with older osmo-mgw IuUP for
IuCS.
- It is conceivable that some MGCP clients prefer explicit conn modes instead
of the implicit MGCP_CONN_RECV_ONLY / MGCP_CONN_RECV_SEND choice. This opens
the possibility to switch between conn modes with MDCX messages.
Change-Id: I26be5c4b06a680f25f19797407ab56a5a4880ddc
currently, when looking at an osmo-mgw log output with a phone call working
completely fine, you see these messages on LOGL_ERROR for each RTP packet:
20190304221420619 DRTP ERROR endpoint:0x0 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420639 DRTP ERROR endpoint:0x1 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420639 DRTP ERROR endpoint:0x0 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420659 DRTP ERROR endpoint:0x1 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
20190304221420659 DRTP ERROR endpoint:0x0 can not patch PT because no suitable egress codec was found. (mgcp_network.c:761)
Put these messages on DEBUG level instead. They currently do not convey useful
information.
Possibly our MGCP clients could use some changes in behavior regarding payload
types, but since that topic is quite unresolved, let's not spam the ERROR log
level with this.
Change-Id: I4afc41fd472ec8ba887b9263fbac62de50d7cef9
There are different specifications around on how a GSM-HR frame should
be encapsulated into an RTP packet. RFC5593 specifies a ToC (Table of
Contents) byte to be prepended in front of the payload data.
The two formats can be distinguished easily by their length. Then the
data can be formatted into the corresponding opposite format and vice
versa.
- Add new VTY rtp-patch options
- Add conversion function
Change-Id: Iceef19e5619f8c92dfa7c8cdecb2e9b15f0a11a1
Related: OS#3807
Add a watchdog timer to connections, and close these connections when
the watchdog timer expires. Kick the watchdog whenever RTP messages or
the relevant MGCP messages arrive. Add the currently remaining timeout
to "show mgcp stats" in the VTY.
This feature is disabled by default, as it is incompatible with LCLS
(connections in LCLS state appear to be inactive). Enable it with the
new "conn-timeout" VTY setting. In general, this feature can be used to
work around interoperability problems causing connections to stay open
forever, and slowly exhausting all available ports. This happened for
various reasons already.
MDCX is the only relevant MGCP message:
- CRCX creates the conn and timer
- DLCX deletes the conn and timer
- MDCX is the only remaining supported MGCP message that indicates a CI
- Can't easily generically parse a CI for all MGCP messages, parsing is
done in handle_modify_con().
Related: OS#3429
Change-Id: I18886052e090466f73829133c24f011806cc1fe0
So far, both osmo-msc and osmo-bsc always pass endpoint names of the form
'...@mgw' to osmo-mgw. Allow configuring the 'mgw' part.
Note that the actual way to pass a differing name is to pass a composed
'rtpbridge/*@foo' to mgcp_msg_gen() in the struct mgcp_msg. So this merely adds
a common VTY config for the domain name part, changes to clients are necessary.
- add mgcp_client_rtpbridge_wildcard() (useful for AoIP endpoints)
- add mgcp_client_endpoint_domain() (useful for SCCPlite endpoints)
- add mgcp client vty cfg 'mgw endpoint-domain NAME'
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
Also: our MGCP clients osmo-bsc and osmo-msc use code dup to compose the
initial 'rtpbridge/*@mgw' rtpbridge wildcard. It should be defined by this API
instead.
This will be used by:
* osmo-msc I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
* osmo-bsc I492023e9dca0233ec0a077032455d9f2e3880f78
After these, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint on two separate osmo-mgw instances:
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
osmo-mgw-for-msc.cfg:
mgcp
domain msc
osmo-msc.cfg:
msc
mgw endpoint-domain msc
There can also be '0@bsc' and '1@msc' endpoints on one single osmo-mgw instance with:
osmo-mgw.cfg:
mgcp
domain *
and same osmo-{bsc,msc}.cfg as above.
(By default, everything will still use '@mgw')
Change-Id: Ia662016f29dd8727d9c4626d726729641e21e1f8
Fix typos, use osmo_sock_get_name2() to show the tx source and target IP:port,
shorten some wording.
Depends: I8ad89ac447c9c582742e70d082072bdd40a5a398 (libosmocore)
Change-Id: Iae728192f499330d16836d9435648f6b8ed213b6
Remove public API that makes no sense anymore and is dead code.
I see the dropped API as a dead-end initial misconception of the early mgcp
client, and it doesn't really make sense to drag this stuff along. It has not
been used by osmo-msc,-bsc for a long time now, and just confuses the reader.
It is public API, yes, and older versions of osmo-msc / osmo-bsc will not be
able to compile against this, but even if it did, the resulting MGCP client
would not work with the current osmo-mgw: this API is still based on the
premise that the MGCP client dictates the MGW endpoint numbers, a concept that
cannot be used with the current osmo-mgw. Instead, osmo-mgw expects a
wildcarded endpoint upon CRCX and assigns its own endpoint names.
Also, the bts-base configuration is unused and a legacy of when osmo-bsc_mgcp
had explicit BTS and CN sides.
Change-Id: I98a9f1f17a1c4ab20cea3b08c7d21663592134d6
If the vty client enters multiple local / remote addresses, that leaks talloc
memory of the previously set addresses. Free those first, if any, using
osmo_talloc_replace_string().
Change-Id: I331b3d53b5eb330b87d798f952077a043674d409
Add the expected domain name, and move the error log to where the expected
domain name is compared.
Change-Id: I59f40dc9263f686852f103ca904fc0a6702d7c8e
Half of those are obviously zero, but I'd rather print the raw data instead of
adding string constants, even if the condition must always lead to 0.0.0.0:0.
Rationale: I had osmo-mgw listen on 0.0.0.0 and got the error message
DRTP ERROR endpoint:0x1 destination IP-address is invalid
which didn't convey that 0.0.0.0 is regarded as invalid.
Change-Id: I9e98d464a27038904797c5c10735a98ef5b7b9c3
mgcp_do_write() is the final stage of writing data towards the MGCP server
(MGW). In that function, drop an unconditional iteration and copy of the MGCP
message to a static string buffer for no apparent reason besides debug logging.
Instead, use osmo_escape_str() with a limited length, which can just be an
inline format argument in the LOGP() statement. This way, the string mangling
is simpler and only gets run when DMGCP is actually on debug log level.
Change-Id: Id6877ed7fd7dbe009b2ece8792d5160d040c1aaa
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: I24179b21ce4ff182649243e286c87c824b889454
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: Ie9db1519e89d2a8ca1e403e480f57d72fc25ab75
Jenkins currently runs the build twice, once with
MGCP="--enable-mgcp-transcoding" and once with
MGCP="--disable-mgcp-transcoding". The configure.ac does not have this
parameter, so let's remove the confusing variable.
This is in preparation for describing all environment variables used in
jenkins.sh (follow up commit).
Change-Id: I6223afef0f34d90170a691d7d5b1d9542c34c6b0
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I504f05a49721f2dfe105b6c5fd1995c4e7a0be9c
See also Ia6fe5ead4b601931c1bf41b29fc1b237aac37d2c in osmo-mgw.git, which
changes the initial single-character implementation to match this specification
of string tokens separated by spaces.
Change-Id: If15a88c3b5b40fd1d24ad0f94f3231f678669ab1
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Change-Id: I79804ec0e61cc19a679f079a083a5ea2ea3ee2de
Add a counter group for DLCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of DLCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'
While here, rename MGCP_MDCX_FAIL_DEFERRED_BY_POLICY to
MGCP_MDCX_DEFERRED_BY_POLICY; we have decided that deferred connections
aren't failures, and this keeps names used by DLCX and MDCX in sync.
Also remove some allocation failure checks with OSMO_ASSERT(); such
checks aren't en vogue anymore.
Change-Id: Ie0dde2faf02fd68a69f986973d39b1bea367039b
Depends: I80d36181600901ae2e0f321dc02b5d54ddc94139I
Related: OS#2660
Even though osmo-mgw advertises the -s option, the getopt configuration lacks
-s and that option does not work. Thus the osmo-mgw.service file that uses -s
was unable to start.
Add 's' to the getopt configuration, fix -s and hence also fix the .service
file.
Change-Id: I6f298aef73eb3486d04706910e9fdbaaebaf2481
The function that parses the LCO uses an internal buffer to store the
codec name that has been issued via LCO. This buffer is only 9 byte
long, this means an 8 character string can be stored. If a codec name
exceeds this limit it gets chopped. For example "GSM-HR-08" becomes
"GSM-HR-0", which may mess up the codec negotiation.
- Increase the buffer from 9 to 17 byte.
Change-Id: I17ce7acde1f23ab1394227d74214fe2a55cd2264
Related: OS#3673
Add a counter group for aggregated RTP connection statistics.
This group contains RTP counters which aggregate values of the
ephemeral RTP counters maintained per connection (mgcp_conn).
This provides a global overview of RTP processing for each
trunk throughout the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'.
While here, fix a typo in an item of the mgcp_conn_rate_ctr_desc array:
"rtp:octets_rx" was displayed for outbound packes; now says "_tx".
Change-Id: I80d36181600901ae2e0f321dc02b5d54ddc94139
Related: OS#2660
Add a counter group for MDCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of MDCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'.
Change-Id: I79c27425ba40c3a85edc6cd846cba325d847298c
Depends: Ia2004f8063f3a50b5d7a838ebe8a784a47fcc50d
Related: OS#2660
Add counters for error conditions which I overlooked in
commit 1e174875bf
Change-Id: Ia2004f8063f3a50b5d7a838ebe8a784a47fcc50d
Depends: If4f097c5e441914eaa24c7657813ebb3f9a49916
Related: OS#2660
Use a local variable to shorten the length of rate counter names.
Cosmetic only; no functional change.
Change-Id: If4f097c5e441914eaa24c7657813ebb3f9a49916
Related: OS#2660
Make the 'mgcp show stats' VTY command display TX/RX counters
for an RTP stream. This command was already showing the counter
for dropped packets from the same counter group, so it seems
natural to display other relevant counters in the group as well.
Change-Id: I1313e64d7d8b49964f21fc8d213cba6c9fb6c7cf
Related: OS#2660
Add a counter group for CRCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of CRCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
For example, after running the TTCN3 mgw test suite, the counters show
the following values:
OsmoMGW> show rate-counters
crxc statistics:
crcx:success: 88 (0/s 88/m 0/h 0/d) CRCX command processed successfully.
crcx:bad_action: 0 (0/s 0/m 0/h 0/d) bad action in CRCX command.
crcx:unhandled_param: 1 (0/s 1/m 0/h 0/d) unhandled parameter in CRCX command.
crcx:missing_callid: 1 (0/s 1/m 0/h 0/d) missing CallId in CRCX command.
crcx:invalid_mode: 1 (0/s 1/m 0/h 0/d) connection invalid mode in CRCX command.
crcx:limit_exceeded: 0 (0/s 0/m 0/h 0/d) limit of concurrent connections was reached.
crcx:unkown_callid: 0 (0/s 0/m 0/h 0/d) unknown CallId in CRCX command.
crcx:alloc_conn_fail: 0 (0/s 0/m 0/h 0/d) connection allocation failure.
crcx:no_remote_conn_desc: 1 (0/s 1/m 0/h 0/d) no opposite end specified for connection.
crcx:start_rtp_failure: 0 (0/s 0/m 0/h 0/d) failure to start RTP processing.
crcx:conn_rejected: 0 (0/s 0/m 0/h 0/d) connection rejected by policy.
OsmoMGW>
These same counters are now also shown by 'show mgcp stats'
in the context of the trunk which they belong to.
With input from Philipp Maier.
Change-Id: Ida82fc340d5c66180e5fe9a0d195e9be6dc64c61
Related: OS#2660
in_addr consists only of s_addr, which is an integer type that
can be compared directly. By avoiding memcmp() here we would have
been able to catch Coverity CID#188874 even without Coverity, and
make the code more compact...
Change-Id: Ic6105d39ae2fb4b301f87448b16763fe9f695621
We were comparing 16 bytes (sockaddr_in) in memcmp() rather than using
four bytes (struct in_addr in mgcp conn end).
This is a good example why we should actually simply use the == (equals)
operator rather than using memcmp which treats everything as void.
Change-Id: Ic64256619ef893d625400e8b1b573ea2c629ed9c
Fixes: Coverity CID#188874
* Refactor code to have unified checks on all paths activating Osmux.
* Improve checkings at activation time and add logging.
* Code now enforces endp osmux status to be enabled before processing
the frame through endp->osmux.out. Before, a delayed or bad pkt could
arrive and be processed by an endp with osmux not enabled, using
endp->osmux.out that was not initialized and ended up crashing:
libosmo-netif/src/osmux.c:281:3: runtime error: member access within null pointer of type 'struct msgb'
This could also happen if a BSC started sending or we received (non legacy dummy) osmux
frames before we received the BSC CRCX ACK agreeing on osmux negotiation
and switching to ACTIVATING state.
Related: SYS#4350
Port from openbsc 4a2cc9eb0a0f9424c16b26fcb757483a39d67482.
Includes fixup from openbsc I438349bffaa46a10ad8983090a4b17aed7e00d82.
Change-Id: Iac11e447ec0d76e4e74ec982a6e3f63b35548978
State ACTIVATING is set once negotiation between the 2 parts went
successfuly.
Port from openbsc 96bd7b075a59eb051079152241b127ca944b0781.
Change-Id: Ic56eda1251be41369d869e687a1cf955df2c6d61
Prior to this commit, the check was only done on legacy dummy frames.
Port from openbsc a42d4584fd01c9cd1021fab609bdaaafe859c13a.
Change-Id: I5b6606d72a9f5ae593a8e3ab5fbbe7e1e5a0ae11
Otherwise we end up in a weird state where we have timers set up but
osmux is still flagged as not enabled.
Cherry-picked from openbsc cad739d2386640a68c24e3d470ddacdcaf377561.
Change-Id: I0a334842463d311bc80a980e60fb702a0a9ad610
Since that define is already used to allocate size of osmux_cid_bitmap,
let's use it here too instead of hardcoding its value.
Change-Id: Ib2e4febee8bc6bcc035ad0a65c5c1eb94ef5e6fb
Right now it's not a big issue since OSMUX_CID_MAX is 255, so 255+1 is
256 which fits array boundaries correctly (multiple of 8). However, if
for example OSMUX_CID_MAX was modified to be 12, 12+1/8 = 1, so we'd
have an undesired memory access when accessing last 4 CIDs.
A +1 should be kept on top, because OSMUX_CID_MAX specified the maximum
number used by a CID, that is (0,OSMUX_CID_MAX), and as a result we
require OSMUX_CID_MAX+1 slots.
Change-Id: Iaf9b93712dbd2a862b01e70dd8e11893bfa6b24c
osmo-bsc-mgcp was removed recently from osmo-mgw.git as it belongs to
openbsc.git.
This symlink was a leftover from that time.
Change-Id: Ifdcb266efd821eac9d90aff186400f85751e8f42
When the peer address is still 0.0.0.0, the endpoint is not yet configured.
This commonly happens before bridging a call is complete, so instead of ERROR
logging about an invalid packet, rather INFO-log this as "early media".
Related: OS#3539
Change-Id: I335f6453bd599be76eef08fcf9e5daed071e5b6d
The Connection Identifier is defined as a hex string, so clients may send the
ID back with or without leading zeros. Ignore all leading zeros when comparing.
A specific SCCPlite MSC is observed to DLCX with Connection Identifier with
leading zeros removed, which would mismatch pefore this patch.
Extend test_conn_id_matching() in mgcp_test.c to include leading zero tests.
Now, mgcp_conn_get() would match a valid id with *any* amount of leading zeros,
even if that far surpasses the permitted conn id length. Valid lengths of
incoming conn ids should be and is checked elsewhere.
Related: OS#3509
Change-Id: If55a64a2da47b6eff035711c08e4114d70dbec91
The Connection Identifier is defined as a hex string, so clients may send the
ID back in lower case. Convert to upper case before comparing.
A specific SCCPlite MSC is observed to DLCX with Connection Identifier in lower
case, which would mismatch pefore this patch.
Add test_conn_id_matching() in mgcp_test.c to verify case insensitivity.
Cosmetic: use strcmp(), not strncmp(). In the presence of a terminating nul as
we can assume here, this makes no functional difference, but it clarifies the
code.
Related: OS#3508
Depends: Ib0ee1206b9f31d7ba25c31f8008119ac55440797 (libosmocore)
Change-Id: I8e52278c3abe9e9c8c848c2b1538bce443f68a43
Reduce the number of hex chars generated as Connection Identifier from 32 to 8.
According to RFC3435 2.1.3.2 "Names of Connections", the maximum length is
indeed 32 characters, but there isn't really a benefit of using IDs of that
size. That, and:
A specific SCCPlite MSC is seen to be able to store conn IDs of up to 8 hex
characters of length. If given more than that, it will later send 'ffffffff' as
ID, e.g. in the DLCX message, causing mismatches and rejected DLCX.
Conn IDs need to be unique only within the context of one endpoint, so
producing 32 characters of ID is far beyond overkill, especially if we
currently expect exactly two IDs per endpoint.
Notice that the maximum length of conn ID that can be handled by the message
parsing and composition doesn't change, only the length that an osmo-mgw will
generate upon CRCX does.
Related: OS#3507
Change-Id: Ia290c22a91fca0e5aa44515fca6df00064aff100
MGCP_CONN_ID_MAXLEN actually includes a terminating nul, so we need to compare
strlen() against MGCP_CONN_ID_MAXLEN-1.
Log the length if it is too long.
Add MDCX_TOO_LONG_CI test to mgcp_test.c, testing a conn id of 33 characters.
Before this patch, the test returns error code 515 meaning "not found", while
now it returns 510 meaning "invalid", showing the off-by-one. Same is
illustrated by the error log ("not found" before, "too long" now), but the
error log is not verified by mgcp_test.c.
Change-Id: I8d6cc96be252bb486e94f343a8c7cae641ff9429
Instead of just -1, return RFC3435 error codes that can be used to compose a
FAIL message response. Note that the return value stays compatible in that it
returns 0 on a valid Connection Identifier, nonzero otherwise.
The idea is to be able to distinguish between "Conn ID not found" and "Conn ID
invalid" in mgcp_test.c's expected output, in upcoming change
I8d6cc96be252bb486e94f343a8c7cae641ff9429.
Change-Id: Ifc17f2893cc4b9a865f3ffcb9888bbf1039337a6
So far, MGCP_CONN_ID_LENGTH was often used as exactly the length of the
Connection Identifier. To indicate this length as a maximum, introduce the
MGCP_CONN_ID_MAXLEN and use it everywhere. Keep the old name as an alias.
Change-Id: I1117003c7614e98535d5c201d002e459c01bdc3f
Instead of just silently truncating the conn ID if it is too long, rather
verify its length and return an error where applicable.
Adjust expected test output.
Change-Id: If2a1aab1f13e771a6705c430e3c75bd42477a23b
Add a full length (32 characters according to spec) conn ID in a CRCX response,
as well as a too long one.
The too long one is currently silently truncated, a subsequent patch will
improve on that (If2a1aab1f13e771a6705c430e3c75bd42477a23b).
Change-Id: I5f2d52f086ea2d330fcce88a176488ace972bf79
The separator between MGCP and SDP section is typically "\r\n\r\n". For some
reason the test so far used "\n\n" instead, rather use the standard separator.
Change-Id: I41c73722e5fae00663bcf96de0b57b7155809a06
I want to test arbitrary length Conn IDs ('I:'), and hence don't want to pass
the conn_id as int, but rather just include it in the message string. Prepare
for that by eliminating the extra conn_id arg and just pass a params string.
Change-Id: Ib2e718dda3aa1f6e9979dee823d973dd002e2318
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: I4bf7b6124c747a0cff5562187a099c33525e109e
Related: OS#3449
This function is set on conn ID length of 32 characters. Make it detect a
shorter length also when parsing 'o=-' headers. Before, this failed to
recognize a space as the end of the conn ID, now sees any non-hex char as end.
Related: OS#3507
Change-Id: I762c273bac172acb6d0aae6ea6267603ab654cbf
Flip logic to accurately log whether an 'I:' is included, instead of logging
the opposite.
Note that it isn't possible to log the actual conn ID, because they are random
and differ in every test run, which would collide with the fixed expected
output file mgcp_test.ok.
Change-Id: Idcd731b9daf618b97d8f7e6a776266071cd29e08
The change Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57 has replaced the
functions make_crcx_msg_bind() and make_crcx_msg_bind_connect() with
make_crcx_msg() and add_audio(). When a bidirectional connection is
needed, the user calls add_audio() to add the remaining connection
details. Unfortunately add_audio() leaves the conn_mode struct member
unchanged. Which means the connection is still at MGCP_CONN_RECV_ONLY,
which will instruct the MGW not to forward any of the received packets.
- Make sure that conn_mode is set to MGCP_CONN_RECV_SEND when
add_audio() is called.
Change-Id: Id12de37797de5af5cc447642d2fbb1af7de680df
Closes: OS#3511
Adjust the X-Osmo-IGN parsing to use string tokens instead of parsing single
characters.
Reconsidering the first implementation as a poor choice, rather specify the
format of X-Osmo-IGN as any-length string tokens separated by spaces, which is
more flexible and more future proof.
See also osmo-gsm-manuals If15a88c3b5b40fd1d24ad0f94f3231f678669ab1 which
defines the X-Osmo-IGN format as string tokens, matching this patch.
In mgcp_test, add an unknown X-Osmo-IGN item. Though the output is not checked
by the testsuite.at, running manually shows the error log about the unkown
X-Osmo-IGN item.
Change-Id: Ia6fe5ead4b601931c1bf41b29fc1b237aac37d2c
Add VTY commands "show mgcp endpoint NAME" and
"show mgcp trunk <0-64> endpoint NAME" which
show information about specific endpoints.
Change-Id: I5330e697ec34bf215de91d44209048a8dc226d51
Related: OS#2660
The format is
CRCX ...
C: ...
M: ...
X-Osmo-IGN: C
So far the only ignorable element is C, i.e. the CallID. Any other items may be
added in the future.
(I initially intended to also add '@' to ignore the endpoint name's domain
part, but in the osmo-mgw code base the domain part is verified long before any
additional headers are even parsed, so sparing that refactoring for now.)
The intention is that osmo-bsc will issue "X-Osmo-IGN: C" for all SCCPlite
calls, because we are unable to retrieve the CallID that the MSC sends to
osmo-mgw for the network side of the endpoint.
Testing with a specific SCCPlite MSC, I actually observe that all CallIDs are
1, even for concurrent calls. So, an alternative hacky solution would have been
to always pass CallID == 1 for SCCPlite connections from osmo-bsc.
Related: I257ad574d8060fef19afce9798bd8a5a7f8c99fe (osmo-bsc)
Change-Id: Id7ae275ffde8ea9389270cfe3db087ee8db00b51
Both make_crcx_msg_bind() and make_crcx_msg_bind_connect() were mostly
identical. Rather, compose the CRCX bits in one common function and just add
the audio bits in another.
Prepares cosmetically for adding X-Osmo-IGN header.
Change-Id: Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57
HACK: for IuUP, we want to reply with an IuUP Initialization ACK upon the first RTP
message received. We currently hackishly accomplish that by putting the endpoint in
loopback mode and patching over the looped back RTP message to make it look like an
ack. We don't know the femto cell's IP address and port until the RAB Assignment
Response is received, but the nano3G expects an IuUP Initialization Ack before it even
sends the RAB Assignment Response. Hence, if the remote address is 0.0.0.0 and the
MGCP port is in loopback mode, allow looping back the packet to any source.
None of these are anything near nice, during call setup using a 3G femto cell,
we still lack a proper IuUP handling. See OS#2459, OS#1937. This is merely a
temporary hack to maintain 3G voice usability in a quick and dirty way.
Related: OS#3411
Change-Id: Ib25e6261855eae8ddb8d1c0b8838cc3e30332cf1
Make the 'domain NAME' vty doc more descriptive, and add the hint that '*'
means any domain.
In check_domain_name(), exit early in success if the configured domain name is
'*'.
(Do not implement other wildcard functionality for partial matches or the
like, just the single '*'.)
Related: OS#3490
Change-Id: Ie0220c88d2f5cee15f2a90390b3c4590ac61d5eb
If no endpoint was found, assert that the cause code indicates error, so that
the remaining code path doesn't assume finding an endpoint was successful.
Also fix find_endpoint() to return an error cause (not 0) in case it finds the
domain name to be wrong.
After this, the error described in OS#3488 simply results in a CRCX failure,
not in a program crash.
Related: OS#3488
Change-Id: I87e2d76c22603d6fef89907c3cf8f7965abf35a0
When the user has set a local port for the mgcp client we want the
client to exit if this port is already occupied. If no port is set the
IETF default port is configured automatically. When we find this port
occupied we try up to 100 times the next port to find a useable port.
Since the for loop that controls the attempts always sets the port
config it uses for its checks it will mistakenly assume that the user
has set a port on the second cycle.
- Make sure we only check for the default port in the first cycle
Change-Id: Ic1fd1018d68fcac94961321615bfdd726465532d
The function mgcp_write_response_sdp() is responsible to write the
audio port and the list with the supported payload type numbers to
the sdp response. At the moment it can only write exactly one payload
type number to the response, but in the future we may want to write
several payload type numbers to the response. Lets add a function
for that so that now.
- add add_audio() helper function to add multiple payload type
numbers, but keep the functionality as it is for now
Change-Id: I662c725f697b2ffb1e3ad4671a445f943cd79b63
Related: OS#3442
The function mgcp_write_response_sdp() generates the rtpmap lines in the
sdp response. Since we will likely support multiple codecs we will need
to generate several rtpmap lines. Therefore it makes sense to split up
that part in a separate function without altering the overall
functionality (yet)
- add static function add_rtpmap() to generate the rtpmap.
Change-Id: I520e2d40fe6294c88bae63dfcbc5238ef98101e2
Related: OS#3442
When we receive a packet, we do not really check the contents. However,
we should at least do some basic checks.
- Check for short RTP packets
- Check if the length field of RTCP packets seems plausible
- Check if the packet type of RTCP packets makes sense (IANA)
Change-Id: Id47b9eee2164c542e6b673db24974859dd0a7618
Related: OS#3444
At the moment all packets that are sent with mgcp_send are fed into
mgcp_patch_pt(). This functions corrects the payload type so that it
matches the codec configuration on the egress side. However, this
functions is only to be used with RTP packets and must not be used on
RTCP packets, which we currently do because we do not check if the
packet is RTCP or RTP.
- Check if the packet is RTP before running mgcp_patch_pt()
Change-Id: I55b8aa830e4e23f991373470bd04d4db12241c56
Related: OS#3444
The test function test_multilple_codec() in mgcp_test.c creates a
lot of connections, but it never releases them. Just freeing the
cfg object is not enough since the UDP ports stay open and this
may interfere with other tests that also create connections
(port numbers).
- Make sure all endpoints are released when test_multilple_codec()
is done.
Change-Id: Ic13b4368162149ec36c93f4188fa4c71166e08d5
The IETF has designated port 2727 for call agents (clients). This
works as long as only one call agent is running. As soon as two
call agents (e.g. osmo-bsc and osmo-msc) run on the same machine.
The port numbers will collide.
To avoid such a situation we will first try the IETF port and if
we fail to use it we increment the port number until we found a
usable port. However, we should only do this if the user has not
configured a non standard port. (The rationale behind this is that
if there is a non standard port configured the choice must have
been made conciously by the user and therefor we should fail hard
so that the user gets aware of the problem.)
Change-Id: Iaa5f41fdb43ec6bf4feaefa174fd82622e37d4d0
Related: OS#2874
At the moment the mgcp client uses an arbitrary port as sourceport to
exchange MGCP messages with the MGW. However, IETF has designated a
specific port as sourceport for MGCP clients (Call agents), which is
2727. See also RFC3435, capter 3.5 Transmission over UDP.
- Change MGCP_CLIENT_LOCAL_PORT_DEFAULT from 0 to 2727
Change-Id: I96de84df3a3bf623d98b057ec3f3f621a3330a8a
Closes: OS#2874
Since no transcoding is in place osmo-mgw forwards the incoming rtp
packets as they are (there may be minor modifications of the header) from
an ingress connection to an egress connection.
This works without problems as long as both connections use the same
payload type. For IANA defined fixed payload type numbers this is
usually the case, but for dynemic payload type numbers both ends may set
up the same codecs but with different payload type numbers.
When different payload type numbers are set up, and the packet is passed
through without modification, it will have the wrong payload type when
it is sent. The receiving end may then toss the packet since it expects
packets with the payload type it has configured.
The machanism, which is introduced with this patch looks up actual codec
inside the struct data of the ingress connection and then looks for the
matching codec in the struct data of the egress connection. When it
finds the codec there it looks up the payload type of this codec. The
header of the RTP packet is then patched with the correct payoad type.
- Add function mgcp_codec_pt_translate() to look up the payload type
- Add unit-test for function mgcp_codec_pt_translate()
- Add payload type translation to mgcp_network.c
Change-Id: I3a874e59fa07bcc2a67c376cafa197360036f539
Related: OS#2728
Related: OS#3384
The regular version of the mgcp_client supports the configuration of of
custom payload types. In case some corner cases require a specific
dynamic paylod type number that is not according to 3GPP standards has
to be used the user can override the standard settings. However the fsm
based variant of the mgcp_client does not have that feature but it
should have it as well.
- add struct members for ptmap config.
- pass configuration values down to the underlying magcp client.
Change-Id: If176a3719dd9e888da16196d5fc0bdb53cc2a5f2
Related: OS#2728
Related: OS#3384
Some distributions (archlinux) or versions of libgsm install gsm.h in
/usr/include/gsm/gsm.h
Since libgsm doesn't come with a pkfconfig, let's first check if gsm.h
and take the correct path in the build setup.
Change-Id: I07d3c03903e0d4bb80e843c7ed917a27b791ea53
voidmgcp_client_conf_init(structmgcp_client_conf*conf)OSMO_DEPRECATED_OUTSIDE_LIBOSMOMGCPCLIENT("use mgcp_client_conf_alloc() (or even better, switch to the mgcp_client_pool API!)");
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
