
| Key: |
XCF-1380
|
| Type: |
New Feature
|
| Status: |
Open
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Scott Lawrence
|
| Votes: |
0
|
| Watchers: |
0
|
|
Available Workflow Actions
|
|
If you were logged in you would be able to see more operations.
|
|
|
sipXconfig
Created: 2006-11-20 11:41
Updated: 2007-06-19 08:50
|
|
| Component/s: |
dial plan
|
| Affects Version/s: |
None
|
| Fix Version/s: |
None
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
|
If internal numbers can match one or more of the patterns for external numbers, it is possible to dial out through a gateway and have the PSTN return the call; this results in tying up two external lines (and presumably paying for two calls).
For example, suppose that my company has direct dial numbers
9785552xxx for any xxx
and I have configured an external dial rule that sends any call with either 1 or 91 followed by 10 digits to my gateway. If an internal user dials 919785552111, then it will not match the registration of the phone at 9785552111, so external (fallback) rules will apply, and the call will be sent to the gateway. The PSTN will then route that call back to me as an incoming call.
To prevent this, there should be a way to configure internal numbers (or blocks). Then the dial plans for any external rules should be checked for overlap - check whether or not any external rule would match the internal number if the external prefix were added. If such a rule is found, then an internal rule should be added to remove those digits. For the example above, the rule would be:
<userMatch>
<userPattern>919785552xxx</userPattern>
<userPattern>19785552xxx</userPattern>
<permissionMatch>
<transform>
<user>9785552{vdigits}</user>
</...
Because this rule would match, our example call would be remapped to the internal number without the 91 prefix; since some internal mapping matched, the external rules would not be used. The call would spiral, and this time it would match the internal number and be made as a SIP call directly to the internal phone (and forwarded according to the rules for that phone).
|
|
Description
|
If internal numbers can match one or more of the patterns for external numbers, it is possible to dial out through a gateway and have the PSTN return the call; this results in tying up two external lines (and presumably paying for two calls).
For example, suppose that my company has direct dial numbers
9785552xxx for any xxx
and I have configured an external dial rule that sends any call with either 1 or 91 followed by 10 digits to my gateway. If an internal user dials 919785552111, then it will not match the registration of the phone at 9785552111, so external (fallback) rules will apply, and the call will be sent to the gateway. The PSTN will then route that call back to me as an incoming call.
To prevent this, there should be a way to configure internal numbers (or blocks). Then the dial plans for any external rules should be checked for overlap - check whether or not any external rule would match the internal number if the external prefix were added. If such a rule is found, then an internal rule should be added to remove those digits. For the example above, the rule would be:
<userMatch>
<userPattern>919785552xxx</userPattern>
<userPattern>19785552xxx</userPattern>
<permissionMatch>
<transform>
<user>9785552{vdigits}</user>
</...
Because this rule would match, our example call would be remapped to the internal number without the 91 prefix; since some internal mapping matched, the external rules would not be used. The call would spiral, and this time it would match the internal number and be made as a SIP call directly to the internal phone (and forwarded according to the rules for that phone).
|
Show » |
|
The way I understand id what Scott is asking for is sipXconfig to analyze all external rules and all internal numbers and extensions and come up with a set of mapping rules that would prevent routing calls externally if the dialed number matches internal extension. This is quite a difficult task. And since adding new users and adding new dial rules are not in any way synchronized it might be hard to provide a natural UI for that.