More outbound route issues ...

[mrdom]

Hi everybody: In the final phases of testing now, and I came across another issue today ... the system is not doing what I would expect it would do.

I have an outbound route set up for each of my lines. Lines 5 and 6 are for system outdialing. Both routes are set up the same. In my routing I have the lines set up in the order I want to have them accessed when users make outgoing calls:

Line 2
Line 4
Line 3
Line 1
Line 5
Line 6

For lines 5 & 6, I have a prefix of *50 set for both lines to force the system to choose either line 5 or 6 for outdialing calls.

I have an option (1) set up in the IVR to transfer the call to a cellular phone if a user presses that number.

So I called into the system on Line 5. I pressed 1, and expected the call to ring on my cell phone with Line 6. Instead, I got the recording that said "all circuits are busy now".

In the order above, the system would obviously know Line 5 is busy and can't complete the call on that line, but why didn't it then look to Line 6 which was idle? It's got the same prefix and dial pattern set up ... not sure why this didn't work.

I'm fearful that when users are utilizing the regular lines and one is busy, it won't go to the next idle line to place the call (they'll get the same all circuits busy message).

I tried to switch Lines 5 and 6 in the order (so they appeared as lines 6 and line 5 in the order). Then it worked fine.

I'm stumped, though, as to why it wouldn't complete the call with the order of 5 & 6. We'll have a few users outdialing, so I want to get this working properly.



Thanks for the help!

 

[theislandtech]

So, you have an IVR that when you press 1 it dials *50NxxNxxxxxx# and a route with the dial pattern
prepend + *50 | NxxNxxxxxx and if there is a match it uses Trunk Sequence
0 = Line5
1 = Line6
If that is correct then when Line5 is busy the next trunk in the sequence should be used

 

[mrdom]

Thanks islandtech. Yes, I've got option 1 in the IVR set to a Miscellaneous Destination, which dials *50NXNXXXXXXX. Interestingly enough, if I put the # at the end of the number, the call won't go through ... the system hangs up. But if I leave the # off, the call goes through.

I'm not using trunk sequencing though. I have two different routes programmed for each line for the purpose of shared line appearance. I need the phone's indicator to show that the line is in use. So, I have two outbound routes set up ... one has scg5 and one has scg6 (for shared line appearance). They're set up exactly the same way though.

If there's a route open that has the pattern programmed, why won't the system select it?

Maybe there's a way to use trunk sequencing and achieve shared line appearance a different way?

Thanks for the help.

 

[mrdom]

OK ... after a little experimenting, this is what I found:

I CAN use trunk sequencing and use one route and achieve the desired outbound results if I go into phone programming and change my line programming to be:

SCA:1@SCG5
SCA:2@SCG5

If I do this, then the calls go through and the buttons light up as expected.

I went into my inbound routes and modified the SCG to be SCG5 for both lines 5 and 6. Now my incoming calls don't work. If I call Line 5, the light illumines next to the button as it should. If I call Line 6, the light next to Line 5 illumines.

So that doesn't really work either ...

I'm trying to get my inbound and outbound calls to light up the right buttons when calls come in and calls go out. I don't know any other way other than to set up one route for each line (inbound and outbound). With the way I had it set up above, there's a route that can handle the call ... why won't the system move to line 6 instead of saying "all circuits are busy now" ... I'm stumped on that one ...

 

[theislandtech]

Didn't know you were using Misc Dest. The # is not needed at the end of the dial string in that case.
If you could post all your trunk, inbound, and outbound routes might be helpful as I have lost track of your configuration due to experimentation.
On outbound routes, priority plays a part. The top right corner of the outbound route page has a list of your routes. You can click on the arrow to move the route up or down in priority . The route chosen is based a first match. If you have 2 routes the same the call will hit the first route matching your dial pattern and if it is busy the call will fail - all circuits are busy now. One route with 2 trunks the call should fall over to the next in sequence if the first is busy.
The Shared Call Tag is used for grouping and an indication on the phones only and not for routing.

 

[mrdom]

[pre]
Thanks, Islandtech, for the continued help. Here's what I have:

TRUNKS (SIP CONNECTED VIA GRANDSTREAM):

==========================
1. LINE 1 1-XXX-XXX-XXXX
==========================
Outbound Caller ID: 1-XXX-XXX-XXXX
Dialed Number Manipulation Rules : None set
Trunk Name: LINE1-XXXXXXXXXX (matches GrandStream)
PEER Details:
host=XXX.XX.X.XX
type=friend
qualify=yes
insecure=invite
context=from-trunk
port=5060
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=ulaw

There are a total of 6 trunks. They're all set up the same way, except the port= is 5062, 5064, 5068, 5070, 5072. Trunk name matches each trunk that's in the GrandStream.

INBOUND ROUTES

==========================
1. LINE 1 1-XXX-XXX-XXXX
==========================

DID Number: 1-XXX-XXX-XXXX
Caller ID Number: blank (nothing entered)
Alert Info: blank (nothing entered)
CID Name Prefix: blank (nothing entered)
Shared Calls Tag: SCG1, SCG2, SCG3, SCG4, SCG5, SCG6 (for each inbound route)
Destination: Time Conditions / 01-MainSchedule (Lines 1-4)
Line 5: Misc. Destination / VMSubscriber
Line 6: Misc. Destination / VMSubscriber

There are a total of six routes (one for each line). They're all configured the same way, except each line has its own SCG, and the last two lines have different destinations.

OUTBOUND ROUTES

I have one outbound route set up for each line. I have them listed in the order I want users to access them:

Position 1: LINE 2
Position 2: LINE 4
Position 3: Line 1
Position 4: Line 3

Each of these routes have the following dial patterns:

(prepend) + prefix | [011./CallerID]
(prepend) + prefix | [1NXXNXXXXXX/CallerID]
(prepend) + prefix | [N11/CallerID]
(prepend) + prefix | [NXXXXXX/CallerID]
(prepend) + prefix | [match pattern/CallerID]

For the shared call group, I have:

SCG1 for Line 1, SCG2 for Line 2, SCG 3 for Line 3, SCG4 for Line 4

For lines 5 and 6 (the outdial routes), I have them listed as:
Position 5: Line 5
Position 6: Line 6

These two routes have the following dial pattern:

(prepend) + *50 | [NXXNXXXXXX/CallerID]

If I make a call, the call will go through, but if I try to make a second call, I get the "all circuits are busy now". My thinking was that if a line was busy, the system would try the next route and match the patter there. It's obviously not doing that, though, and it gives up after looking at only one route.

I could do trunk sequencing, but I have no idea how to make my line buttons light up next to the appropriate line if I don't have a SCG tag that's unique. Whatever the SCG should be, it has to match what's in the inbound routes and what I have programmed for my line buttons, because if they're different, the lines won't light up next to the correct buttons. This is where I'm having the problem.

Thanks for your continued help!

[/pre]

 

[theislandtech]

Routes provide access only to trunks(lines). A route that has a dial pattern of prepend + *50 | NXXNXXXXXX and only 1 analog trunk/line will allow only 1 call.
A second route with same dial patterns as above does nothing. Since the second call will match on the first routes dial pattern and it only has 1 trunk therefore the second call will fail.
You can add Line 6 in the trunk sequence of the above route.
Program that outbound route with the Shared Call Tag of SCG5.
Program the phone buttons with SCA:1@SGC5 and SCA:2@SCG5 to indicate usage.

Outgoing calls are completed by:
the first route that matches the dial pattern
which will send the call to the trunk
if no available trunk then (congestion) the recording "all circuits are busy at this time" will play.

 

[mrdom]

OK ... that makes sense, and that's what I tried last night. That works OK.

But what do I do about the incoming calls? I tried setting both incoming routes to SCG5 as well, but it didn't work. When a call comes in for Line 5, it illumines the correct light. But if I try to call Line 6, the light next to Line 5 illumines.

If I set up the outbound routes as you suggested, then I'd only need two. My first route would be for dialing out from system users. I would put all of my trunks in there in the order I want them accessed (Lines 1-4), and then assign SCGUSER as the shared call group. On the buttons, I'd program them to be:
SCA:1@SGUSER
SCA:2@SGUSER
SCA:3@SGUSER
SCA:4@SGUSER

For system outdial, I'd have the second outbound route programmed with my prefix and dial pattern. I'd assign lines 5 and 6 to this route and assign SCOUTDIAL as the shared call group. On the buttons, I'd program them to be:
SCA:1@SCOUTDIAL
SCA:2@SCOUTDIAL

So if I have my outbound routes set like the above, do I need to remove all of my individiaul inbound routes and only have two of these as well? I'd need two routes here though ... one for lines 1-4 to go to the ring group/IVR and one for Lines 5 & 6 to go to voice mail subscriber service. But I'm not sure how to do this. I'm assuming I'd need to modify the GrandStream in some way as well. We're getting there!

 

[theislandtech]

Only 2 outbound routes are needed. 1 outbound route for lines 1-4 tagged SCGUSER and 1 outbound route for lines 5-6 tagged SCGOUTDIAL.
Does each line ring to the correct destination now?
If so, leave the inbound routes as is but change the Shared Call tag in each route for lines 1-4 to SCGUSER and for lines 5-6 to SCGOUTDIAL.
Program the buttons as needed. Lines 1-4 SCA:1@SCGUSER, SCA:2@SCGUSER, SCA:3@SCGUSER, SCA:4@SCGUSER
Lines 5-6 SCA:1@SCGOUTDIAL, SCA:2@SCGOUTDIAL

 

[mrdom]

OK ... I removed all the outbound routes except for two. For the user outdial route, I put all the lines in trunk sequence. I gave it the tag SCGUSER.

In the second outbound route, I put Lines 5 and 6 together in the trunk sequence. I gave it the tag SCGOUTDIAL.

For the inbound routes, I left them alone except for the shared calls tag. I put in the tag SCGUSER for Lines 1-4 and SCGOUTDIAL for Lines 5-6.

I updated one of my phones with the following line buttons

Line 1 = SCA:1@SCGUser
Line 2 = SCA:2@SCGUser
Line 3 = SCA:3@SCGUser
Line 4 = SCA:4@SCGUser
Line 5 = SCA:1@SCGOutdial
Line 6 = SCA:2@SCGOutdial

If I call in on Line 5 and press 1 to force the system to outdial, the call goes through and Line 6 lights up as it should.

But when I try to call in on Line 6, the icon next to Line 5 illumines. The icon next to Line 6 remains a -.

I'm wondering if I have to somehow combine the inbound routes too? Not sure ...

 

[theislandtech]

If line 5 is idle and a call comes in on line 6 it will light SCA:1@SCGOutdial since both line 5 & 6 are in the same inbound route. Did the call complete when you dialed in on line 6?

 

[engenius]

Hi Guys
I've been following this thread - very educational.
It is my understanding that the call coming into the shared call group
will always cascade down for example appearance 1 to 2 and so on.
That is why the call placed to line 6 in your example is hitting shared appearance position 5.

 

[mrdom]

Yes - when I called in to Line 6, the call did complete and the VM Subscriber service answered as expected. Line 5's indicator was illumined, however.

My users are used to seeing phone numbers as their line indicators. Since we have four lines, people calling in usually return the call to the line that they've got in their cellphones. If a caller returns a call to us using Line 3's phone number, but the call actually rings on Line 1's indicator button, that's going to be awfully confusing to people. That's why I started with assigning each Inbound Route with its own shared call tag ... if I do that, then when someone calls in on Line 3, Line 3's indicator blinks.

Is there no way to set up the lines so that the indicators light up the correct trunk for both incoming and outgoing calls?

You have been so great islandtech - thanks for all the help you've provided thus far.

 

[theislandtech]

The UCX is not like a Key System, although SCA comes close to emulating one.
Are lines 1-4 in a hunt group(rollover) from your provider? If not maybe you can have them set it up with all lines having the caller id of the pilot number(line 1). If they are already hunting then ask for them to have the same caller id of line 1 for all members.
Thus your customer will receive line 1 caller id on their phones. When they return the call to line 1 if busy will rollover to line 2 etc.
Another choice - program each line to its own inbound route with its own Shared Call tag (sort of like you had). Create outbound routes for each line based on some kind of prefix to access the desired line.
Or another choice - Port line 1 to a SIP provider with multiple channels and drop the other three analog lines. You could keep line 5 & 6 analog or port line 5 & 6. If line 5&6 are relatively new drop them and get DID's from the SIP provider.

 

[mrdom]

Yep - you're right, islandtech, and I was thinking exactly what you typed when I posted the last message. I am totally a key system user, and think along those lines. I guess in the scheme of things, it doesn't totally matter what line the calls are going out on. Lines 1-4 do hunt, so I guess I can rename the lines "line 1" "line 2" "line 3" etc. My users don't necessarily need to know what trunk they're using ... just as long as they can access them from other extensions, and we figured out that this is possible.

It's a shame that the UCx won't look at all outbound routes when trying to place an outgoing call. While I understand that if it finds a match and the trunk is busy, the call will die ... but it would sure be nice to have the system check the other routes established to see if there's a pattern match on another route with an idle trunk. If this worked, then I could match my shared call groups between inbound and outbound routes, and it would function more like a key system.

Soooooooooooooo ... to end all things, it really wasn't a problem - I was just trying to attempt something that the system wasn't designed for. I think that's been my problem in many of these posts. Alas, it's good to know nonetheless. I'm grateful to you, islandtech!

 

[ucxguy]

I think you're right that the capability you were looking for is actually missing due to a system design choice.

To implement shared call appearances, E-MetroTel could either implement SCA tags for trunks or for routes. If they went with trunks, an SCA key could show when the corresponding trunk is active - that would be good for small systems with let's say up to 8 trunks. E-MetroTel decided to use routes - and I think associating SCA tags with routes (inbound and outbound) provides more flexibility, which is important for bigger systems.

End users really don't need to know which channel of what trunk they are using. With SCA tags used for routes, you can have the same SCA programmable key on the user's phone to represent calls over different trunks (for example PRI trunks for the majority of calls, GSM gateway trunks for mobile, SIP trunks as an overflow, analog trunks as an emergency backup...). From the user's perspective, they dialed a number and they have the call on their "Line 1" button - there is no need for them to know that they are for example using a SIP overflow trunk.

 

[mrdom]

that's a great point, ucxguy. i remember working with a pbx several years ago, and you're right - didn't really care what line my calls went out on ... i never saw it anyway. as long as the lines appear and can be accessed from other extensions, that's really the mission-critical part that i need to be able to do, so i'll just change the line button labels to an actual name and not the trunk number, and we'll be fine. it'd be cool if emetrotel could incorporate both ideas and allow the end-user to choose how they'd like to tag - by trunk or by route. that's probably a lot of programming though, so i'll just be happy with what I've got.