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.orgHi!
While writing the RTP proxy, I've been playing with the ip.access RTP related
code for quite a bit. This is as far as I have understood it so far:
Setting up a voice call (for one MS)
* sending IPACCESS_BIND via RSL, specifying
* the GSM channel number IE
* the IP speech mode IE, indicating
* 0x1- : uni-directional, rx-only
* 0x-1 : EFR (0: FR, 2: AMR)
* receiving IPACCESS_BIND_ACK via RSL, specifying
* the GSM channel number IE
* the ip.access connection identifier
* the locally-bound UDP port for RTP
* the locally-bound IP address for RTP
* optionally: the RTP payload type
* sending IPACCESS_CONNECT via RSL, specifying
* the GSM channel number IE
* the ip.access connection identifier (from BIND_ACK)
* the remote UDP port number for RTP
* the remote IP address for RTP
* the IP speech mode IE, indicating
* 0x0-: bi-directional
* 0x-1: EFR (0: FR, 2: AMR)
* optionally: the RTP payload type, if BIND_CAK specified it
Misc observations:
* if BIND is called with IP speech mode IE 0x10 (uni-directional FR), then no
RTP payload type is returned in BIND_ACK. Instead, the standard type for GSM
06.10 (0x03) is used in the packets.
* I'm not sure which RTP payload type (and IP speech mode) is which, i.e. if
the payload type of BIND/BIND_ACK specifies "expect this payload type for
incoming packets" or "use this payload type for all RTP packets originated by
this side"
--
- 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)