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.
Rework batching routine to reduce its complexity, updates:
* Now it uses a list of lists to store the messages that will be
batched.
batch list
|
`-> node SSRC=a ---> ... ---> node SSRC=b
| |
msg seq=x1 msg seq=y1
| |
msg seq=x2 msg seq=y2
| |
msg seq=x3 msg seq=y3
| |
msg seq=x4 msg seq y4
This keeps easier the creation of the final batch that is sent from that
data structure.
* We also detect duplicate messages in the batch, ie. messages with the
same sequence are skipped.
Still pending to resolve reordering, corruption and omissions (reliability
is desired).
Between two RTP messages that were extracted from a batch, the
timestamp difference should be 160.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Instead of internally released. This is required if we use the
osmo_dgram infrastructure, to avoid a double release.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
This patch removes osmo_ipa_recv_msg, it performs two syscall invocations
and it's stream generic. Now we use the specific receival function
we want to use (no matter if stream or datagram based) and then we
call osmo_ipa_process_msg to check that the IPA message correct.
This adds the possibility to specify the variant of the channel.
This was discussed during the osmocom workshop. Harald wanted a way
to say if the channel is using TCP, UDP, DADHDI and so on.
This patch fixes the ordering in RTP sequence number. Before this patch,
the list was inverted.
This also fixes the calculation of the room that still remains in the
batch.
osmux only lags ~0.15 ms at maximum to transmit one scheduled RTP message
according to my tests with PCAP traces.
Yes, only ~0.15 milliseconds, this is not wrong :-).
This is good news, our timer infrastructure seems to be quite precise.
This fixes the algorithms to include the messages in order in the
batch based on the TRP SSRC (from lower to higher).
This is very important to reduce the amount of bytes that we
spend on the osmux header.