The need of RTP payload type IE in CRCX and MDCX

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
Sat Dec 19 17:40:15 UTC 2009


On Thu, Dec 17, 2009 at 10:44:05PM +0100, Sylvain Munaut wrote:
> Hi,
> 
> I have a nanobts unit 139 with a software that somehow only accepts GSM FR
> (and not EFR), unless I also send the RTP payload type IE (
> RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP
> payload type" IE, the "RTP payload type 2" has no effect I can see).

thanks for pointing this out.  Now the question is, would that affect the later
models?  Do you have any later models to test?  If later models / versions
don't mind the RTP Payload (non-type-2), we can jusy simply always use that.

> From the ip.access dissector, I think it's just a mapping between the RTP
> 'type' used and the corresponding codec.

we can use any random number as we control both the BTS and the RTP proxy on
our side.

> For GSM FR the RFC specifies PT=3 but for HR/EFR/AMR, they are dynamic and
> must be chosed in the 96-127 range.
> AFAIK, we could just use a static mapping in openbsc or load that from the
> config. Does anyone sees a downside to that ?

static mapping is fine with me, patches welcome.

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