19 Dec
2009
19 Dec
'09
6:40 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)