osmo-msc/openbsc/src/libmgcp/osmux.c

545 lines
14 KiB
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
/*
* (C) 2012-2013 by Pablo Neira Ayuso <pablo@gnumonks.org>
* (C) 2012-2013 by On Waves ehf <http://www.on-waves.com>
* All rights not specifically granted under this license are reserved.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU Affero General Public License as published by the
* Free Software Foundation; either version 3 of the License, or (at your
* option) any later version.
*/
#include <stdio.h> /* for printf */
#include <string.h> /* for memcpy */
#include <stdlib.h> /* for abs */
#include <netinet/in.h>
#include <osmocom/core/msgb.h>
#include <osmocom/core/talloc.h>
#include <osmocom/netif/osmux.h>
#include <osmocom/netif/rtp.h>
#include <openbsc/mgcp.h>
#include <openbsc/mgcp_internal.h>
#include <openbsc/osmux.h>
#define OSMUX_PORT 1984
static struct osmo_fd osmux_fd;
static LLIST_HEAD(osmux_handle_list);
struct osmux_handle {
struct llist_head head;
struct osmux_in_handle *in;
struct in_addr rem_addr;
int rem_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
int refcnt;
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
};
static void *osmux;
static void osmux_deliver(struct msgb *batch_msg, void *data)
{
struct osmux_handle *handle = data;
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
struct sockaddr_in out = {
.sin_family = AF_INET,
.sin_port = handle->rem_port,
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
};
char buf[4096];
memcpy(&out.sin_addr, &handle->rem_addr, sizeof(handle->rem_addr));
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
osmux_snprintf(buf, sizeof(buf), batch_msg);
LOGP(DMGCP, LOGL_DEBUG, "OSMUX delivering batch to addr=%s: %s\n",
inet_ntoa(out.sin_addr), buf);
sendto(osmux_fd.fd, batch_msg->data, batch_msg->len, 0,
(struct sockaddr *)&out, sizeof(out));
}
static struct osmux_handle *
osmux_handle_find_get(struct in_addr *addr, int rem_port)
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
{
struct osmux_handle *h;
/* Lookup for existing OSMUX handle for this destination address. */
llist_for_each_entry(h, &osmux_handle_list, head) {
if (memcmp(&h->rem_addr, addr, sizeof(struct in_addr)) == 0 &&
h->rem_port == rem_port) {
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
LOGP(DMGCP, LOGL_DEBUG, "using existing OSMUX handle "
"for addr=%s:%d\n",
inet_ntoa(*addr), ntohs(rem_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
h->refcnt++;
return h;
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
}
}
return NULL;
}
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
static void osmux_handle_put(struct osmux_in_handle *in)
{
struct osmux_handle *h;
/* Lookup for existing OSMUX handle for this destination address. */
llist_for_each_entry(h, &osmux_handle_list, head) {
if (h->in == in) {
if (--h->refcnt == 0) {
LOGP(DMGCP, LOGL_DEBUG,
"Releasing unused osmux handle for %s:%d\n",
inet_ntoa(h->rem_addr),
ntohs(h->rem_port));
llist_del(&h->head);
osmux_xfrm_input_fini(h->in);
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
talloc_free(h);
}
return;
}
}
LOGP(DMGCP, LOGL_ERROR, "cannot find Osmux input handle %p\n", in);
}
static struct osmux_handle *
osmux_handle_alloc(struct mgcp_config *cfg, struct in_addr *addr, int rem_port)
{
struct osmux_handle *h;
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
h = talloc_zero(osmux, struct osmux_handle);
if (!h)
return NULL;
h->rem_addr = *addr;
h->rem_port = rem_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
h->refcnt++;
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
h->in = talloc_zero(h, struct osmux_in_handle);
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
if (!h->in) {
talloc_free(h);
return NULL;
}
h->in->osmux_seq = 0; /* sequence number to start OSmux message from */
h->in->batch_factor = cfg->osmux_batch;
h->in->deliver = osmux_deliver;
osmux_xfrm_input_init(h->in);
h->in->data = h;
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
llist_add(&h->head, &osmux_handle_list);
LOGP(DMGCP, LOGL_DEBUG, "created new OSMUX handle for addr=%s:%d\n",
inet_ntoa(*addr), ntohs(rem_port));
return h;
}
static struct osmux_in_handle *
osmux_handle_lookup(struct mgcp_config *cfg, struct in_addr *addr, int rem_port)
{
struct osmux_handle *h;
h = osmux_handle_find_get(addr, rem_port);
if (h != NULL)
return h->in;
h = osmux_handle_alloc(cfg, addr, rem_port);
if (h == NULL)
return NULL;
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
return h->in;
}
int osmux_xfrm_to_osmux(int type, char *buf, int rc, 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 ret;
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
struct msgb *msg;
msg = msgb_alloc(4096, "RTP");
if (!msg)
return 0;
memcpy(msg->data, buf, rc);
msgb_put(msg, rc);
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
while ((ret = osmux_xfrm_input(endp->osmux.in, msg, endp->osmux.cid)) > 0) {
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
/* batch full, build and deliver it */
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_xfrm_input_deliver(endp->osmux.in);
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
}
return 0;
}
static struct mgcp_endpoint *
endpoint_lookup(struct mgcp_config *cfg, int cid,
struct in_addr *from_addr, int type)
{
struct mgcp_endpoint *tmp = NULL;
int i;
/* Lookup for the endpoint that corresponds to this port */
for (i=0; i<cfg->trunk.number_endpoints; i++) {
struct in_addr *this;
tmp = &cfg->trunk.endpoints[i];
if (!tmp->allocated)
continue;
switch(type) {
case MGCP_DEST_NET:
this = &tmp->net_end.addr;
break;
case MGCP_DEST_BTS:
this = &tmp->bts_end.addr;
break;
default:
/* Should not ever happen */
LOGP(DMGCP, LOGL_ERROR, "Bad type %d. Fix your code.\n", type);
return NULL;
}
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
if (tmp->osmux.cid == cid && this->s_addr == from_addr->s_addr)
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
return tmp;
}
LOGP(DMGCP, LOGL_ERROR, "Cannot find endpoint with cid=%d\n", cid);
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
return NULL;
}
static void scheduled_tx_net_cb(struct msgb *msg, void *data)
{
struct mgcp_endpoint *endp = data;
struct sockaddr_in addr;
mgcp_send(endp, MGCP_DEST_NET, 1, &addr, (char *)msg->data, msg->len);
msgb_free(msg);
}
static void scheduled_tx_bts_cb(struct msgb *msg, void *data)
{
struct mgcp_endpoint *endp = data;
struct sockaddr_in addr;
mgcp_send(endp, MGCP_DEST_BTS, 1, &addr, (char *)msg->data, msg->len);
msgb_free(msg);
}
static struct msgb *osmux_recv(struct osmo_fd *ofd, struct sockaddr_in *addr)
{
struct msgb *msg;
socklen_t slen = sizeof(*addr);
int ret;
msg = msgb_alloc(4096, "OSMUX");
if (!msg) {
LOGP(DMGCP, LOGL_ERROR, "cannot allocate message\n");
return NULL;
}
ret = recvfrom(ofd->fd, msg->data, msg->data_len, 0,
(struct sockaddr *)addr, &slen);
if (ret <= 0) {
msgb_free(msg);
LOGP(DMGCP, LOGL_ERROR, "cannot receive message\n");
return NULL;
}
msgb_put(msg, ret);
return msg;
}
int osmux_read_from_bsc_nat_cb(struct osmo_fd *ofd, unsigned int what)
{
struct msgb *msg;
struct osmux_hdr *osmuxh;
struct llist_head list;
struct sockaddr_in addr;
struct mgcp_config *cfg = ofd->data;
char buf[4096];
msg = osmux_recv(ofd, &addr);
if (!msg)
return -1;
/* not any further processing dummy messages */
if (msg->data[0] == MGCP_DUMMY_LOAD)
goto out;
osmux_snprintf(buf, sizeof(buf), msg);
LOGP(DMGCP, LOGL_DEBUG, "received OSMUX message from "
"BSC NAT (len=%d) %s\n", msg->len, buf);
while((osmuxh = osmux_xfrm_output_pull(msg)) != NULL) {
struct mgcp_endpoint *endp;
/* Yes, we use MGCP_DEST_NET to locate the origin */
endp = endpoint_lookup(cfg, osmuxh->circuit_id,
&addr.sin_addr, MGCP_DEST_NET);
if (!endp) {
LOGP(DMGCP, LOGL_ERROR,
"Cannot find an endpoint for circuit_id=%d\n",
osmuxh->circuit_id);
goto out;
}
LOGP(DMGCP, LOGL_DEBUG,
"sending extracted RTP from OSMUX to BSC via endpoint=%u "
"(allocated=%d)\n", ENDPOINT_NUMBER(endp), endp->allocated);
osmux_xfrm_output(osmuxh, &endp->osmux.out, &list);
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
osmux_tx_sched(&list, scheduled_tx_bts_cb, endp);
}
out:
msgb_free(msg);
return 0;
}
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
/* This is called from the bsc-nat */
static int osmux_handle_dummy(struct mgcp_config *cfg, struct sockaddr_in *addr,
struct msgb *msg)
{
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
uint8_t osmux_cid;
if (msg->len < 1 + sizeof(osmux_cid)) {
LOGP(DMGCP, LOGL_ERROR,
"Discarding truncated Osmux dummy load\n");
goto out;
}
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
LOGP(DMGCP, LOGL_DEBUG, "Received Osmux dummy load from %s\n",
inet_ntoa(addr->sin_addr));
if (!cfg->osmux) {
LOGP(DMGCP, LOGL_ERROR,
"bsc wants to use Osmux but bsc-nat did not request it\n");
goto out;
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: 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
/* extract the osmux CID from the dummy message */
memcpy(&osmux_cid, &msg->data[1], sizeof(osmux_cid));
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
endp = endpoint_lookup(cfg, osmux_cid, &addr->sin_addr, MGCP_DEST_BTS);
if (!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
LOGP(DMGCP, LOGL_ERROR,
"Cannot find endpoint for Osmux CID %d\n", osmux_cid);
goto out;
}
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
if (endp->osmux.state == OSMUX_STATE_ENABLED)
goto out;
if (osmux_enable_endpoint(endp, OSMUX_ROLE_BSC_NAT,
&addr->sin_addr, addr->sin_port) < 0 ){
LOGP(DMGCP, LOGL_ERROR,
"Could not enable osmux in endpoint %d\n",
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
ENDPOINT_NUMBER(endp));
goto out;
}
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
LOGP(DMGCP, LOGL_INFO, "Enabling osmux in endpoint %d for %s:%u\n",
ENDPOINT_NUMBER(endp), inet_ntoa(addr->sin_addr),
ntohs(addr->sin_port));
out:
msgb_free(msg);
return 0;
}
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_read_from_bsc_cb(struct osmo_fd *ofd, unsigned int what)
{
struct msgb *msg;
struct osmux_hdr *osmuxh;
struct llist_head list;
struct sockaddr_in addr;
struct mgcp_config *cfg = ofd->data;
char buf[4096];
msg = osmux_recv(ofd, &addr);
if (!msg)
return -1;
/* not any further processing dummy messages */
if (msg->data[0] == MGCP_DUMMY_LOAD)
return osmux_handle_dummy(cfg, &addr, msg);
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
osmux_snprintf(buf, sizeof(buf), msg);
LOGP(DMGCP, LOGL_DEBUG,
"received OSMUX message from BSC(%s:%d) (len=%d) %s\n",
inet_ntoa(addr.sin_addr), ntohs(addr.sin_port),
msg->len, buf);
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
while((osmuxh = osmux_xfrm_output_pull(msg)) != NULL) {
struct mgcp_endpoint *endp;
/* Yes, we use MGCP_DEST_BTS to locate the origin */
endp = endpoint_lookup(cfg, osmuxh->circuit_id,
&addr.sin_addr, MGCP_DEST_BTS);
if (!endp) {
LOGP(DMGCP, LOGL_ERROR,
"Cannot find an endpoint for circuit_id=%d\n",
osmuxh->circuit_id);
goto out;
}
LOGP(DMGCP, LOGL_DEBUG,
"sending extracted RTP from OSMUX to MSC via endpoint=%u "
"(allocated=%d)\n", ENDPOINT_NUMBER(endp), endp->allocated);
osmux_xfrm_output(osmuxh, &endp->osmux.out, &list);
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
osmux_tx_sched(&list, scheduled_tx_net_cb, endp);
}
out:
msgb_free(msg);
return 0;
}
int osmux_init(int role, struct mgcp_config *cfg)
{
int ret;
switch(role) {
case OSMUX_ROLE_BSC:
osmux_fd.cb = osmux_read_from_bsc_nat_cb;
break;
case OSMUX_ROLE_BSC_NAT:
osmux_fd.cb = osmux_read_from_bsc_cb;
break;
default:
LOGP(DMGCP, LOGL_ERROR, "wrong role for OSMUX\n");
return -1;
}
osmux_fd.data = cfg;
ret = mgcp_create_bind("0.0.0.0", &osmux_fd, OSMUX_PORT);
if (ret < 0) {
LOGP(DMGCP, LOGL_ERROR, "cannot bind OSMUX socket\n");
return ret;
}
osmux_fd.when |= BSC_FD_READ;
ret = osmo_fd_register(&osmux_fd);
if (ret < 0) {
LOGP(DMGCP, LOGL_ERROR, "cannot register OSMUX socket\n");
return ret;
}
cfg->osmux_init = 1;
return 0;
}
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_enable_endpoint(struct mgcp_endpoint *endp, int role,
struct in_addr *addr, uint16_t port)
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
{
/* If osmux is enabled, initialize the output handler. This handler is
* used to reconstruct the RTP flow from osmux. The RTP SSRC is
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
* allocated based on the circuit ID (endp->osmux.cid), which is unique
* in the local scope to the BSC/BSC-NAT. We use it to divide the RTP
* SSRC space (2^32) by the 256 possible circuit IDs, then randomly
* select one value from that window. Thus, we have no chance to have
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
* overlapping RTP SSRC traveling to the BTSes behind the BSC,
* similarly, for flows traveling to the MSC.
*/
static const uint32_t rtp_ssrc_winlen = UINT32_MAX / 256;
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
if (endp->osmux.state == OSMUX_STATE_DISABLED) {
LOGP(DMGCP, LOGL_ERROR, "Endpoint %u didn't request Osmux\n",
ENDPOINT_NUMBER(endp));
return -1;
}
osmux_xfrm_output_init(&endp->osmux.out,
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
(endp->osmux.cid * rtp_ssrc_winlen) +
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
(random() % rtp_ssrc_winlen));
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
endp->osmux.in = osmux_handle_lookup(endp->cfg, addr, port);
if (!endp->osmux.in) {
LOGP(DMGCP, LOGL_ERROR, "Cannot allocate input osmux handle\n");
return -1;
}
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
switch (endp->cfg->role) {
case MGCP_BSC_NAT:
endp->type = MGCP_OSMUX_BSC_NAT;
break;
case MGCP_BSC:
endp->type = MGCP_OSMUX_BSC;
break;
}
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
endp->osmux.state = OSMUX_STATE_ENABLED;
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
return 0;
}
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)
{
LOGP(DMGCP, LOGL_INFO, "Releasing endpoint %u using Osmux CID %u\n",
ENDPOINT_NUMBER(endp), endp->osmux.cid);
endp->osmux.state = OSMUX_STATE_DISABLED;
endp->osmux.cid = -1;
osmux_handle_put(endp->osmux.in);
}
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
/* We don't need to send the dummy load for osmux so often as another endpoint
* may have already punched the hole in the firewall. This approach is simple
* though.
*/
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
char buf[1 + sizeof(uint8_t)];
struct in_addr addr_unset = {};
buf[0] = MGCP_DUMMY_LOAD;
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
memcpy(&buf[1], &endp->osmux.cid, sizeof(endp->osmux.cid));
/* Wait until we have the connection information from MDCX */
if (memcmp(&endp->net_end.addr, &addr_unset, sizeof(addr_unset)) == 0)
return 0;
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
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
if (endp->osmux.state == OSMUX_STATE_ACTIVATING) {
if (osmux_enable_endpoint(endp, OSMUX_ROLE_BSC,
&endp->net_end.addr,
htons(OSMUX_PORT)) < 0) {
LOGP(DMGCP, LOGL_ERROR,
"Could not activate osmux in endpoint %d\n",
ENDPOINT_NUMBER(endp));
}
LOGP(DMGCP, LOGL_ERROR,
"Osmux CID %u for %s:%u is now enabled\n",
endp->osmux.cid, inet_ntoa(endp->net_end.addr),
OSMUX_PORT);
}
LOGP(DMGCP, LOGL_DEBUG,
"sending OSMUX dummy load to %s CID %u\n",
inet_ntoa(endp->net_end.addr), endp->osmux.cid);
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
return mgcp_udp_send(osmux_fd.fd, &endp->net_end.addr,
htons(OSMUX_PORT), buf, sizeof(buf));
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
}
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
/* bsc-nat allocates/releases the Osmux circuit ID */
static uint8_t osmux_cid_bitmap[16];
int osmux_get_cid(void)
{
int i, j;
for (i = 0; i < sizeof(osmux_cid_bitmap) / 8; i++) {
for (j = 0; j < 8; j++) {
if (osmux_cid_bitmap[i] & (1 << j))
continue;
osmux_cid_bitmap[i] |= (1 << j);
LOGP(DMGCP, LOGL_DEBUG,
"Allocating Osmux CID %u from pool\n", (i * 8) + j);
return (i * 8) + j;
}
}
LOGP(DMGCP, LOGL_ERROR, "All Osmux circuits are in use!\n");
return -1;
}
void osmux_put_cid(uint8_t osmux_cid)
{
LOGP(DMGCP, LOGL_DEBUG, "Osmux CID %u is back to the pool\n", osmux_cid);
osmux_cid_bitmap[osmux_cid / 8] &= ~(1 << (osmux_cid % 8));
}