rtp handling for all speech codecs

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/.

jolly andreas at eversberg.eu
Sun Mar 10 15:13:50 UTC 2013


hi,

long time ago i had these patches at a seperate "rtpmux" branch. now i
added them to a new branch (jolly/trx). they are very well tested now,
and i think they should get merged after some review. it is my aim to
support all speech codecs at osmo-nitb (built-in call handling, as well
as MNCC socket interface). these patches are essential for patches that
will follow during next weeks.


http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=f029472c1e439ee6c2519ce1b67807d4249ab55b

    Adding traffic forwarding via RTP to remote application
    
    Instead of forwarding traffic through MNCC interface, traffic can
    now be forwarded to a given RTP destination. A special MNCC message
    is used for that. The traffic can still be forwarded through MNCC
    interface when this special MNCC message is not used.
    
    It also works with E1 based BTSs.
    
    In conjunction with LCR's "rtp-bridge" feature, the RTP traffic
    can be directly exchanged with a remote SIP endpoint, so that the
    traffic is not forwarded by LCR itself. This way the performance
    of handling traffic only depends on OpenBSC and the remote SIP
    endpoint. Also the traffic is exchanged with the SIP endpoint
    without transcoding, to have maximum performance.

http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=eb333169ae035946a4ae50ff56b0f948fc5de12a

    Adding handling of BFI (Bad Frame Indicatior) of received TRAU frames
    
    If a bad TRAU frame is received, it is forwarded to MNCC application
    as GSM_TCHF_BAD_FRAME. The application can now handle the GAP of
    missing audio. (e.g. with extrapolation)
    
    If TRAU frames are forwarded via RTP, bad frames are dropped, but frame
    counter and timestamp of RTP sender state is increased.

http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=7fb2bf09ec2855dd6e7b164d98b8ccf5cace46ba

    Allow dynamic RTP payload types between application and MNCC interface
    
    Since EFR/AMR/HR codecs use dynamic RTP payload, the payload type can
    be set. If it is set, the frame type must be set also, so OpenBSC
    knows what frame types are received via RTP.
    
    This modification only affects traffic beween application and MNCC
    interface, not the RTP traffic between OpenBSC and BTS.

http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=42eb7251b96581e2f9f9af38fcb0ba08a137e97f

    Fixed delay problems, if RTP stream jitters too much
    
    The RTP stream is generated or forwarded by OpenBSC to nanoBTS. Due to
    switching of streams (hold/retrieve call), packet loss or even stalling
    of sender's process, the time stamp must be corrected. If outdated
    packets are received, they get dropped.

http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=ee20ef2691fb20b3a94c7e734cc4c65bebee6d17

    Finished support for all codecs (RTP bridge and MNCC interface)
   
    The code is not yet tested.
   
    AMR rate is currently fixed to 5.9k.

http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=5140fa39898d159be5a6e621ead2ffe885b6174e

    Fixed problem of mute audio on some calls
   
    When reading from RTP socket, the first read() may fail right after
    connecting to remote socket. Subsequent read() will work as it should.
   
    I have not checked why this read fails, but I don't see any reason
    why we should stop reading, just because one read() fails at the
    beginning.

http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=82e1a17ecb71233a0ea87d692f695e3cd493d2dc

    Fix: TCHH/HR payloads are 15 bytes (ToC + 14 bytes of speech data)

note: this last fix can be applied to the patches above, rather than
merged seperately.

any suggestions?


andreas





More information about the OpenBSC mailing list