1. I have a customer who had a IVR on his own side, (Session:C) and requires input from Session:A. The weird thing is that it seems the input is wrong. Keys entered do not correspond to what his IVR is receiving. As if newly dtmfs are generated somewhere. When I switch to another inbound provider, making Session:A using rfc2388 and not inband, but do dialout via the provider using inband detection. It seems to work fine.
start_dtmf adds a media bug that detects dtmf tones in the audio and generates the out of band rfc2833 messages. It's doesn't remove the inband ones though. If the receiving end accepts both it'll detect duplicated digits. This may be your issue. You may also be generating duplicate rfc2833 yourself if them sender is already sending both. You should only use start_dtmf if the sender only sends inband and receiver only accepts outofband. It'll also have to decode all audio and examine the audio to detect tones - so running it only when required also decreases server load. -Steve Sent from my iPad On 31 May 2012, at 18:16, JRichey <jrichey@itltd.net> wrote:
1. I have a customer who had a IVR on his own side, (Session:C) and requires input from Session:A. The weird thing is that it seems the input is wrong. Keys entered do not correspond to what his IVR is receiving. As if newly dtmfs are generated somewhere. When I switch to another inbound provider, making Session:A using rfc2388 and not inband, but do dialout via the provider using inband detection. It seems to work fine.