<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> I have a nanobts unit 139 with a software that somehow only accepts GSM FR<br>
> (and not EFR), unless I also send the RTP payload type IE (<br>
> RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP<br>
> payload type" IE, the "RTP payload type 2" has no effect I can see).<br>
<br>
</div>thanks for pointing this out.  Now the question is, would that affect the later<br>
models?  Do you have any later models to test?  If later models / versions<br>
don't mind the RTP Payload (non-type-2), we can jusy simply always use that.<br></blockquote><div><br>I tested with a later version othe 139 software and including the RTP payload type IE works fine. I don't have any other units (EDGE ones) so I can't test. But I just posted the patch so someone could test ...<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> For GSM FR the RFC specifies PT=3 but for HR/EFR/AMR, they are dynamic and<br>
> must be chosed in the 96-127 range.<br>
> AFAIK, we could just use a static mapping in openbsc or load that from the<br>
> config. Does anyone sees a downside to that ?<br>
<br>
</div>static mapping is fine with me, patches welcome.<br></blockquote><div><br>Patch sent  on the ML.<br><br>    Sylvain<br></div></div>