Hi,
.
I was hoping to get guidence on the best practices with 'hunt lists', 'ring groups' etc..
.
For example with our hunt lists we created the 'hunt list', then a 'feature code' that points at the hunt list, then configure the 'inbound route' to go to the 'feature code'. Looking back I am not really sure why I configured them this way, I think it was so they were accessible internally.
.
I also use a custom queue and ring-group scripts for a few of our inbound numbers, but with these I have not bother with the 'feature code' and instead call the script directly within the 'inbound route'.
.
Their are multiple ways and places to do almost everything, I know it will probably come down to person preference, but is their a preferred or industry standard method; as in always use feature codes?
.
Thanks
Allister
script so instead of 5 identical inbound routes
Erik,
> Ive got a few customers who are defining multiple DIDs to perform the same actions, and when
> they make a change they have to do it for 5 DID's. I am probably going to write some very
> simple Goto script so instead of 5 identical inbound routes, they can define 1 inbound route and
> have the other DIDs do a Goto for them, keeping a simple change, well, simple.
We have the same what I call a problem, or royal pain in the butt.. I'd love to discuss in more detail about geting this option added as a default to MTE.
your thoughts Alex..?
George
Inbound route best practices
I think that feature codes should be used for all the functionality. I prefer "tl-goto-featurextension" approach over invoking other scripts directly from inbound route, but unfortunately we can not enforce this because many scripts were marked as "allowed to be used in inbound routes" and changing that will break backward comatibility.
If you would like to enforce the goto approach with your users you can "unmark" all the scripts you don't want to be used in inbound routes.
Best regards,
Alex
I was heading the feature
I was heading the feature code direction and consulting the forum backed that up.
Regards
Allister
its the scheduling thats the
its the scheduling thats the problem..
I would love a Goto to handle this...
exten => +15025551212,1,Set(DIALED_PUBLIC_NUMBER=${EXTEN})
exten => +15025551212,2,Set(DIALED_NUMBER=${EXTEN})
... more code
exten => +15025551212,13,GotoIfTime(7:00-20:59|mon-fri|*|*?from-outside-+15025551212-normalopen-bgn|+15025551212|1)
exten => +15025551212,14,GotoIfTime(10:00-17:59|sat|*|*?from-outside-+15025551212-normalopen-bgn|+15025551212|1)
exten => +15025551212,15,GotoIfTime(10:00-17:59|sun|*|*?from-outside-+15025551212-normalopen-bgn|+15025551212|1)
... more code
exten => +15025551212,25,GotoIfTime(18:00-23:59|sun|*|*?from-outside-+15025551212-normalclosed-bgn|+15025551212|1)
instead of having to setup another bunch of schedules for a number you want to do the exact same thing (and maintain it when you change a behavior), it would be great if we could just point a second number to that script.
exten => +18005551212,1,Goto(+15025551212,1)
bam! I just saved 25 lines of code. AND.. when I make changes to the +15025551212 route all the other numbers automatically work. This is very common when someone has a few numbers that used to just point to their main number (like toll free etc). In single tenant it would be a snap to make this script, but in MTE I would need a pulldown to select a DID to ensure only DIDs owned by the tenant could be declared.
I would need a pulldown
>> I would need a pulldown to select a DID to ensure only DIDs owned by the tenant could be declared.
this is what we have requested and would be perfect for taking care of multible DID's for a customer.
George
Script for DID rerouting
Ok, I think we should make a script for this.
Here is a question I would like to get feedback on.
I can either 1) make a special "DID" argument type for the scripts that will display a dropdown with only the customer's DIDs 2) allow the number to be simply entered in the script as text.
In the second case there is not going to be any checking of who the number belongs to and whether it is correct, but I don't think that should be a big problem.
n fact I like the second approach better as it is more flexible, and it will be easier to implement. It will also be consistent for single tenant where otherwise things will be complicated as there is no DIDs and I would have to populate the dropdown with (already defined) inbound routes and exclude patterns, etc.
Any suggestions?
Alex
Script for DID rerouting
Hi Alex,
personally I like option 1
>> 1) make a special "DID" argument type for the scripts that will display a dropdown with only the customer's DIDs
since we are Multi Tenant and I would think the same would apply with a single tenant the simpler you make it for the customer to understand the better.
while "we here" wouldn't have a major problem with option 2 I think it would be problematic for the customer and if something is not entered in exactly correct breaking the routes.
So the simpler the better option 1
George
the only 'downside' i can think of in defining an inbound route directly to a script or ring group, aside from not being able to call it directly from inside, is consistency. If you are sending an inbound route to a script, and a feature code to a script (lets say a queue) and you don't set the argument variables identically (lets say you forgot to set the prepend callerid name field on one) they wont show up exactly the same. And inversely if you have defined an action in two places, thats twice as many places you will have to update when a change needs to be made.
Its entirely a personal preference really. Ive got a few customers who are defining multiple DIDs to perform the same actions, and when they make a change they have to do it for 5 DID's. I am probably going to write some very simple Goto script so instead of 5 identical inbound routes, they can define 1 inbound route and have the other DIDs do a Goto for them, keeping a simple change, well, simple.