incoming calls to ivr via-sip: external calls work, internal calls don't

[wMitel]

we recently purchased sip licesnses for a trial version of an IVR system. and so far it works...for external incoming calls only.

here's i think is what's happening on external calls (please forgive me if i explain this erroneously, i am new to this):
- external calls come from our pri
- call is handled by the 3300 controller (10.100.100.xxx) and calls the IVR (10.1.1.xxx)
- mitel controller and IVR are now talking and understanding each other. we can hear the IVR test message. we send DTMF tones, and IVR recognizes it.

here's what i think is happening on internal calls
- internal 5320 phone (10.100.xxx.xxx) dials 4-digits
- 3300 controller sees that the caller and the callee is on the same network, connects both directly to each other
- they don't understand each other. we get dead air on the 5320 phone. we try to send DTMF tones, IVR doesn't understand it.

question:
am i correct to assume this is what's hapening?
is there any way to route a single phone (internal extension) calls to 3300 controller or in other words make it act like it's an external call?

disclaimer:
i am not a real phone guy and definitely not a network guy. i'm just the guy that knows a little bit of something. i'm also the guy that really needs major help. please help. thanks in advance.

 

[LoopyLou]

You are mostly correct. The calls come into your office on the PRI. The 3300 controller converts the call to IP and handles setting up the call to the IVR platform. The 3300 then produces all the necessary tones etc to complete the callers choices as well as converting the audio from the IVR back to TDM for the caller. obviously there is no issue communicating between the 3300 and the IVR.

On an internal call the 5320 dials the ext number of the hunt group of the ports to the IVR. The 3300 handles the setup of the call to the IVR using SIP and tells the 5320 the IP address of the IVR port it is connected to . The 5320 then directly communicates with the IVR. There should be no issue with doing this as its all RTP packets at this point. SIP signalling is purely for call setup, tear down and features like transfering. You should at least get audio so I suspect there is some issue with routing between the subnet the phone is on and the one the IVR is on.

One other point. You don't say whether the IVR uses SIP trunks or SIP users to connect to the 3300.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[gib1506]

You will need to get a Sip trace of 3300 or a Wireshark trace ,two issues it could be .Port issue on Firewall (if one in Place) or codec that is been used .You may still have the DTMF issue as it depends on what Payload is been used for sending the DTMF. All these will be show in the SDP Packets

 

[LoopyLou]

agreed gib1506. A way to test also is putting a phone on the same layer 2 as the IVR ( and in the same subnet ). This elimates the possibility of routing or firewalls causing the issue.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.