CUBE with LTI - no audio on calls with in-band DTMF

[TONY SMITH]

Hi,

I'm not sure what's going on here.  Call path is ITSP->CUBE->CUCM.   The ITSP say they present DTMF either inband or as rtp-nte and this seems to depend on the origin.  With dial peers configured for rtp-nte then DTMF works OK, but where it's presented inband it does not work. 

I had thought that an LTI transcoder ought to resolve this, but what I have actually found is that with the LTI enabled I get no audio on the call with in-band DTMF.   "sh call act voice comp" shows the two expected call legs, one to phone and one to ITSP with G.711u on both legs in this case.   "sh dspfarm dsp act" shows that two channels are assigned with packets counting up.  However there is no audio, and the status screen on the answering phone shows both codecs as "none".

The only different in the signalling to CUCM that stands out is that the working call offers G711u and G729, whereas the non working call offers G711a as well, reflecting the codecs in the original invite from ITSP.  However in both cases CUCM pick G711u and the call connects on that basis.  The LTI profile includes all those codecs.

Inbound calls using rtp-nte don't invoke the LTI and work normally.

Any ideas?   Shutting down the LTI profile resolves the audio issue, but leaving the DTMF issue.

[Chris Deren]

Can you post your config?

Have you tried listing multiple DTMF methods on your inbound dial-peer from ITSP and outbound dial-peer to CUCM?  The  "dumf-relay" commend can take more than one DTMF method.

[TONY SMITH]

"The "dumf-relay" commend can take more than one DTMF method."

Some of the documentation suggests that a method of "none" should be available to indicate in-band.  However on this install (ISR4331 16.06.04) that doesn't seem to be available.  

I don't know if this is relevant, and I need to do a couple more tests but it looks as if the Invite CUBE->CUCM has a different IP address in the "From:" header, compared to good calls.  The calls that hit the LTI show the outside IP address of the CUBE, the address the ITSP dial peer is bound to.  Calls with LTI shutdown show the address of the inside interface, the address the CUCM facing dial peer is bound to.  Just that particular header differs, VIA and the SDP all show the correct address.

[Anthony Holloway]

I think the none, means literally, nothing configured. As that is the default setting.

Anyway, you could rule out the From header as the problem by implementing some SIP normalization at the outgoing dial-peer.

Something like:

voice class sip-profiles 1
 rule 1 request INVITE sip-header From modify "bad ip" "good ip"
!

EDIT: I have not yet needed to implement the LTI, so I wasn't aware of this, but a quick read through the docs tells me there's not interface to bind to, like there is with SCCP based transcoding. Huh.

[TONY SMITH]

Thanks.   I gave that profile at try, which corrected that particular header.  I'm not particularly surprised that it's not fixed the problem.

I guess if there's no obvious way a configuration issue could cause it fault, it may need TAC.

I'm still a bit puzzled that the CUBE->CUCM SDP negotiation all looks correct, but the phone shows codec as "none".  If it was a CUBE fault I've have expected the phone to look normal but just receive silence. (Edit, just had a look at SCCP traces and the SCCP media all seems to match the SIP signalling, addresses ports codec etc)