osmo-mgw/include/osmocom/mgcp_client/mgcp_client.h

128 lines
4.7 KiB
C
Raw Normal View History

#pragma once
#include <stdint.h>
#include <arpa/inet.h>
#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>
/* See also: RFC 3435, chapter 3.5 Transmission over UDP */
#define MGCP_CLIENT_LOCAL_ADDR_DEFAULT NULL /* INADDR(6)_ANY */
#define MGCP_CLIENT_LOCAL_PORT_DEFAULT 0
#define MGCP_CLIENT_REMOTE_ADDR_DEFAULT "127.0.0.1"
#define MGCP_CLIENT_REMOTE_PORT_DEFAULT 2427
mgcp-client: Add keepalive feature 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
2023-06-14 10:20:49 +00:00
#define MGCP_CLIENT_KEEPALIVE_DEFAULT_ENDP "null"
#define MGCP_CLIENT_MGW_STR "Configure MGCP connection to Media Gateway\n"
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;
mgcp_client: make domain part of endpoint configurable 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
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];
/* 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;
/* human readable name / description */
char *description;
mgcp-client: Add keepalive feature 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
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;
};
typedef unsigned int mgcp_trans_id_t;
/*! 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,
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 */
CODEC_IUFP = 96,
CODEC_CLEARMODE = 120, /* 3GPP TS 48.103 table 5.4.2.2.1 */
};
/* 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! */
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); }
/*! Structure to build a payload type map to allow the defiition custom payload
* types. */
struct ptmap {
/*! codec for which a payload type number should be defined */
enum mgcp_codecs codec;
/*! payload type number (96-127) */
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);
enum mgcp_verb {
MGCP_VERB_CRCX,
MGCP_VERB_MDCX,
MGCP_VERB_DLCX,
MGCP_VERB_AUEP,
MGCP_VERB_RSIP,
};
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!)");
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);
int mgcp_client_connect2(struct mgcp_client *mgcp, unsigned int retry_n_ports) OSMO_DEPRECATED("Use mgcp_client_connect() instead");
void mgcp_client_disconnect(struct mgcp_client *mgcp);
const char *mgcp_client_remote_addr_str(struct mgcp_client *mgcp);
uint16_t mgcp_client_remote_port(struct mgcp_client *mgcp);
uint32_t mgcp_client_remote_addr_n(struct mgcp_client *mgcp) OSMO_DEPRECATED("deprecated, returns 0");
mgcp_client: make domain part of endpoint configurable 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
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);
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);
mgcp_client: make domain part of endpoint configurable 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
2018-12-18 23:27:50 +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);
}
enum mgcp_codecs map_str_to_codec(const char *str);
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);
const char *mgcp_client_name(const struct mgcp_client *mgcp);