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
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in libosmo-mgcp-client's VTY interface.
Change-Id: If772edc304a9f342a57fb548f26908256cc9e6e5
Related: OS#2967
The client library should be usable to all GPLv2/v3/AGPLv2/v3 programs,
so like our general project practises, let's put it under
GPLv2-or-later. I believe this was unintentional from the beginning.
Our general policy has been:
* libraries under GPLv2-or-later
* applications under AGPLv3-or-later
Change-Id: I29ed7edc510dba67d28b9247aecb4d6d5d25cc0c
OsmoMSC is in the odd situation that it is already using the new
libosmo-mgcp-client, which is targeted at osmo-mgw, to configure talking to the
old osmo-bsc_mgcp. By removing the bts_base, we break current OsmoMSC.
Removing bts_base makes sense, but let's revert this until OsmoMSC is ready
after merging Ieea9630358b3963261fa1993cf1f3b563ff23538 (which moves the
osmo-msc over to osmo-mgw).
This reverts commit 0be3ce66c0.
Change-Id: Ibce214c2bfc35623097abbb647619426ef3dcc94
There should not be any BTS base port to be configured at an MGCP client.
Possibly this is related to the legacy behavior of libosmo-legacy-mgcp, and
certainly has no place in libosmo-mgcp-client.
Further changes may be needed to follow up on removal of the BTS base port
concept, at least drop it from the VTY for now.
Change-Id: I36e46208d7b75611e5ade3c74d8e1c25870de511
Fix errors like "remote bind address", mention 'MGW' instead of 'MGCP gateway',
minor typos and wording tweaks.
Change-Id: Ie1a408f9e651c5fb3424a84ceaaa603e20ad595c
Commit 87203f2a37 renamed some cmds to use
mgw instead of mgcpgw, and added deprecated alias for the old commands,
but forgot to add one for 'mgcpgw bts-base'. This commit fixes
backawards compatibility with old config files that mentioned commit
introduced.
Change-Id: Ib1c58945f4203b05d79f367afb3082b9a6a2c4e3
'mgcpgw' was a working title for the osmo-mgw. Before this takes hold out
there, let's rename the VTY commands to 'mgw'. I'd rather have some local
fallout in our testing environments now than drag the stupid name along.
Keep deprecated 'mgcpgw' commands for backwards compat.
Change-Id: I1d43d42929dc9162e57640499526fb7cadbcfbe6
Add mgcp_common.h to libosmo-mgcp-client, to not need to share a header file
with libosmo-legacy-mgcp (nor the upcoming libosmo-mgcp). Both libraries use
the enum mgcp_connection_mode (and a for-loop macro and a string mangling
function), so far declared in mgcp.h, and both mgcp-dev and mgcp-client-dev
debian packages would require this header file to be installed. So far the
mgcp-client-dev lacks this header file, which causes the osmo-msc debian
package to fail building. Ways to solve:
- If both -dev debian packages installed the same header file in the same
place, they would conflict if ever installed at the same time.
- mgcp-client-dev can depend on mgcp-dev, but it seems bad to keep such a large
dependency for just one enum and two helpers.
- Instead, this patch solves this by copying the few definitions to
libosmo-mgcp-client.
Once libosmo-mgcp-client has its own copy of those definitions, it is
fully self-contained and depending builds (osmo-msc deb) will succeed.
Copy the few actually common definitions to new header
<osmocom/mgcp_client/mgcp_common.h>. The nature of this .h is that it may be
shared with future libosmo-mgcp without causing linking problems.
Remove libosmo-legacy-mgcp/mgcp_common.c file from the build of
libosmo-mgcp-client, no longer needed.
Add to new mgcp_common.h:
- enum mgcp_connection_mode;
- for_each_non_empty_line() macro.
- mgcp_msg_terminate_nul() as static function. Its complexity is just above
your average static inline, but being inline is a way to use it in both mgcp
and mgcp_client without linking problems.
Replace for_each_line() use in mgcp_client with for_each_non_empty_line()
(for_each_non_empty_line() replaces for_each_line() and uses strtok_r() instead
of a local reinvention).
mgcp_connection_mode_strs are actually only used in libosmo-mgcp-client, so
rename to mgcp_client_ prefix and move to mgcp_client.c.
BTW, the future plan for upcoming libosmo-mgcp is to use the identical header
file, and keep only one copy in the git source tree. The second copy may be
generated during 'make', to avoid code dup while having two distinct headers.
Related: I8e3359bedf973077c0a038aa04f5371a00c48fa0 (fix osmo-msc after this),
I7a5d3b9a2eb90be7e34b95efa529429f2e6c3ed8 (mgcp_common.h)
Change-Id: Ifb8f3fc2b399662a9dbba174e942352a1a21df3f
The name "mgcpgw_client" referred to an MGCP gateway, which is rather an MGW
(Media Gateway). But this client code is more generally a client for the MGCP
protocol, independently from what the server program is called.
Rename the files as well as the function prefixes to drop the "gw". It is
purely cosmetic and not strictly necessary, but a good point in time for fixes
like this.
osmo-msc build will be adjusted by I093ad02ca0e532f659447c785e09678b3e6f220d.
osmo-bsc build will be adjusted by I6402c7cbe58dacae7630f7f03819f8102e54c699.
These should be applied right after this here is merged to avoid fallout.
Change-Id: I99f7faab637cfcc22ece64a1dbcbe590f2042187
Neels Hofmeyr
Harald Welte
Neels Hofmeyr
Pau Espin