06-21-2013 07:18 AM - edited 03-18-2019 01:20 AM
Hello all,
I will be configuring next week an isdn gw 3241. I did some readig about it (user guide and other cisco docs).
In my implementation we hane an the isdn gw with 1 E1 (multiple DID). several video endpoints (VEP) will be using this isdn gw.
All IP VEP are registed to VCS.
I would like to configure it in this way:
IP to ISDN
Any IP VEP, when calling i.e 88XXXXXXX (88 is the isdn gw video prefix), the call will be routed to the ISDN GW.
ISDN to IP
if remote VEP call ISDN GW number +44335xxxx01, call get routed to IP VEP1
if remote VEP call ISDN GW number +44335xxxx02, call get routed to IP VEP2
if remote VEP call ISDN GW number +44335xxxx03, call get routed to IP VEP3
If other number from this range is dialed i.e +3245xxxx06, call to be rejected.
Can Anyone share some snapshots from an ISDN gw config with simlar rules and comment? Thanks in advance.
Regards,
Solved! Go to Solution.
06-22-2013 11:14 AM
Hi friend,
With regards toll fraud, I normally use a simple methodology that brings a nice security level without demanding a complex configuration. CPL is a nice option too, but it is too complex in certain environment, and it is hard to manage and troubleshoot in my opinion.
I normally limit the access to ISDN gateway through search rules alone. Try this:
Please, follow all instructions I mentioned above, it is so important.
If you have many PSTN access codes, you can create many search rules following this procedure, or you can use regex to summarize the the routes. For example, let's say you have 99, 98 and 97 as PSTN codes, your pattern string may be (99|98|97)\d*. This route will match any number whose prefix is 97 or 98 or 99.
Another important consideration is, if you have PSTN access codes (not having makes no sense), you must to design a dial plan which avoidsmismatch between your PSTN Access codes and your another alias and routes. It is extremely important! For example, following the suggestion I placed above, you should not have any endpoint whose alias starts in 9, because it would bring a conflict with your ISDN search rules.
Before making any configuration, save a time to think and plan. I would also suggest you to make several test after implementing your ISDN integration with toll fraud prevention.
I hope this to be helpfull.
Best Regards,
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-23-2013 01:27 AM
Thanks Paulo,
Very detailed explanation. That will for sure help me for this implementation.
I will give you my feed back asap.
Hi Ahmed, you are welcome!
There is another important thing to point here, I didn't mention it because you said you will use DID to receive calls from ISDN and not gateway's IVR.
Anyway, let me explain it better. If you receive calls from ISDN and you configure your gateway to route the calls to its internal IVR, the user from ISDN could use the IVR to redial to a another external ISDN number. The IVR on the gateway is very simple, it simply allows the user to dial any number, then the user can get connected into IVR and dial a PSTN number again, then gateway would route this number to VCS, and VCS would route this call back to the gateway. Therefore, it may also be a way to make toll fraud. External user could make a local call to your gateway and use your system to make an international call.
You can also prevent this by using search rules following the suggestion I posted above. It is very simple, do this:
Furthermore, you can also use the field "Request must to be authenticated" on search rule configuration. If you set it to "yes" as I mentioned before, only authenticated endpoints (or endpoints treated as authenticated) will be able to reach the rule. Then you can setup your desirable sub zones to whether "check credentials" (VCS will challenge the endpoint to authenticate) or to "treat as authenticated" (VCS will mark the endpoints as authenticated without challenging authentication). Therefore, only desirable endpoints will be able to dial PSTN numbers.
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-21-2013 08:30 AM
It is quite dependent on how you want to deploy your setup (like how how to integrate with your
existing dialplan, using e164 numbers or enum, how the isdn numbers are send and have to be
received from your isdn provider, ...
Like you most likely are able to dial +44 from your mobile phone but not from your isdn line and
you will most likely also not get +44 as the source or destination number from your isdn provider.
Also keep in mind that you need to do some security considerations to not end up as a free
voice gateway, ....
Please remember to rate helpful responses and identify
06-21-2013 12:24 PM
yes, security is very important here. make sure you close the loop hole of calling into ISDN gw (local call) and going through VCS and back to ISDN gw (international call).
06-22-2013 08:25 AM
Thanks Martin, Thanks Ahmad.
I found on VCTalk website few snapshots + the cisco user guide that hepled my understanding how to implement the dial plan for the isdn gateway. I will need to discuss with customer how he want to use the isdn gateway.
Thanks for bringing to my attention the security aspect. I found a thread about this: https://supportforums.cisco.com/thread/2141248 . I will go through it and try to understand and implement the solution in away to block any toll fraud on this gateway. If you have any advise or other comments please add it.
I will add some snapshots after the implemention so it may helps other in the future.
Ahmed
06-22-2013 10:06 AM
To stop the toll fraud you need to secure your VCS routing since calls coming and going out from this sever. There are many ways to do that. one way would be to use CPL script. To implement the script, more information regarding zones and dialplan is requied. But I would reveal sensitive info regarding dialplan here. you are better off to open TAC case and get help from TAC.
regards,
Ahmad
06-22-2013 11:14 AM
Hi friend,
With regards toll fraud, I normally use a simple methodology that brings a nice security level without demanding a complex configuration. CPL is a nice option too, but it is too complex in certain environment, and it is hard to manage and troubleshoot in my opinion.
I normally limit the access to ISDN gateway through search rules alone. Try this:
Please, follow all instructions I mentioned above, it is so important.
If you have many PSTN access codes, you can create many search rules following this procedure, or you can use regex to summarize the the routes. For example, let's say you have 99, 98 and 97 as PSTN codes, your pattern string may be (99|98|97)\d*. This route will match any number whose prefix is 97 or 98 or 99.
Another important consideration is, if you have PSTN access codes (not having makes no sense), you must to design a dial plan which avoidsmismatch between your PSTN Access codes and your another alias and routes. It is extremely important! For example, following the suggestion I placed above, you should not have any endpoint whose alias starts in 9, because it would bring a conflict with your ISDN search rules.
Before making any configuration, save a time to think and plan. I would also suggest you to make several test after implementing your ISDN integration with toll fraud prevention.
I hope this to be helpfull.
Best Regards,
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-22-2013 03:01 PM
Thanks Paulo,
Very detailed explanation. That will for sure help me for this implementation.
I will give you my feed back asap.
Best regards,
Ahmed
06-22-2013 11:11 PM
Hi Ahmed,
A single rule in searchrule is not enough to prevent toll fraud. As I suggested before, please seek help from TAC.
regards, Ahmad
06-23-2013 01:24 AM
Hi Ahmed,
A single rule in searchrule is not enough to prevent toll fraud. As I suggested before, please seek help from TAC.
Hi Ahmad,
Single search rule? Did you even read all the explantion I posted? What I posted was just an example, which involves search rules, sub zones and authentication, that's why I suggested Ahmed to save a time to plan, design and test a solution. The point here is, you CAN prevent toll fraud by using search rules alone.
I really didn't understand what you mean. Why do you think is not possible to prevent toll fraud by using search rules? Sorry man, but I am not getting your point.
See this topic about the same matter.
https://supportforums.cisco.com/thread/2141248
Read the right answer, the guy is suggesting to use search rules and sub zones to restrict calls from internet to get routed to ISDN gateway, just like I did here.
Now I am very curious to know what you mean, please, let me know.
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-23-2013 01:27 AM
Thanks Paulo,
Very detailed explanation. That will for sure help me for this implementation.
I will give you my feed back asap.
Hi Ahmed, you are welcome!
There is another important thing to point here, I didn't mention it because you said you will use DID to receive calls from ISDN and not gateway's IVR.
Anyway, let me explain it better. If you receive calls from ISDN and you configure your gateway to route the calls to its internal IVR, the user from ISDN could use the IVR to redial to a another external ISDN number. The IVR on the gateway is very simple, it simply allows the user to dial any number, then the user can get connected into IVR and dial a PSTN number again, then gateway would route this number to VCS, and VCS would route this call back to the gateway. Therefore, it may also be a way to make toll fraud. External user could make a local call to your gateway and use your system to make an international call.
You can also prevent this by using search rules following the suggestion I posted above. It is very simple, do this:
Furthermore, you can also use the field "Request must to be authenticated" on search rule configuration. If you set it to "yes" as I mentioned before, only authenticated endpoints (or endpoints treated as authenticated) will be able to reach the rule. Then you can setup your desirable sub zones to whether "check credentials" (VCS will challenge the endpoint to authenticate) or to "treat as authenticated" (VCS will mark the endpoints as authenticated without challenging authentication). Therefore, only desirable endpoints will be able to dial PSTN numbers.
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-29-2013 03:11 PM
Hello,
As promissed adding here some snapshots from the isdn gw basic config in case some one need it in the future.
for the rules it is straight forward. I did follwo recommendation above for securing the gw from toll frade calls.
Thanks all for you help.
06-29-2013 06:46 PM
Hi Ahmed, thanks for your feedback.
If you think your doubt has been answered, please, mark the "right answer". We use it to control which topics have been resolved.
Regards
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide