cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2828
Views
0
Helpful
11
Replies

ISDN GW 3241 rules

nuinoahmed
Level 1
Level 1

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,

2 Accepted Solutions

Accepted Solutions

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:

  1. Let's say your PSTN access code is 9. So your endpoints would call a PSTN number dialling 9 + Number.
  2. Let's say that your ISDN gateway is registering the prefix 9 to VCS, so that when you dial 9XXXX the call is routed to ISDN gateway which is registered to local zone of VCS
  3. Create a specific search rule to ISDN calls, see the example below, consider the marks:

VCS blocking toll fraude.png

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

View solution in original post

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:


  1. Create a isolated sub zone on VCS to register your ISDN gateway
  2. Register all your ISDN prefix to this sub zone
  3. Now you have all your ISDN numbers in a separated sub zone on VCS, you can now configure your ISDN search rules and specify which source will be allowed to reach this rule. On the "source" field, specify a sub zone other than the subzone where you registered your ISDN numbers. For example, you may choose the "Default Sub Zone" as the source, Then VCS won't allow ISDN gateway to reach the search rules that points do itself, but all another endpoints registered to VCS will be able to dial ISDN numbers (VCS 7.2 or newer is required to choose a specific sub zone as source).

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

View solution in original post

11 Replies 11

Martin Koch
VIP Alumni
VIP Alumni

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

ahmashar
Level 4
Level 4

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).

nuinoahmed
Level 1
Level 1

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

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

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:

  1. Let's say your PSTN access code is 9. So your endpoints would call a PSTN number dialling 9 + Number.
  2. Let's say that your ISDN gateway is registering the prefix 9 to VCS, so that when you dial 9XXXX the call is routed to ISDN gateway which is registered to local zone of VCS
  3. Create a specific search rule to ISDN calls, see the example below, consider the marks:

VCS blocking toll fraude.png

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

nuinoahmed
Level 1
Level 1

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

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

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

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:


  1. Create a isolated sub zone on VCS to register your ISDN gateway
  2. Register all your ISDN prefix to this sub zone
  3. Now you have all your ISDN numbers in a separated sub zone on VCS, you can now configure your ISDN search rules and specify which source will be allowed to reach this rule. On the "source" field, specify a sub zone other than the subzone where you registered your ISDN numbers. For example, you may choose the "Default Sub Zone" as the source, Then VCS won't allow ISDN gateway to reach the search rules that points do itself, but all another endpoints registered to VCS will be able to dial ISDN numbers (VCS 7.2 or newer is required to choose a specific sub zone as source).

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

nuinoahmed
Level 1
Level 1

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.

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: