cellular-infrastructure
/
osmo-mgw
mirror of https://gerrit.osmocom.org/osmo-mgw
10
0
Fork 0
Code Issues Releases Wiki Activity
osmo-mgw/include/osmocom/legacy_mgcp/osmux.h

42 lines
995 B
C
Raw Normal View History

mgcp: add voice muxer support This patch adds the voice muxer. You can use this to batch RTP traffic to reduce bandwidth comsuption. Basically, osmux transforms RTP flows to a compact batch format, that is later on decompacted to its original form. Port UDP/1984 is used for the muxer traffic between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This feature depends on libosmo-netif, which contains the osmux core support. Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using the vendor-specific extension X-Osmux: on) coming from the BSC-NAT, so you can selectively enable osmux per BSC from one the bsc-nat.cfg file, so we have a centralized point to enable/disable osmux. First thing you need to do is to accept requests to use Osmux, this can be done from VTY interface of osmo-bsc_nat and osmo-bsc_mgcp by adding the following line: mgcp ... osmux on osmux batch-factor 4 This just initializes the osmux engine. You still have to specify what BSC uses osmux from osmo-bsc_nat configuration file: ... bsc 1 osmux on bsc 2 ... bsc 3 osmux on In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does not have osmux enabled. Thus, you can selectively enable osmux depending on the BSC, and we have a centralized point for configuration from the bsc-nat to enable osmux on demand, as suggested by Holger. At this moment, this patch contains heavy debug logging for each RTP packet that can be removed later to save cycles. The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that is received to configure an endpoint.
2014-02-05 17:56:17 +00:00
#ifndef _OPENBSC_OSMUX_H_
#define _OPENBSC_OSMUX_H_
#include <osmocom/netif/osmux.h>
osmux: set default port from mgcp_parse_config()
2014-08-29 10:20:17 +00:00
#define OSMUX_PORT 1984
mgcp: add voice muxer support This patch adds the voice muxer. You can use this to batch RTP traffic to reduce bandwidth comsuption. Basically, osmux transforms RTP flows to a compact batch format, that is later on decompacted to its original form. Port UDP/1984 is used for the muxer traffic between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This feature depends on libosmo-netif, which contains the osmux core support. Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using the vendor-specific extension X-Osmux: on) coming from the BSC-NAT, so you can selectively enable osmux per BSC from one the bsc-nat.cfg file, so we have a centralized point to enable/disable osmux. First thing you need to do is to accept requests to use Osmux, this can be done from VTY interface of osmo-bsc_nat and osmo-bsc_mgcp by adding the following line: mgcp ... osmux on osmux batch-factor 4 This just initializes the osmux engine. You still have to specify what BSC uses osmux from osmo-bsc_nat configuration file: ... bsc 1 osmux on bsc 2 ... bsc 3 osmux on In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does not have osmux enabled. Thus, you can selectively enable osmux depending on the BSC, and we have a centralized point for configuration from the bsc-nat to enable osmux on demand, as suggested by Holger. At this moment, this patch contains heavy debug logging for each RTP packet that can be removed later to save cycles. The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that is received to configure an endpoint.
2014-02-05 17:56:17 +00:00
enum {
OSMUX_ROLE_BSC = 0,
OSMUX_ROLE_BSC_NAT,
};
int osmux_init(int role, struct mgcp_config *cfg);
mgcp_osmux: Remove unused parameter Change-Id: Icb1e7cb15fe04642578f5292124ebc1eac9c9aa3
2017-08-11 14:48:51 +00:00
int osmux_enable_endpoint(struct mgcp_endpoint *endp, struct in_addr *addr, uint16_t port);
osmux: add osmux circuit ID management and resolve NAT problems This patch includes several osmux fixes that are interdependent: 1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This announces the circuit ID in the CRCX MGCP message. This aims to resolve the lack of uniqueness due to the use of endp->ci, which is local to the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux circuit ID. 2) The dummy load routines are now used to setup osmux both in bsc and bsc-nat to resolve source port NAT issues as suggested by Holger. The source port that is used from the bsc is not known until the first voice message is sent to the bsc-nat, therefore enabling osmux from the MGCP plane breaks when a different source port is used. 3) Add refcnt to struct osmux_handle, several endpoints can be using the same input RTP osmux handle to perform the batching. Remove it from the osmux handle list once nobody is using it anymore to clean it up. 4) Add a simple Osmux state-machine with three states. The initial state is disabled, then if the bsc-nat requests Osmux, both sides enters activating. The final enabled state is reached once the bsc-nat sees the dummy load message that tells what source port is used by the bsc. 5) The osmux input handle (which transforms RTP messages to one Osmux batch) is now permanently attached to the endpoint when Osmux is set up from the dummy load path, so we skip a lookup for each message. This simplifies osmux_xfrm_to_osmux(). After this patch, the workflow to setup Osmux is the following: bsc bsc-nat | | |<------ CRCX ----------| | X-Osmux: 3 | (where 3 is the Osmux circuit ID | | that the bsc-nat has allocated) |------- resp --------->| | X-Osmux: 3 | (the bsc confirm that it can | | use Osmux). . . | | setup osmux |----- dummy load ----->| setup osmux | Osmux CID: 3 | In two steps: 1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique Osmux CID that is notified to the bsc through the 'X-Osmux:' extension. The bsc-nat annotates this circuit ID in the endpoint object. The bsc replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux. If the bsc doesn't want to use Osmux, it doesn't include the extension so the bsc-nat knows that it has to use to RTP. 2nd) The dummy load is used to convey the Osmux CID. This needs to happen at this stage since the bsc-nat needs to know what source port the bsc uses to get this working since the bsc may use a different source port due to NAT. Unfortunately, this can't be done from the MGCP signal plane since the real source port is not known that the bsc uses is not known. This patch also reverts the MDCX handling until it is clear that we need this special handling for this case.
2014-08-27 15:02:52 +00:00
void osmux_disable_endpoint(struct mgcp_endpoint *endp);
osmux: Remember the allocated CID and make sure it is released There appears to be a leak of CIDs: <000b> mgcp_osmux.c:544 All Osmux circuits are in use! There are paths that a CID had been requested and never released of the NAT. Remember the allocated CID inside the endpoint so it can always be released. It is using a new variable as the behavior for the NAT and MGCP MGW is different. The allocated_cid must be signed so that we can assign outside of the 0-255 range of it. Fixes: OW#1493
2015-10-04 09:11:11 +00:00
void osmux_allocate_cid(struct mgcp_endpoint *endp);
void osmux_release_cid(struct mgcp_endpoint *endp);
mgcp: add voice muxer support This patch adds the voice muxer. You can use this to batch RTP traffic to reduce bandwidth comsuption. Basically, osmux transforms RTP flows to a compact batch format, that is later on decompacted to its original form. Port UDP/1984 is used for the muxer traffic between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This feature depends on libosmo-netif, which contains the osmux core support. Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using the vendor-specific extension X-Osmux: on) coming from the BSC-NAT, so you can selectively enable osmux per BSC from one the bsc-nat.cfg file, so we have a centralized point to enable/disable osmux. First thing you need to do is to accept requests to use Osmux, this can be done from VTY interface of osmo-bsc_nat and osmo-bsc_mgcp by adding the following line: mgcp ... osmux on osmux batch-factor 4 This just initializes the osmux engine. You still have to specify what BSC uses osmux from osmo-bsc_nat configuration file: ... bsc 1 osmux on bsc 2 ... bsc 3 osmux on In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does not have osmux enabled. Thus, you can selectively enable osmux depending on the BSC, and we have a centralized point for configuration from the bsc-nat to enable osmux on demand, as suggested by Holger. At this moment, this patch contains heavy debug logging for each RTP packet that can be removed later to save cycles. The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that is received to configure an endpoint.
2014-02-05 17:56:17 +00:00
int osmux_xfrm_to_rtp(struct mgcp_endpoint *endp, int type, char *buf, int rc);
int osmux_xfrm_to_osmux(int type, char *buf, int rc, struct mgcp_endpoint *endp);
int osmux_send_dummy(struct mgcp_endpoint *endp);
osmux: add osmux circuit ID management and resolve NAT problems This patch includes several osmux fixes that are interdependent: 1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This announces the circuit ID in the CRCX MGCP message. This aims to resolve the lack of uniqueness due to the use of endp->ci, which is local to the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux circuit ID. 2) The dummy load routines are now used to setup osmux both in bsc and bsc-nat to resolve source port NAT issues as suggested by Holger. The source port that is used from the bsc is not known until the first voice message is sent to the bsc-nat, therefore enabling osmux from the MGCP plane breaks when a different source port is used. 3) Add refcnt to struct osmux_handle, several endpoints can be using the same input RTP osmux handle to perform the batching. Remove it from the osmux handle list once nobody is using it anymore to clean it up. 4) Add a simple Osmux state-machine with three states. The initial state is disabled, then if the bsc-nat requests Osmux, both sides enters activating. The final enabled state is reached once the bsc-nat sees the dummy load message that tells what source port is used by the bsc. 5) The osmux input handle (which transforms RTP messages to one Osmux batch) is now permanently attached to the endpoint when Osmux is set up from the dummy load path, so we skip a lookup for each message. This simplifies osmux_xfrm_to_osmux(). After this patch, the workflow to setup Osmux is the following: bsc bsc-nat | | |<------ CRCX ----------| | X-Osmux: 3 | (where 3 is the Osmux circuit ID | | that the bsc-nat has allocated) |------- resp --------->| | X-Osmux: 3 | (the bsc confirm that it can | | use Osmux). . . | | setup osmux |----- dummy load ----->| setup osmux | Osmux CID: 3 | In two steps: 1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique Osmux CID that is notified to the bsc through the 'X-Osmux:' extension. The bsc-nat annotates this circuit ID in the endpoint object. The bsc replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux. If the bsc doesn't want to use Osmux, it doesn't include the extension so the bsc-nat knows that it has to use to RTP. 2nd) The dummy load is used to convey the Osmux CID. This needs to happen at this stage since the bsc-nat needs to know what source port the bsc uses to get this working since the bsc may use a different source port due to NAT. Unfortunately, this can't be done from the MGCP signal plane since the real source port is not known that the bsc uses is not known. This patch also reverts the MDCX handling until it is clear that we need this special handling for this case.
2014-08-27 15:02:52 +00:00
int osmux_get_cid(void);
void osmux_put_cid(uint8_t osmux_cid);
osmux: Test cid allocation and de-allocation * Test that one can get an id * That they are assigned predicatble right now * That returning them will make the number of used ones go down * That allocating more will fail
2015-10-02 13:56:35 +00:00
int osmux_used_cid(void);
osmux: add osmux circuit ID management and resolve NAT problems This patch includes several osmux fixes that are interdependent: 1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This announces the circuit ID in the CRCX MGCP message. This aims to resolve the lack of uniqueness due to the use of endp->ci, which is local to the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux circuit ID. 2) The dummy load routines are now used to setup osmux both in bsc and bsc-nat to resolve source port NAT issues as suggested by Holger. The source port that is used from the bsc is not known until the first voice message is sent to the bsc-nat, therefore enabling osmux from the MGCP plane breaks when a different source port is used. 3) Add refcnt to struct osmux_handle, several endpoints can be using the same input RTP osmux handle to perform the batching. Remove it from the osmux handle list once nobody is using it anymore to clean it up. 4) Add a simple Osmux state-machine with three states. The initial state is disabled, then if the bsc-nat requests Osmux, both sides enters activating. The final enabled state is reached once the bsc-nat sees the dummy load message that tells what source port is used by the bsc. 5) The osmux input handle (which transforms RTP messages to one Osmux batch) is now permanently attached to the endpoint when Osmux is set up from the dummy load path, so we skip a lookup for each message. This simplifies osmux_xfrm_to_osmux(). After this patch, the workflow to setup Osmux is the following: bsc bsc-nat | | |<------ CRCX ----------| | X-Osmux: 3 | (where 3 is the Osmux circuit ID | | that the bsc-nat has allocated) |------- resp --------->| | X-Osmux: 3 | (the bsc confirm that it can | | use Osmux). . . | | setup osmux |----- dummy load ----->| setup osmux | Osmux CID: 3 | In two steps: 1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique Osmux CID that is notified to the bsc through the 'X-Osmux:' extension. The bsc-nat annotates this circuit ID in the endpoint object. The bsc replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux. If the bsc doesn't want to use Osmux, it doesn't include the extension so the bsc-nat knows that it has to use to RTP. 2nd) The dummy load is used to convey the Osmux CID. This needs to happen at this stage since the bsc-nat needs to know what source port the bsc uses to get this working since the bsc may use a different source port due to NAT. Unfortunately, this can't be done from the MGCP signal plane since the real source port is not known that the bsc uses is not known. This patch also reverts the MDCX handling until it is clear that we need this special handling for this case.
2014-08-27 15:02:52 +00:00
enum osmux_state {
OSMUX_STATE_DISABLED = 0,
osmux: Add negotiation state so race conditions can't disable osmux Without this commit it is possible that osmux is disabled again on links with high jitter. This happens when an MGCP response without X-Osmux header is received before the NAT receives an Osmux dummy frame from the other side. Ticket: SYS#2628, SYS#2627 Sponsored-by: On-Waves ehf Change-Id: Id624b0279aee5e2412059a10296ce7896e2d4628
2016-06-29 14:24:42 +00:00
OSMUX_STATE_NEGOTIATING,
osmux: add osmux circuit ID management and resolve NAT problems This patch includes several osmux fixes that are interdependent: 1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This announces the circuit ID in the CRCX MGCP message. This aims to resolve the lack of uniqueness due to the use of endp->ci, which is local to the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux circuit ID. 2) The dummy load routines are now used to setup osmux both in bsc and bsc-nat to resolve source port NAT issues as suggested by Holger. The source port that is used from the bsc is not known until the first voice message is sent to the bsc-nat, therefore enabling osmux from the MGCP plane breaks when a different source port is used. 3) Add refcnt to struct osmux_handle, several endpoints can be using the same input RTP osmux handle to perform the batching. Remove it from the osmux handle list once nobody is using it anymore to clean it up. 4) Add a simple Osmux state-machine with three states. The initial state is disabled, then if the bsc-nat requests Osmux, both sides enters activating. The final enabled state is reached once the bsc-nat sees the dummy load message that tells what source port is used by the bsc. 5) The osmux input handle (which transforms RTP messages to one Osmux batch) is now permanently attached to the endpoint when Osmux is set up from the dummy load path, so we skip a lookup for each message. This simplifies osmux_xfrm_to_osmux(). After this patch, the workflow to setup Osmux is the following: bsc bsc-nat | | |<------ CRCX ----------| | X-Osmux: 3 | (where 3 is the Osmux circuit ID | | that the bsc-nat has allocated) |------- resp --------->| | X-Osmux: 3 | (the bsc confirm that it can | | use Osmux). . . | | setup osmux |----- dummy load ----->| setup osmux | Osmux CID: 3 | In two steps: 1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique Osmux CID that is notified to the bsc through the 'X-Osmux:' extension. The bsc-nat annotates this circuit ID in the endpoint object. The bsc replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux. If the bsc doesn't want to use Osmux, it doesn't include the extension so the bsc-nat knows that it has to use to RTP. 2nd) The dummy load is used to convey the Osmux CID. This needs to happen at this stage since the bsc-nat needs to know what source port the bsc uses to get this working since the bsc may use a different source port due to NAT. Unfortunately, this can't be done from the MGCP signal plane since the real source port is not known that the bsc uses is not known. This patch also reverts the MDCX handling until it is clear that we need this special handling for this case.
2014-08-27 15:02:52 +00:00
OSMUX_STATE_ACTIVATING,
OSMUX_STATE_ENABLED,
};
osmux: Allow to enforce using Osmux for the client Some systems only want to use Osmux. In case only Osmux should be used fail if it has not be offered/acked. Client: Verified On, Off and Only with X-Osmux: 3 and without this field. <000b> mgcp_protocol.c:823 Osmux only and no osmux offered on 0x14 <000b> mgcp_protocol.c:884 Resource error on 0x14 NAT: Not tested and implemented Fixes: OW#1492
2015-10-02 15:38:27 +00:00
enum osmux_usage {
OSMUX_USAGE_OFF = 0,
OSMUX_USAGE_ON = 1,
OSMUX_USAGE_ONLY = 2,
};
mgcp: add voice muxer support This patch adds the voice muxer. You can use this to batch RTP traffic to reduce bandwidth comsuption. Basically, osmux transforms RTP flows to a compact batch format, that is later on decompacted to its original form. Port UDP/1984 is used for the muxer traffic between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This feature depends on libosmo-netif, which contains the osmux core support. Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using the vendor-specific extension X-Osmux: on) coming from the BSC-NAT, so you can selectively enable osmux per BSC from one the bsc-nat.cfg file, so we have a centralized point to enable/disable osmux. First thing you need to do is to accept requests to use Osmux, this can be done from VTY interface of osmo-bsc_nat and osmo-bsc_mgcp by adding the following line: mgcp ... osmux on osmux batch-factor 4 This just initializes the osmux engine. You still have to specify what BSC uses osmux from osmo-bsc_nat configuration file: ... bsc 1 osmux on bsc 2 ... bsc 3 osmux on In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does not have osmux enabled. Thus, you can selectively enable osmux depending on the BSC, and we have a centralized point for configuration from the bsc-nat to enable osmux on demand, as suggested by Holger. At this moment, this patch contains heavy debug logging for each RTP packet that can be removed later to save cycles. The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that is received to configure an endpoint.
2014-02-05 17:56:17 +00:00
#endif