After call to mgcp_find_section_end(), actually check the proper variable to
evaluate its return value.
Show in mgcp_client_test output that the parsing errors are fixed, and enable
the assertion that no tests should fail.
Change-Id: I62a2453cd9e2e7d5408423161fa65ec9c9989f98
The mgcp_response_parse_params() is in a jumble. Straighten out these cosmetic
issues:
- Move assertion of r->body close to its first use.
- Instead of a talloc_zero and osmo_strlcpy dance, simply use talloc_strdup().
- Drop the first unused invocation of mgcp_find_section_end().
- Drop unused assignment of data_ptr = data.
- In the log, mention "SDP" to clarify.
- Add a comment clarifying how we skip the section marker.
Change-Id: Icf1df761270777a142bc8ace75f2a10918314f73
The struct that holds the parsing results of the MGCP response is
allocated on the stack. However, it would make sense to allocate
the struct dynamically on the heap. This also would provide a
talloc context that is in reach on most places of the code.
- Allocate struct mgcp_response dynamically in mgcp_client_rx()
- Use struct mgcp_response as talloc context for temporary
allocated memory while parsing the response.
Change-Id: I5099abe68b580c75b47bc797bf93f01084f0c4db
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
The function mgcp_msg_gen() does only check if the user supplied
an endpoint name or not. The user may still supply an endpoint
name that does not contain the separator (@) character.
- Refuse to generate the message if the endpoint name does not
contain any @ character.
Change-Id: I92dd1556e4a26b4bef8e1c8c57141552abf988ca
At the moment the client does not check if the endpoint identifier
that is returned from the MGW actually contains an @ character.
- Check if the endpoint id in the response contains an @ character.
Change-Id: I6073419a4b6cdcd31880672564f0861cb4bd02f5
When the client gets a specific endpoint identifier (Z) in a
MGCP response it just accepts the identifier even when it is
not specific (contsins wildcard characters). In those cases,
the client should refuse to parse the response.
- Check for wildcards in endpoint identifiers and stop
parsing when check is positive.
Change-Id: Ic94bd8c025b7b3eb006b639fecfd7282194e504a
The parameter ordering of the client responses does not match the
ordering as proposed by by RFC2327, Chapter 6. SDP Specification
- reorder generated SDP parameters so that they match RFC2327
Change-Id: I63cac2ebc982ffead92703c22bf68c7aafa7936c
While parsing the head of an MGCP response the r->body buffer is
manipulated in order to NUL terminate the extracted comment filed.
- Use a static buffer to store and manipulate the comment field.
Change-Id: Ib273c13d6fe7ee042fb4e3b8ed46ac02602226f6
The function mgcp_response_parse_params() that is used to parse the
SDP parameters edits the content of the r->body.
- Create a local copy of r->body and work on this copy to keep
the original r-body in its original state.
Change-Id: Ia475036f7f3802b1638e0511a5e9162fea1592eb
The mgcp protocol in general allows wildcarded endpoints on CRCX.
osmo-mgw does not support this feature yet.
- when the endpoint name contains a wildcard character, search
a free endpoint automatically
- return the resulting endpoint name in the parameter section of
the mgcp response
- add parsing support for the returned endpoint names
- Be more concious about the parameters that are returned with
each response. Do not unnecessarily attach known parameters.
Return the connection ID only on CRCX commands. Only return
the endpoint ID on CRCX commands that are wildcarded.
Change-Id: Iebc95043569191b6f5fbc8fe266b13fcfcab2e48
related: OS#2631
The mcgp message generator function mgcp_msg_gen() lacks support
for the mandatory SDP fields (v)ersion, (o)rigin, (s)ession and
(t)ime.
- Automatically generate the missing fields when SDP is
generated.
Change-Id: I5fbc31a17e8ac10c7cc5dbc31357b61e8920aaa5
Related: OS#2837
An MDCX without call-id does not make much sense. The call-id is
an integral element of the MDCX message to ensure that the correct
call is modified.
- update the presence check bitmasks to mark the call-id field
mandatory for MDCX requests
Change-Id: Id2bcc3a68139e0d935790bcea2ef91eaf6291aa3
The current implementation of mgcp_client.c requires MGCP
paragraphs to be separated wit a \n\n sequence. However,
when the client is used with servers other than osmo-mgcp,
the parapgraph may be formatted differently.
Also allow \n\r\n\r and \r\n\r\n as separator
Change-Id: Ie209fb71499e011e52f58575c6af118de2fdee88
There's no need for us to use the sockets API directly: We have
pretty nice socket helper functions in libosmocore, let's make
use of them.
Change-Id: I39d47b8a27f683060a2facf2dbecff8d00c19ce9
mgcp_msg_gen() does not check the contents of the prameters that
are handed over with the struct. This may lead to invalid mgcp
messages sent to the MGW, which can be difficult to debug.
Add some additional checks to make a possible problem
noticeable in an early stage.
- verify that the endpoint is not a nullstring
- verify that the connection id is not a nullstring
- verify that the ip-address is not a nullstring
- verify that the port number is a value greater 0
Change-Id: I15c464c4bcdf6e524f68acc62f44186dd7ad19a7
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
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
The MGCP connection identifier is allocated by the MGW while processing
the CRCX, see RFC3435 2.1.3.2:. Including/Accepting a connection
identifier in CRCX is "forbidden" as per RFC3435 Section 3.2.2.
So the MGW side must *reject* a CRCX message with 'I' parameter, and
allocate a connection identifier which is subsequently returned in the
response.
Closes: OS#2648
Change-Id: Iab6a6038e7610c62f34e642cd49c93d11151252c
The MGCP spec in RFC3435 is quite clear: Connection Identifiers are
hexadecimal strings of up to 32 characters. We should not print and
parse them as integers on either client or server.
Change the internal uint32_t representation of connection identifiers
to a string representation in the client and also in the server.
Closes: OS#2649
Change-Id: I0531a1b670d00cec50078423a2868207135b2436
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
currently the only way to generate MGCP messages is to use
mgcp_msg_crcx(), mgcp_msg_mdcx() and mgcp_msg_dlcx(). All
three function take a fixed set of parameters via their
parameter list. There is no way to add or leave away optional
parameters.
add function mgcp_msg_gen(), this function takes a unified
message struct. The struct features a presence bitmask which
allows to enable and disable parameters as needed. It is also
possible to add new parameters in the future without breaking
the API.
Depends: libosmocore I15e1af68616309555d0ed9ac5da027c9833d42e3
Change-Id: I29c5e2fb972896faeb771ba040f015592487fcbe
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
Philipp Maier
Harald Welte
Neels Hofmeyr