The recently-introduced dependency to libosmogsm symbols needed
some explicit addition of linker flags to avoid user applications
to fail linking with
/usr/bin/ld: /usr/local/lib/libosmonetif.so: undefined reference to `ipa_ccm_id_resp_parse'
Change-Id: I07a28f8970b90f82736e2de783bafc9d2c5ea0e5
In libosmocore Change-ID I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
we have introduced ipa_ccm_id_resp_parse() as a bugfixed replacement
of ipa_ccm_idtag_parse().
The main difference is that the returned "value" parts now have
a correct reported "length", whereas before this commit they all
reported a one-byte too-long "length" for each IE.
Let's use this opportunity to remove the copy+pasted
osmo_ipa_idtag_parse() function from the libosmo-netif codebase.
Change-Id: I4626d247626543e032593bf226b6c233f6678562
When establishing a client-side stream connection via libosmo-netif,
we must using non-blocking connect if we want to avoid blocking/stalling
the entire process. The libosmocore socket API provides the
OSMO_SOCK_F_NONBLOCK flag for this. Make use of it!
Change-Id: I9bfcb39b5801a36ef32ca0d1f3eb8236687d7ed6
Related: OS#3383
The "channel" layer on top of IPA client + server was introduced in
2011 but never used in any osmocom program/project so far. Contrary
to the several other IPA multiplex related implementations in libosmo*,
it did not deal properly with segmented IPA messages, i.e. where a
single TCP segment (and hence recv/read call) does not contain a full
IPA message.
So rather than fixing it up and having yet another IPA related API in
our libraries, let's remove it.
Change-Id: I97c378750acb1637ee032fa88a968edf68d8979f
This message is expected as all code filling batches call
osmux_batch_enqueue() and checks for error to know if it must tell the
user of the lib to call osmux_xfrm_input_deliver.
Change-Id: I3d8227f2281f6ca92fd2502d3e328765dc7ecfe9
In Change-Id: I2efed6d726a1b8e77e686c7a5fe1940d3f4901a7 we're adding a
new member to 'struct osmux_out_handle' which is not initialized.
Rather than initializing this single new member, let's do a memset()
over the entire osmux_out_handle at the beginnign of
osmux_xfrm_output_init().
Change-Id: I751e9414c6de2413a9f977e5ae5655ebfd114f45
Closes: OS#3219
Until this patch, we didn't notify in any way to the RTP reader when an
Osmux frame was lost. Instead, we updated the seq×tamp as if there
was no lost, and as a result the RTP reader would only see a steady
increase of delay every time an osmux frame was lost.
As the batch_factor for the lost packet is unknown, we cannot assume any
number of amr payloads lost, and thus we cannot simply increment seq and
timestamp for a specific amount. Instead, the only viable solution seems
to set the M marker bit in the first rtp packet generated after a
non-consecutive osmux frame is received.
The implementation may act differently with the first generated RTP
packet based on the first osmux seq number used for the stream. In case
0 it's used as first osmux seq number, M will be set depending on
request from original RTP packet having the M bit set. If it's not 0,
the first RTP packer will unconditionally have the M bit. That's not an
issue because it's anyway expect for receiver to sync on the first
packet.
Related: OS#3185
Change-Id: I2efed6d726a1b8e77e686c7a5fe1940d3f4901a7
With old implementation, in conditions with jitter we could end up
scheduling RTP generated packets from two consecutive osmux frames in an
interleaved way (from seq field point of view).
This new implementation should make it easier for any RTP
reader/playback to have better results in those conditions.
Old APIs osmux_xfm_output and osmux_tx_sched are marked as deprecated in
favour of the new one, which has a better control of generated RTP
packets. However, they are still usable despite the implementation changes
done to support the new API.
Related: OS#3180
Change-Id: I4e05ff141eb4041128ae77812bbcfe84ed4c02de
Documentation of osmo_sock_init2 doesn't provide information of any
specific value of errno set/expected after running the function. It is
incorrect to expect a specific value of errno and looking at the
implementation it is actually not a good idea to check it.
If reconnect flag is set, let's reconnect always instead of looking at
errno to decide.
Change-Id: I25b33f4cdc496ae31ff240d445b9b2805091845c
Introduce osmo_stream_srv_set_flush_and_destroy() which marks a
stream to be 'flushed and destroyed'. No new messages will be
received on this stream, and no new messages can be queued.
Once the Tx queue has been drained, the connection is destroyed.
The API user is given a chance to perform cleanup operations
in the closed_cb() callback for the connection.
The same mechanism will be added for client-side connections
in a follow-up patch.
Change-Id: I8ed78fe39c463e9018756700d13ee5ebe003b57f
Related: OS#2789
Suggested-by: Harald Welte
On destroying a client or server stream, deallocate any msgbs that are still
pending in the queue.
In libosmo-sccp, the ss7_test.c in test_as(), messages are queued and were,
before this, left floating after the stream was destroyed, causing a sanitizer
memory leak. This patch fixes the leak.
Depends: Ia291832ca445d4071f0ed9a01730d945ff691cf7 (libosmocore)
Change-Id: Iaad35f03e3bdfabf3ba82b16e563c0a5d1f03639
In previous implementation, if no reconfiguring is needed, a new socket
would be created without closing the old one, leaking the previous
socket. Instead, if we don't need reconfiguring, we return 0 as no
operation is required.
Change-Id: I6c1a7fff63e44840fb5e2bc7ace5e9a61e304987
Short changelog:
* Add Doxygen documentation
* SCTP support in stream.c
* new udp-test-client and udp-test-server programs
* better / more verbose error handling in examples
* new osmo_dgram_tx_set_local_{addr,port}() functions
* use IPA definitions from libosmogsm, rather than repeating them
* encode RTP header M field of RFC3550/4867 in OSMUX header
* new osmo_stream_srv_link_set_nodelay()
* new osmo_stream_srv_link_set_proto()
* new osmo_stream_cli_set_nodelay()
* new osmo_stream_cli_set_proto()
* new osmo_stream_cli_set_local_addr()
* new osmo_stream_cli_set_local_port()
* new osmo_stream_cli_reconnect()
* new osmo_stream_cli_open2() with reconnect argument
* more vrebose osmux_snprintf()
* remove mistaken reference to AGPL in rs232.c
* fix memory leak in osmo_stream_srv_link_set_addr()
* add osmo-pcap-test for SLL and Ethernet
* extend osmux-test
Change-Id: Ibf75fcd6643351ce3946faa155ae1db8c33a5e35
Previous implementation handled all types as if they were Osmux AMR
frames. For Dummy frames, we account the padding but we don't care about
the padding content. For Signalling ones, as they are not in the
specification yet, it is better avoid using unespecified fields and
return an error because it's still not known how extra data will be
handled in the input msgb.
Change-Id: I48565472b47c2a0e5db50881fbb005537af8c70d
The current code still expects to parse only AMR osmux frames, but that
will be fixed in following patches.
Change-Id: Ic2f4d1d3cc88af912bb43c8ecd90eacc6ff7190f
Previously recv() returning 0 for UDP socket was considered as error
although it's legitimate return value for empty UDP packets. Relax the
error check to avoid confusing error messages.
The function behavior is the same:
* msg is not altered while receiving 0-length UDP packet
* return value is 0
The only result of the relaxed error check is the absense of error log
message for 0-length UDP packet.
Change-Id: I32e5fcbf5ed92cc923660ac59e6a37fd3f0703a7
Fixes: OS#2219
There's no need for the rs232 code to include a files from
libosmoabis. The only users of libosmoabis left now are the LAPD
examples:
examples/lapd-over-datagram-network.c
examples/lapd-over-datagram-user.c
Change-Id: Ie1bc0dd811362cec546486edc41d632740ed19cd
This patch inconditionally initializes the buffer we get to
nul-terminate it, whenever possible. It's a very simple solution to
catch three overly corner cases:
1) snprintf() returns -1, very much unlikely in practise.
2) msg->len == 0: In such case, I would expect this function is never
called with an empty message, but let's be safe in this case too.
3) If your buffer is empty, it doesn't nul-terminate the buffer.
Change-Id: I97e517f2d98e83894ea707c63489559302ff6bd2
SNPRINTF_BUFFER_SIZE() looks too complex, previous version maintains two
different variables to account for the remaining space in the buffer,
one of them is always decremented based on what snprintf() returns,
which may result in underflow. These variables are swapped - not used
consistently - all over this code.
Replace this macro by a simplified version, with one single parameter to
account for remaining space. This macro also deals with two corner
cases:
1) snprintf() fails, actually never happens in practise, but
documentation indicates it may return -1, so let's catch this case
from here to stick to specs.
2) There is not enough space in the buffer, in that case, keep
increasing offset, so we know how much would have been printed, just
like snprintf() does.
Thanks to Pau Espin for reporting, and Holger for clues on this.
I have run osmux_test and, at quick glance, it looks good.
Change-Id: I5b5d6ec57a02f57c23b1ae86dbd894bad28ea797
The buffer for osmux_test is increased as the former doesn't seem to be
able to cope with the whole output.
Change-Id: Ic838dd9d7ad89b4510ccfa58c0390c69a075b616
We didn't check for cases where setsockopt_nodelay() fails. Let's check
for that and bail out + close the socket.
Change-Id: I0adbc4cec35be7c36bdf01d4d8fefd6097e9be5d
Fixes: coverity CID#166970
We couldn't figure out what "crx" as supposed to mean and assume
it is a typo. Fix the code and call it ctx, this is fixing the
API documentation as well.
Change-Id: I27ed1178fdbbcf3fc0e1070dc19b4ecf9a327a04
According to RFC4867 (RTP payload format for AMR):
"The RTP header marker bit (M) SHALL be set to 1 if the first frameblock
carried in the packet contains a speech frame which is the first in a
talkspurt. For all other packets the marker bit SHALL be set to zero (M=0)."
This information bit provides a way for the receiver to better
synchronize the delay with ther sender.
This is specially useful if AMR DTX features are supported and
enabled on the sender.
Change-Id: I0315658159429603f1d80a168718b026015060e9
This commit should fix a bug present if for instance batch_factor < 8
and osmux_batch_enqueue is called from osmux_replay_lost_packets and
enough packets were lost from last received packet.
Change-Id: I5d643810949aeca4762f0cad05eed534d35087f7
Enabling sender_dry_event in SCTP_FLAGS breaks reliable delivery of DATA
chunks to the scoket user on Linux. Let's avoid enabling that, while
still enabling various other interesting events.
See https://bugzilla.redhat.com/show_bug.cgi?id=1442784 for all related
details.
Change-Id: Ib616cd07a6044ca2ee7e05093b22df3369c62b56
We were using the wrong variable when setting the SCTP_NODELAY,
resulting in the setsoctkopt() fialing.
Change-Id: Ic04cb8bb5ff41f177f7f5b7f7e2a2ecc686dd4c0
So far we seem to assume that the accept_cb does all handling of socket
fd cleanup. However, there are cases where there is no accept_cb set,
the accept_cb returns error, or an earlier sctp_sock_activate_events()
or the activation of non-blocking mode fails.
For those cases, close the socket and return an error code.
Fixes: CID#57915
Change-Id: I3a3ce9194ab7ca5c1921fc79c2a1c9e10a552cf0
In a659590e29 we fixed endianness issues
with the Stream ID field, but at the same time mistook the PPID field
for 16bits. In reality it is 32bits, and hence our 'htons' is rendering
wrong PPID values.
Change-Id: I1b60523044835ee630dba9a43d26af4f1ebd1ced
Using this function, the user can configure if sockets related to the
respective stream client or server should have the NODELAY socket
option set in order to avoid Nagle algorithm or related algorithms
that may introduce packet delay on the transmitter side.
Change-Id: Ibeb9ba227bab18f7f4f16518c0022c4f003cc8e9
In their infinite wisdom, the inventors of SCTP designed an API (the
sockets API described in RFC6458), where some members are in host byte
order (like the stream identifier), while other members are in network
byte order (like the PPID).
Let's handle this properly (we assumed both are network byte order), and
also use 16-bit htons/ntohs fo the PPID, rather than htonl/ntohl.
Change-Id: I777174ca2915c6de0063db41a745c71b4a09bbec
* when using osmo_*_destroy(), always call *_close() internally to
make sure we don't free memory holding references to sockets that are
still open
* when closing the socket, always make sure to set the fd to -1 in all
cases, to avoid attempts to avoid later close() on a new file using
the same fd number as the socket closed previously.
Change-Id: I29c37da6e8f5be8ab030e68952a8f92add146821
during osmo_*_set_addr(), we must make sure to talloc_free() any old
address before copying in the new address. Not all functions did this,
and those that did implemented it manually. Let's use
osmo_talloc_replace_string() which is exactly intended for this case.
Change-Id: Ie1b140a160c66e8b62c745174865d5ba525cb2c2
This uses the new osmo_sock_init2() features introduced in libosmocore
Change-Id Idab124bcca47872f55311a82d6818aed590965e6 to bind *and*
connect a given socket during creation.
Change-Id: I013f4cc10b26d332d52d231f252bb0f03df8c54b
We should have doxygen documentation for all libosmo-* APIs.
libosmo-netif is currently devoid of any API docs. Let's start with the
stream and datagram socket related functions.
Change-Id: I589a5e60d9df2b8a65fbaf68f80e3ae0039d8c2a
without setting the BSC_FD_* flags prior to reconnection, the re-connect
would happen silently and the client program would not be notified via the
connect_cb().
Change-Id: Iaf8ec8662cf83476eee1b76fa41dc57f063f0ad3
In case the application is using the read-callback and a read returns 0,
then the application itself would want to trigger the reconnect. This
is different from the osmo_stream_cli_recv() case where the reconnect
can be handled internally to the library.
Change-Id: I41314bad4a9f44e8a61b9d2ba33d1a76b25bd145
if osmo_stream_cli_destroy() is called while the reconnect timer is
running, we would end up in a crash.
Change-Id: If6597130f472f1e2b8d9682002250ecd54675bb0
We use the magic value '-1' in case the file descriptor is not yet
initialized. If somebody calls osmo_stream_*_close() before this
changes, we used to crash. Let's check for this and avoid a crash.
Also, after close let's change the fd to -1 again to mark the fd
invalidity.
Change-Id: I3aa04999ab01cb7971ee2dad45dfc31ab4142868
The reconnect behavior was likely broken in commit
de3f57a8293a5b39435d6f283da23e0172bad8bb
If the user requests a re-connect, we should start it. Not only in case
the connection drops later, but also if the initial connection itself
fails.
Change-Id: I817e026404cbd9145cae2ce90bc57a1db1d2e12b
osmo_sock_init() never returns -1 + errno EINPROGRESS. It will return a
positive fd in case the connect operation is in progress. Therefore,
the related code in osmo_stream_cli_open2() was impossible to execute.
Change-Id: Id3483d1d1d4d2eabba94729ea29e5c93b33abff0
Fixes: Coverity CID 57861
When the setsockopt() in sctp_sock_activate_events() indicates an error,
let's print an error message in the log about this.
Change-Id: I5920154e23debe6d01eaa156005db0842f1a18cc
Fixes: Coverity CID 57634
Use this function in osmux_batch_del_circuit() since msgs are stored in a list
per circuit. After the circuit is free()d the msgs are lost.
Before this patch any messages enqueued inside a batch when the circiut is
deleted were leaking.
Change-Id: Ib0311652183332d0475bf7347023d518d38487ef
Ticket: OS#1733
Reviewed-on: https://gerrit.osmocom.org/120
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
caught by valgrind:
==3150== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s)
==3150== at 0x60DC0D0: __sendmsg_nocancel (syscall-template.S:81)
==3150== by 0x5DF3413: sctp_send (in /usr/lib/x86_64-linux-gnu/libsctp.so.1.0.16)
==3150== by 0x65AA066: osmo_stream_srv_write (stream.c:540)
So far, when the first connection attempt failed in
osmo_stream_cli_open(), we returned a terminal errro without any
re-connection attempts. While this may be useful in some cases, our
general idea of the stream client logic is to handle the reconnection
attempts insid the library. We introduce a new osmo_stream_cli_open2()
function while keping the old behavior for backwards compatibility.
Wih this change, osmo_stream_ client and server API can be used not only
for TCP but also for SCTP. The latter is needed in SIGTRAN ad Iuh
applications, for example.
I have added two new interfaces to add and to delete circuits from osmux input
handles. The client application needs to be adapted to use them otherwise it
will break. That's why I'm making this library release incompatible with the
previous generation.
This new function allows you to create a circuit on an existing input handle.
We don't create the circuit anymore from the first packet seen, instead the
client application is in full control of opening and closing the circuit.
This change includes a new feature to pad a circuit until we see the first
packet that contains voice data. This is useful to preallocate bandwidth on
satellite links such as Iridium/OpenPort.
Add this new function to explicitly remove an existing circuit. Thus, the
client application (openbsc) is in full control to release circuits.
Before this patch, the circuit object was added when the first RTP messages was
seen, and it was removed when transforming the list of pending RTP messages to
the Osmux message (once the timer expired).
Moreover, check circuit->nmsgs to account bytes that are consumed by the osmux
header, given that !circuit doesn't mean "this is the first packet" anymore.
Add a new field to count the number of messages in the batch that are pending
to be transformed to osmux. Use this new field to check when to enable the
osmux timer.
The follow up patch keeps circuit objects in the batch until they are closed,
so we won't be able to rely on this to know when to enable the timer anymore.
I think this is a better name for this object. Basically, an input handle
represents a batch that is composed of one or more circuit objects.
Each circuit object contains a list of RTP messages that are pending to be
converted to the osmux format in one single batch.
This new structure serves as container of the internal osmux state during
transformation from RTP AMR to the compressed osmux format.
This reduces the footprint of several functions and it makes them easier to
extend if we need to pass new information between functions.
When libosmo-abis is installed in a distinct prefix, the build failed
with non-found headers, for example:
../../src/rs232.c:38:35: fatal error: osmocom/abis/e1_input.h: No such file or directory
#include <osmocom/abis/e1_input.h>
Use the new macros to deal with little/big endian. Im a bit
worried to make this change due the little test coverage in
this module but in case of a typo the elements would not be
defined.
Make sure we don't release a osmux handle with an armed batch timer.
==9753== Invalid read of size 4
==9753== at 0x4043CA2: rb_first (rbtree.c:293)
==9753== by 0x403E172: osmo_timers_check (timer.c:256)
==9753== by 0x403E69E: osmo_select_main (select.c:124)
==9753== by 0x804EBD3: main (bsc_nat.c:1613)
==9753== Address 0x4302670 is 56 bytes inside a block of size 108 free'd
==9753== at 0x4023B6A: free (vg_replace_malloc.c:366)
==9753== by 0x40494CF: talloc_free (talloc.c:609)
==9753== by 0x40AB279: osmux_xfrm_input_fini (osmux.c:620)
==9753== by 0x80651FC: osmux_disable_endpoint (mgcp_osmux.c:96)
==9753== by 0x805CAFF: mgcp_release_endp (mgcp_protocol.c:1540)
==9753== by 0x805DD35: handle_delete_con (mgcp_protocol.c:1274)
==9753== by 0x805E998: mgcp_handle_message (mgcp_protocol.c:415)
==9753== by 0x804CFF1: mgcp_do_read (bsc_mgcp_utils.c:972)
==9753== by 0x403F96D: osmo_wqueue_bfd_cb (write_queue.c:48)
==9753== by 0x403E724: osmo_select_main (select.c:158)
==9753== by 0x804EBD3: main (bsc_nat.c:1613)
If it is not possible to put the RTP message into the batch in case that:
1) The message is malformed.
2) The message is duplicated.
3) OOM.
4) The batch is already full.
Osmux releases the messages and gets back to the upper layer with an OK
to give another chance to follow up RTP messages.
This patch also fixes a use-after-free that was possible when the batch
was full. The message was released and osmux_batch_add() was returning 0
osmux_xfrm_input(), which resulted in accessing the released message
when updating the statistics.
This is ugly, with many ifdefs, but they don't want any debug message
that can be spamming. I don't want to remove these because there is
no dissector for osmux, and this can be useful for troubleshooting.
Should be enabled only in case you consider that Osmux should
is lagging when reconstructing RTP messages. I haven't seen
any issue regarding this so far. Let's disable it by default.
This patch adds a new field to the struct osmux_in_handle that allows
you to specify the osmux frame size. If not specified, the default
size assumes your nic uses a mtu of 1500 bytes.
Remove message that is printed twice and reword the messages to
make it more clear the traffic flow when compressing and
decompressing the RTP AMR traffic.
(dc898ab osmux: don't trust AMR FT field) was not correctly
validating the AMR FT field as it was comparing the same
value twice calculated in different ways.
Use osmo_amr_bytes(amrh->ft) to obtain the expected length
and check if it is what we got. Use the output of
osmo_rtp_get_payload() as it also includes the RTP payload
stripping possible extensions.
The ctr field of the osmux header is 3 bits long, make sure we
don't run over that boundary. This should not happen in practise
unless we have to deal with network congestion or broken RTP
stacks, but osmux should not crash in that case.
With this patch, osmux_xfrm_input() returns 0 (means "message has been
processed") instead of 1 (means "retry") if the RTP message is too big
to fit into one osmux batch. This fixes a likely infinite loop in the
caller, which will retry forever for a message does not fit into the
batch.
Unlikely to happen in normal scenario, as RTP+AMR messages are way
smaller than the interface MTU.
The AMR FT field is used to infer the length of the payload, if
a value higher than 8 (SID) is received, skip it.
This fixes a possible crash in osmux_snprintf() in case we receive
a malformed osmux header.
This is also addresses the crash described in c733ae5b6e.
valgrind reports the following crash backtrace:
!<001c> osmux.c:687 No room for OSMUX payload: only 49 bytes
==12800==
==12800== Process terminating with default action of signal 11 (SIGSEGV)
==12800== Access not within mapped region at address 0xDFA8E473
==12800== at 0x4073FD2: osmux_snprintf (osmux.c:628)
==12800== by 0x80524F1: osmux_deliver (osmux.c:50)
==12800== by 0x407371C: osmux_xfrm_input_deliver (osmux.c:302)
==12800== by 0x4073792: osmux_batch_timer_expired (osmux.c:312)
==12800== by 0x405A4A0: osmo_timers_update (timer.c:243)
==12800== by 0x405A79A: osmo_select_main (select.c:133)
==12800== by 0x8049A53: main (mgcp_main.c:307)
The problem is that osmux_snprintf() is not handling multi-batch
messages (ie. messages that contain several osmux batches). More
specifically, the offset to print the osmux batches was reset
when parsing every osmux batch.
The problem also manifested with wrong outputs.
Reported by Mattias Lundstrom.
Valgrind complains about a possible use after free:
==12800== Invalid read of size 4
==12800== at 0x4073DF6: osmux_tx_sched (linuxlist.h:119)
==12800== by 0x8052B0F: osmux_read_from_bsc_nat_cb (osmux.c:261)
==12800== by 0x453F967: ???
==12800== Address 0x453f710 is 48 bytes inside a block of size 145
+free'd
==12800== at 0x402750C: free (vg_replace_malloc.c:427)
==12800== by 0x4064ADE: talloc_free (talloc.c:609)
==12800== by 0x405AAAA: msgb_free (msgb.c:72)
==12800== by 0x8052492: scheduled_tx_bts_cb (osmux.c:196)
==12800== by 0x4072CF8: osmux_tx_cb (osmux.c:554)
==12800== by 0x4073F03: osmux_tx_sched (osmux.c:582)
==12800== by 0x8052B0F: osmux_read_from_bsc_nat_cb (osmux.c:261)
==12800== by 0x453F967: ???
The problem is that osmux_tx_sched may immediately call osmux_tx_cb for
the first extracted RTP message from the osmux batch, which releases the
message after that.
Remove the message from our list of messages to be transmitted before
the message is passed to the tx callback.
Reported by Mattias Lundstrom.
According to RFC3267, AMR FT upper 9 should be discarded. This patch
adds extra validation to make sure that input RTP traffic encapsulating
AMR payload and OSMUX amr_ft field are OK with regards to that
restriction.
rtp.c:154:26: warning: The left operand to '/' is always 0
frame_diff = (usec_diff / 20000);
~~~~~~~~~ ^
rtp.c:157:43: warning: The left operand to '-' is always 0
long int frame_diff_excess = frame_diff - 1;
~~~~~~~~~~ ^
rtp.c:153:39: warning: The right operand to '+' is always 0
usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec;
^ ~~~~~~~~~~~~~~~
rtp.c:153:29: warning: The left operand to '*' is always 0
usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec;
~~~~~~~~~~~~~~ ^
4 warnings generated.
Reported by Holger Hans Peter Freyther.
osmux.c:622:20: warning: Value stored to 'osmuxh' during its
initialization is never read
struct osmux_hdr *osmuxh = (struct osmux_hdr *)msg->data;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reported by Holger Hans Peter Freyther.
If osmux notices a gap between two RTP packets, fill it with
the last RTP packet seen. Without this patch, 10% of packet loss
is enough to get garbage, with it we get glitches in the conversation
with 30%, and pretty much broken conversation with 40% of it.
Use talloc_size not talloc. Should fix:
0xb779401a in rb_erase (node=0x200200, root=0xb779c908) at rbtree.c:230
0xb779401a in rb_erase (node=0x200200, root=0xb779c908) at rbtree.c:230
0xb778ee48 in osmo_timer_del (timer=0x94aacd0) at timer.c:110
0xb778ef65 in osmo_timer_add (timer=0x94aacd0) at timer.c:72
0xb778f03c in osmo_timer_schedule (timer=0x94aacd0, seconds=0, microseconds=64000)
0xb77360ff in osmux_xfrm_input (h=0x94a4280, msg=0x94b8a50, ccid=18) at osmux.c:390
Due to uninitialization batch structures.
Remove these functions:
- osmux_xfrm_input_get_ccid
- osmux_xfrm_input_register_ccid
The ccid will be managed by the BSC and it will be stored in the
mgcp_endpoint structure.
Also adjust all tests and examples using the API.