None

'type' used and the corresponding codec. 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 ? Sylvain --000325564d6aac09c2047af385f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,<br><br>I have a nanobts unit 139 with a software that somehow only acce= pts 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 &quot;RT= P payload type&quot; IE, the &quot;RTP payload type 2&quot; has no effect I= can see).<br> <br>From the ip.access dissector, I think it&#39;s just a mapping between t= he RTP &#39;type&#39; used and the corresponding codec.<br><br>For GSM FR t= he RFC specifies PT=3D3 but for HR/EFR/AMR, they are dynamic and must be ch= osed in the 96-127 range.<br> AFAIK, we could just use a static mapping in openbsc or load that from the = config. Does anyone sees a downside to that ?<br><br>=C2=A0=C2=A0=C2=A0 Syl= vain<br><br> --000325564d6aac09c2047af385f6--