2017-09-03 23:02:56 +00:00
# pragma once
# include <stdint.h>
2017-10-05 16:25:37 +00:00
# include <arpa/inet.h>
2017-09-03 23:02:56 +00:00
mgcp_client: Introduce mgcp_client_conf_alloc(), deprecate mgcp_client_conf_init()
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
2023-06-13 17:41:44 +00:00
# include <osmocom/mgcp_client/defs.h>
libosmo-mgcp-client: fix debian, make self-contained
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
2017-09-21 22:52:54 +00:00
# include <osmocom/mgcp_client/mgcp_common.h>
2018-07-27 14:04:41 +00:00
/* See also: RFC 3435, chapter 3.5 Transmission over UDP */
2020-08-31 17:36:31 +00:00
# define MGCP_CLIENT_LOCAL_ADDR_DEFAULT NULL /* INADDR(6)_ANY */
2022-10-17 17:20:45 +00:00
# define MGCP_CLIENT_LOCAL_PORT_DEFAULT 0
2017-09-03 23:02:56 +00:00
# define MGCP_CLIENT_REMOTE_ADDR_DEFAULT "127.0.0.1"
# define MGCP_CLIENT_REMOTE_PORT_DEFAULT 2427
2023-06-14 10:20:49 +00:00
# define MGCP_CLIENT_KEEPALIVE_DEFAULT_ENDP "null"
2018-08-23 14:36:48 +00:00
# define MGCP_CLIENT_MGW_STR "Configure MGCP connection to Media Gateway\n"
2017-09-03 23:02:56 +00:00
struct msgb ;
struct vty ;
struct mgcp_client ;
struct mgcp_client_conf {
const char * local_addr ;
int local_port ;
const char * remote_addr ;
int remote_port ;
2018-12-18 23:27:50 +00:00
/* By default, we are always addressing the MGW with e.g. 'rtpbridge/123@mgw'.
* If this is nonempty , the contained name will be used instead of ' mgw ' . */
char endpoint_domain_name [ MGCP_ENDPOINT_MAXLEN ] ;
2021-07-22 09:53:07 +00:00
/* The user may configure certain endpoint names that are reset via DLCX
* on startup . Usually this will be one wildcarded endpoint e . g .
* ' rtpbridge / ( wildcard ) ' or a number of specific E1 like e . g .
* ' ds / e1 - 0 / s - 3 / su16 - 4 ' */
struct llist_head reset_epnames ;
2021-09-03 15:50:51 +00:00
/* human readable name / description */
char * description ;
2023-06-14 10:20:49 +00:00
struct {
uint32_t timeout_sec ;
uint32_t req_interval_sec ;
char req_endpoint_name [ MGCP_ENDPOINT_MAXLEN ] ;
} keepalive ;
2017-09-03 23:02:56 +00:00
} ;
typedef unsigned int mgcp_trans_id_t ;
2018-06-07 16:51:31 +00:00
/*! Enumeration of the codec types that mgcp_client is able to handle. */
enum mgcp_codecs {
CODEC_PCMU_8000_1 = 0 ,
CODEC_GSM_8000_1 = 3 ,
CODEC_PCMA_8000_1 = 8 ,
CODEC_G729_8000_1 = 18 ,
2023-05-23 10:03:16 +00:00
CODEC_GSMEFR_8000_1 = 110 , /* 3GPP TS 48.103 table 5.4.2.2.1 */
CODEC_GSMHR_8000_1 = 111 , /* 3GPP TS 48.103 table 5.4.2.2.1 */
CODEC_AMR_8000_1 = 112 , /* 3GPP TS 48.103 table 5.4.2.2.1 */
CODEC_AMRWB_16000_1 = 113 , /* 3GPP TS 48.103 table 5.4.2.2.1 */
2021-12-21 13:38:14 +00:00
CODEC_IUFP = 96 ,
2023-05-23 10:03:16 +00:00
CODEC_CLEARMODE = 120 , /* 3GPP TS 48.103 table 5.4.2.2.1 */
2018-06-07 16:51:31 +00:00
} ;
/* Note: when new codec types are added, the corresponding value strings
* in mgcp_client . c ( codec_table ) must be updated as well . Enumerations
* in enum mgcp_codecs must correspond to a valid payload type . However ,
* this is an internal assumption that is made to avoid lookup tables .
* The API - User should not rely on this coincidence ! */
2019-02-27 04:56:53 +00:00
extern const struct value_string osmo_mgcpc_codec_names [ ] ;
static inline const char * osmo_mgcpc_codec_name ( enum mgcp_codecs val )
{ return get_value_string ( osmo_mgcpc_codec_names , val ) ; }
2018-06-07 16:51:31 +00:00
/*! Structure to build a payload type map to allow the defiition custom payload
* types . */
struct ptmap {
2018-06-25 22:05:53 +00:00
/*! codec for which a payload type number should be defined */
2018-06-07 16:51:31 +00:00
enum mgcp_codecs codec ;
2018-06-25 22:05:53 +00:00
/*! payload type number (96-127) */
2018-06-07 16:51:31 +00:00
unsigned int pt ;
} ;
client: collapse codecs[] and ptmap[]; allow codec variants
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
2023-12-07 02:46:46 +00:00
int ptmap_cmp ( const struct ptmap * a , const struct ptmap * b ) ;
2017-10-05 16:25:37 +00:00
enum mgcp_verb {
MGCP_VERB_CRCX ,
MGCP_VERB_MDCX ,
MGCP_VERB_DLCX ,
MGCP_VERB_AUEP ,
MGCP_VERB_RSIP ,
} ;
mgcp_client: Introduce mgcp_client_conf_alloc(), deprecate mgcp_client_conf_init()
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
2023-06-13 17:41:44 +00:00
struct mgcp_client_conf * mgcp_client_conf_alloc ( void * ctx ) ;
void mgcp_client_conf_init ( struct mgcp_client_conf * conf ) OSMO_DEPRECATED_OUTSIDE_LIBOSMOMGCPCLIENT ( " use mgcp_client_conf_alloc() (or even better, switch to the mgcp_client_pool API!) " ) ;
2017-09-03 23:02:56 +00:00
void mgcp_client_vty_init ( void * talloc_ctx , int node , struct mgcp_client_conf * conf ) ;
int mgcp_client_config_write ( struct vty * vty , const char * indent ) ;
struct mgcp_client_conf * mgcp_client_conf_actual ( struct mgcp_client * mgcp ) ;
struct mgcp_client * mgcp_client_init ( void * ctx ,
struct mgcp_client_conf * conf ) ;
int mgcp_client_connect ( struct mgcp_client * mgcp ) ;
2022-10-17 17:20:45 +00:00
int mgcp_client_connect2 ( struct mgcp_client * mgcp , unsigned int retry_n_ports ) OSMO_DEPRECATED ( " Use mgcp_client_connect() instead " ) ;
2021-07-26 11:20:05 +00:00
void mgcp_client_disconnect ( struct mgcp_client * mgcp ) ;
2017-09-03 23:02:56 +00:00
const char * mgcp_client_remote_addr_str ( struct mgcp_client * mgcp ) ;
uint16_t mgcp_client_remote_port ( struct mgcp_client * mgcp ) ;
2020-09-02 15:19:20 +00:00
uint32_t mgcp_client_remote_addr_n ( struct mgcp_client * mgcp ) OSMO_DEPRECATED ( " deprecated, returns 0 " ) ;
2017-09-03 23:02:56 +00:00
2018-12-18 23:27:50 +00:00
const char * mgcp_client_endpoint_domain ( const struct mgcp_client * mgcp ) ;
const char * mgcp_client_rtpbridge_wildcard ( const struct mgcp_client * mgcp ) ;
2020-06-25 18:16:22 +00:00
const char * mgcp_client_e1_epname ( void * ctx , const struct mgcp_client * mgcp , uint8_t trunk_id , uint8_t ts ,
uint8_t rate , uint8_t offset ) ;
2018-12-18 23:27:50 +00:00
2017-09-03 23:02:56 +00:00
enum mgcp_connection_mode ;
libosmo-mgcp-client: fix debian, make self-contained
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
2017-09-21 22:52:54 +00:00
extern const struct value_string mgcp_client_connection_mode_strs [ ] ;
static inline const char * mgcp_client_cmode_name ( enum mgcp_connection_mode mode )
{
return get_value_string ( mgcp_client_connection_mode_strs , mode ) ;
}
2018-06-07 16:51:31 +00:00
enum mgcp_codecs map_str_to_codec ( const char * str ) ;
2024-01-11 19:40:27 +00:00
unsigned int map_codec_to_pt ( const struct ptmap * ptmap , unsigned int ptmap_len ,
enum mgcp_codecs codec ) ;
enum mgcp_codecs map_pt_to_codec ( struct ptmap * ptmap , unsigned int ptmap_len ,
unsigned int pt ) ;
2021-09-03 15:50:51 +00:00
const char * mgcp_client_name ( const struct mgcp_client * mgcp ) ;