We are integrating with a cloud based contact centre system and it sends Opus, PCMA, PCMU as offered codecs in that order. HMP doesn't know what Opus is - which is fine. It negotiates PCMA but something odd happens with the DTMF payload negotiation but I can kind-of work around it (see offer/answer SDP's below for details). It chooses the first DTMF payload type 101 which has a declared rate of 48000, but responds with 101 but with the rate 8000. Payload type 102 with a declared rate of 8000 is ignored. The other issue is that it duplicates a= lines in the response SDP which can cause some endpoints to reject the SIP (like Cisco CUBE is known to do).
In my view, the RFC 2833 (RFC 4733) payload type rate in an SDP response should be matched to the rate of the codec its being used with. PCMA is 8000 by default. Opus is declared in the SDP to be 48000/2. I'm not entirely sure whether its legal to change the rate of a specific offered RFC 2833 payload type like that but it stops DTMF from working in my testing (it appears that the source of the call doesnt like it).
I'm using HMP 3.0WIN SU372 (the latest at the time of writing) and using first party call control. This is a plain offer/answer without insertion of parameters to alter the HMP SIP stack operation (i.e. entirely automatic).
Offered call SDP (note that the 96 in the m= line is the Opus codec and the rate for opus is 48000):
Response SDP from HMP (wrong because the a=rtpmap line has had its rate changed from 48000 to 8000 and it has duplicated a pair of a= lines):