Suspicious code in rtp_send_frame ( libtrau/rtp_proxy.c )

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Aug 14 13:07:28 UTC 2013


Hi Andreas,

On Wed, Aug 14, 2013 at 01:19:48PM +0200, Andreas Eversberg wrote:

> it is actually working out of the box with nanobts. only required is one
> bts, because handover can be triggered via vty (subscr exten xxxx
> handover 0). because handover requires a different channel, it will
> start with a new rtp stream, so sequence numbers should be different.

That's exactly the reason why I specifically asked for two nanoBTS.  The
timing behavior of handing over between two channels on the same BTS is
not realistic, as both channels are clocked by the same master clock,
and thus do not have unsynchronized timing behavior.

Yes, the SSRC _might_ jump (technically the RTP specs would not require
it in this case), but afther that one jump it would have exactly the
same timing as before the HO - unlike the case where you hand-over to
another BTS.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list