IVR and SIP trunks ??

[TipandRingtoSIP]

HI,
So I have an existing IVR that is connected to my OS4000 with sip trunks. Users dial an extension number, and it goes to the IVR and everything works great.. This was installed about 10 months ago and more or less works as designed. The folks that handle the IVR application have a secondary server or backup IVR that they just noticed, never receives any calls. Well, yeah? I only have one trunk group, with one access number. So my question, or I should say questions to those who may know: Can I somehow get calls for this trunk group to target 2 seperate IVR's? Would I need to add additional SIP trunks to the existing trunk group, and then create a new GKREG entry with the second servers IP and add it to the call route in the GW-2 field ? Could I just add the GKREG entry in the GW-2 for the route without adding SIP trunks, and it would use the existing trunks if the first server failed? The IVR people want the calls to be distributed between the 2 servers, which to me seems like cannot be done from the OS4K side... Anyone have any thoughts on this?? Thanks in advance..
Bruce

 

[sbcsu]

You could keep all the trunks going to the IVR in the one trunk group.
Then just change the route to circular to pickup one channel in a circle.
In the relevant TDCSU's you will see SRCHMODE
Change that to whatever suits (put in a question mark for SRCHMODE - CHA-TDCSUEN=X-X-X-X,SRCHMODE=? )

 

[Moriendi]

He's asking about a 2nd IP address reachable via existing TDCSU to STMI.

If you add another GKREG entry then yes, you can target the 2nd IVR. The LDAT can be adjusted to contain both GW numbers, say 1-0 and 2-0, or you can have a 2nd LDAT, and put 1-0 in the first LDAT and 2-0 in the 2nd LDAT. You can't make it choose 121212 to cycle between IVR's. It would step to 2nd choice when either first choice is busy or unreachable.

GKREG is no longer a supported method of config. SIP profiles should be used on the STMI instead, where you browse to the card and configure target in the GUI. Cannot configure target destinations like you can in GKREG though, so you have to either buy another STMI to use for 2nd destination, or configure a DNS SRV entry as target instead of fixed IP.

GKREG will work with 2 entries if it's working OK with 1 now.

 

[sbcsu]

Apologies - yes you are correct "Can I somehow get calls for this trunk group to target 2 seperate IVR's? " - I missed that line....

 

[TipandRingtoSIP]

So the part that I am missing is this: I currently have 24 trunks configured in my trunk group. What is it that ties those 24 channels to the IVR at the other end?. If I have a second IVR, do I need to configure another 24 channels? Are the existing 24 channels in a pool of available channels, and will route to the 2nd server via GKREG? That's where I'm hung up.

Edited:
I wrote the above prior to seeing Moriendi's response.But yes, that is what I was trying to do, route calls to the second server via the same trunk group. It is working now with the first gateway. I created a GKREG entry for the 2nd IVR and added it in LDAT, but it did not seem to work. May need them to reset the line card, it's been sitting for months with no traffic...So the SIP trunks in the trunk group would act like a pool of channels to be used to connect with either of the 2 listed gateways? Correct?

 

[Moriendi]

Run wireshark on the 2nd IVR and filter on port 5060. You'll see if anything hits the box from the STMI. There is a timer where 4K will not invite to a gateway destination if there has been no response, ctime cp2, gwnavail. But it's short, seconds. Then it will try again for next call when timer has expired. It won't deliver calls cyclically to the IVR's though. Removing LAN cable from IVR 1 would be a good test, but only once you confirm SIP traffic to IVR 2 with wireshark. Or, if you created another LDAT LRTEL,(2), swap over LRTEL 1 & 2..

 

[TipandRingtoSIP]

Oh, now I see. Add a second route element in the existing route with the second gateway as GW-1. I'll have them run wireshark on the second IVR while we place calls... Thanks!