This patch cleans up the transmission path for osmux, this involves
the functions that extract the messages from the batch and the one
that reconstruct the timing.
They now take a list that contains the reconstructed RTP messages:
osmux_xfrm_output(osmuxh, &h_output, &list);
osmux_tx_sched(&list, &tv, tx_cb, NULL);
This patch adds the counter field to the osmux header, so we can
reduce the size of the batch even further, eg.
osmuxhdr (ctr=3)
speech
speech
speech
osmuxhdr (ctr=2)
speech
speech
...
The new header is the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT | CTR |F|Q| SeqNR | Circuit ID |AMR-FT |AMR-CMR|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The counter field is 3 bits long, thus, we can batch up to 8
RTP speech frames into one single batch per circuit ID.
I have also removed the RTP marker, since it can be reconstructed
from the AMR information.
Moreover, the entire workflow has been also reworked. Whenever a
packet arrives, we introduce it into the batch list. This batch
list contains a list of RTP messages ordered by RTP SSRC. Then,
once the batch timer expires or the it gets full, we build the
batch from the list of RTP messages.
Note that this allows us to put several speech frame into one
single osmux header without actually worrying about the amount
of messages that we'll receive.
The functions that reconstruct the RTP messages has been also
adjusted. Now, it returns a list of RTP messages per RTP SSRC
that has been extracted from the batch.
This function schedules the transmission of a RTP message that was
obtained from one osmux batch. It takes the time (in microseconds)
after which the message should be transmitted.
I was using AMR CMR 2 (15 bytes) as the initial tests were done
with the codec variant.
This patch fixes this by using the new generic osmo_amr_bytes
extracted from 3GPP TS 26.101.
This patch splits osmo_rtp_parse in two functions:
osmo_rtp_get_hdr
osmo_rtp_get_payload
So we can validate corrent RTP header to access its fields. Then,
obtain the payload.
This patch adds the osmo-pcap-test infrastructure that allows you
to take packets stored in one pcap file, convert them to msgb and
pass it to some function.
The infrastructure also provides timing reconstruction based on
the pcap file information.
This is useful for easy protocol development, automated testing and
fuzzying of the existing code to validate the code.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
This patch adds the initial RTP support for libosmo-netif, it's based
on Harald's RTP support available in openBSC.
I have also added a couple of example to show how our new channel
infrastructure interacts with the RTP layer.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
This patch adds the generic channel infrastructure that allows to
create channel of different types. Each channel has their own
configuration functions.
struct osmo_chan *chan;
chan = osmo_chan_create(tall_example, CHAN_ABIS_IPA_SERVER);
...
/* specific configuration functions per supported channel. */
osmo_chan_abis_ipa_server_set_cb_signalmsg(chan, signal_msg_cb);
osmo_chan_abis_ipa_unit_add(chan, 1801, 0);
/* open channel. */
osmo_chan_open(chan);
The input path requires a callback to be registered. The output path
is handled through:
int osmo_chan_enqueue(struct osmo_chan *c, struct msgb *msg);
The msg->dst must be set (it can be taken from the original message
to route one reply).
This patch also adds A-bis IPA server support. It has been tested with
e1inp_ipa_bsc_test available in libosmo-abis.
This patch adds IPA helper function that can be use on top of stream
sockets.
The current API is just a copy and paste from libosmo-abis, it will
change in follow up patches to improve it.
We provide osmo_dgram_conn_recv(...) which allows you to take control
on the message allocation and receival process. Instead of hiding this
details inside the datagram infrastructure.
Providing more control to clients of this code means more flexibility.
Now they can be used to generate a number of messages from the
user and to measure the RTT of LAPD over datagram messages.
Still, they need to be expanded to take the origin and remote
IPs as argument from the command line, later.
Pablo Neira Ayuso