DTMF "Transcoding"?

Asterisk Asterisk Support
1

Hello all, hope you all had a great Thanksgiving!

I was wondering, does Asterisk do DTMF “transcoding”? So what I mean is that I have:

  1. Peer A dtmf mode = info
  2. Peer B dtmf mode = rfc2833

So when an inbound call comes in from Peer A, I:

  1. Answer()
  2. Read, and get the destination number (in this case get dtmf via SIP INFO)
  3. Send the call out to Peere B (which is rfc2833)

But it seems when the call gets sent out to Peer B, the dtmf is trying to negotiate INFO which Peer B device not have.

So by defining rfc2833 in Peer B, it doesn’t seem to work. DTMF seems dictate by what Peer A (inbound) initially setup as.

Is there anyway to have Asterisk “transcode” from INFO from Peer A and then sent out as RFC2833 on Peer B?

Thank you!

2

Asterisk will do DTMF transcoding even when it doesn’t need to. Unless it is able to create a native bridge, it will decode the DTMF, pass it as AST_CONTROL_DTMF messages, and re-encode on the other leg.

Your example doesn’t require any DTMF transcoding, as no DTMF is sent to B in the media stream.

Are you saying that Asterisk is not offering telephony events in its SDP offer to B?

I would note that this case should be rare these days, as all current equipment uses 2833 (or rather its successor).

3

Well, I found some other way which may resolve my issue. But yes, it seems that if I do SIP INFO in “A” leg, when it sent the call to “B” leg, it only will have SIP INFO in dtmf negotiation which if the “B” leg device do not have SIP INFO, call would fail. What I thought that Asterisk would convert it to RFC2833 and also in the SIP invite to have RFC2833 (instead of the original SIP INFO) in the DTMF negotiation list.

But it seems it is just passing SIP INFO to far end which caused the call fail.

4

You are going to have to provide the evidence, i.e.g the SP traces.