Difference between revisions of "Inbound Routes"
Line 1: | Line 1: | ||
'''Menu: (Dialplan-Inbound Routes)''' | '''Menu: (Dialplan-Inbound Routes)''' | ||
− | Directs public inbound calls to an internal destination on the system.<br/> | + | Directs public inbound calls to an internal destination on the system.<br/> Note that the only difference between the inbound route dial plan and the normal dial plan is that the inbound route dial plan works on all calls that are in the public context whereas the normal dial plan works on the default context. <br/> |
*Inbound Call Routing is used to route incoming calls to destinations based on one or more conditions and context. It can send incoming calls to an auto attendant, huntgroup, extension, external number, or a script. Order is important when an anti-action is used or when there are multiple conditions that match. | *Inbound Call Routing is used to route incoming calls to destinations based on one or more conditions and context. It can send incoming calls to an auto attendant, huntgroup, extension, external number, or a script. Order is important when an anti-action is used or when there are multiple conditions that match. | ||
Revision as of 01:15, 14 April 2011
Menu: (Dialplan-Inbound Routes)
Directs public inbound calls to an internal destination on the system.
Note that the only difference between the inbound route dial plan and the normal dial plan is that the inbound route dial plan works on all calls that are in the public context whereas the normal dial plan works on the default context.
- Inbound Call Routing is used to route incoming calls to destinations based on one or more conditions and context. It can send incoming calls to an auto attendant, huntgroup, extension, external number, or a script. Order is important when an anti-action is used or when there are multiple conditions that match.
ADD inbound route
Name: Condition 1: Field: Expression: Condition 2: Field: Expression: Action 1: Action 2: Order: Enabled: Description:
Modifying CID on Inbound Routes
You can use this to perpend data onto caller ID. For example: A company has multiple numbers but wants to be able to tell the difference between an emergency call and a regular call.
Setting up in FusionPBX - keep in mind this will probably have to go after the context and before the transfer.
Name: Priority Inbound Condition 1 - Field: destination_number Expression: ^12345551234$ Action 1: set Data: effective_caller_id=EMERGENCY ${caller_id_name}
The XML is as follows:
<action application="set" data="effective_caller_id_name=EMERGENCY ${caller_id_name}"/>
So, if John Smith calls into the number 12345551234 with a huge emergency, the caller ID would show up as
EMERGENCY John Smith
- Some phones truncate CID names after a certain character limit.
Creating a catch all inbound route
To create a catch all inbound route, remove the destination_number condition. Then there is one condition remaining and that is the one that makes sure its the public context - this is a condition included for all inbound routes (you don't ever see this condition). To use your new catch all rule, make sure it has the highest order number so it is the last to process - this will allow you to have specific rules processed before it and this will then truly function as a catch all - only processing calls that don't match any of the earlier rules