cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

872
Views
5
Helpful
9
Replies
laffitte laurent
Beginner

Blocking Ad-Hoc conferences creation from ISDN endpoints through ISDN GW

Hi,

we have set up a customer infrastructure with a VCS-Control, a MCU 8510  and a 3241 ISDN gateway.

The MCU 8510 is registered on the VCS-Control with

- Prefix for MCU registrations = 50

- MCU service prefix =  50

THe MCU allows ad-Hoc conferences to be created.

On the other hand, the gateway is registered on the VCS-Control with  prefixes 0 and 1.
We have observed the following behavior regarding the  creation of Ad-Hoc conferences on the MCU using the 50  prefix:

- internal users (using internal endpoints registered on the  VCS-Control) can dial 50xxx to create Ad-Hoc conferences,

- external users on the ISDN network can dial the ISDN gateway  auto-attendant number followed by the 50xxx to join the conferences already  created by internal users.... but they can also dial 50xxx aliases even if  internal users have not created an Ad-Hoc conference on the MCU =>  consequently, external users are able to create Ad-Hoc conferences on the  MCU.

The problem is the following:

- The customer does not want external users such as ISDN endpoints to be  able to create Ad-Hoc conferences,

- On the MCU, we could disable the parameter named "Incoming calls to  unknown conferences or auto attendants" but we need it because Multiway is  mandatory for the customer: this feature must be set to "Create new ad hoc conference" for Multiway to work  properly.

- For now, the only solution we think about would be to  differentiate calls to Aliases already registered on the VCS-C from calls to  Aliases that are not registered to the VCS-Control.... but we have not found the  way to do it either using search rules, VCS-Control features or CPL scripts in  Call Policy.
I have looked into the CPL reference and examples in the VCS-C admin guide but there nothing about that in it. I have found a field that allows to check if the source of the call is registered or not ("registered-origin" parameter) but not for the destination !

So the main question is "is there a way to differentiate calls to Already  registered aliases from calls to unregistered aliases ?".

More generally, the question is "do we have a way to prevent external  ISDN users calling through the ISDN gateway to create Ad-Hoc calls on the MCU  (other than disabling the Ad-Hoc feature on the MCU)  ?"
9 REPLIES 9
ahmashar
Enthusiast

you can address this issue many different ways:

1- create different subzone 1 for local endpoints and register them here and create another subzone 2 and register your MCU there.Tthen you can create CPL script to check the call is coming from Default subzone (unregistered devices) or from subzone 1 (registered devices). Then you can allow or deny call routing based on dialed digit (for example 0 and 1 for gateway and 50 for MCU).

2- you can use authentication and again you can use either search rules or CPL to check for authenticated devices (i.e. internal or external via ISDN not authenticated) and allow or deny call routing.

3- you can tag the call destination for "registered-origin" via cpl by something like "valid" (abc@mycompay.com;valid) and then create search rule with regex look for valid, if it find a match for "valid" then strip "valid" and direct the call to specific zone  where MCU or ISDN is located/registered.

regards,

Ahmad

you can address this issue many different ways:

1- create different subzone 1 for local endpoints and register them here and create another subzone 2 and register your MCU there.Tthen you can create CPL script to check the call is coming from Default subzone (unregistered devices) or from subzone 1 (registered devices). Then you can allow or deny call routing based on dialed digit (for example 0 and 1 for gateway and 50 for MCU).

=> In that precise case, calls are never coming from the Default Zone assuming they are coming from the ISDN GW registered in a dedicated subzone on the VCS-C: as a consequence, calls are always coming from the registered ISDN GW. I am already denying some calls based on the dialed prefix but here I want to deny calls based on whether the destination endpoint is or is not registered.

2- you can use authentication and again you can use either search rules or CPL to check for authenticated devices (i.e. internal or external via ISDN not authenticated) and allow or deny call routing.

=> as before, calls are always coming from the registered ISDN GW and are always seen as not authenticated calls. I cannot distinguish calls coming from the ISDN GW to registered devices from calls coming from the ISDN GW to unregistered devices.

3- you can tag the call destination for "registered-origin" via cpl by something like "valid" (abc@mycompay.com;valid) and then create search rule with regex look for valid, if it find a match for "valid" then strip "valid" and direct the call to specific zone  where MCU or ISDN is located/registered.

=> when I look into the CPL reference guide, registered-origin is only applicable to the call origin and not on the call destination. How do you tag the call destination ? Also, how do know if it is a valid destination ? In my case, a valid destination would be a registered meeting room alias whereas a non valid destination would be a non registered meeting room alias.

regards,

Ahmad

Hi Paulo,

sorry for my late answer, I was busy on another project.

As I understand, you need to route a call to a destination checking if it is registered or not, if it is registered, you route the call, if not, you don't route. Is my understanding correct?

=> yes, it is correct.

But think with me, even if CPL could check the registration status of the destination, it wouldn't resolve the issue, because you will have the service prefix 50 registered all the time. The service prefix 50 matches the destination 50 and any destination 50*, then when CPL is checking if 509999, for example, is registered, the search will be true, because 509999 matches service prefix 50, so that VCS considers 509999 as a registered number even if only service prefix 50 is registered alone. This is a gatekeeper logic.

=> Seems legit

Well, even if CPL was able to resolve the issue, I wouldn't use it. There is a simplest solution . I would do this:

  1. Create a custom auto attendant on MCU and configure numeric ID to it (99999 for example); register the ID to VCS only using SIP, don't register H323 because you are using prefix 50 to H323, so it won't help; Disable the "creation of new conferences" on the auto attendant, but allow the "access to adhoc conferences" and allow access to scheduled conferences if desirable.
  2. Block ISDN gateway to dial anything starting with 50*; when ISDN gateway dial 50*, you should translate the number and route the calls to MCU's auto attendant 99999.
  3. On MCU's auto attendant, ISDN participants will be able to join in the conferences, but not to create new conferences
  4. The auto attendant of MCU is in english by default, if it is a problem, you can customize it and set the language you want; Refer to MCU documentation for further details.

=> I think this works, I will have to test it. However, I am not really familiar with the MCU auto attendant. Will the users dialing into the MCU auto attendant have to use the auto attendant menus and dial the conference number to join it or will they be able to directly dial the number to access the conference ?

Example:

- dial +33134355033

- call routed to the ISDN GW

- ISDN GW receives 4 last digits (5033), strips the 50 and transforms the received number into 9999933.

- call routed to the MCU auto attendant by VCS

- call connected to conference number 9999933 ?

Another "problem" is that external users will be able to list all the Ad-Hoc conferences and join them which means adding a PIN code will be necessary ... and the customer does not really want to add many steps to connection process.



To configure step 2, you can use CPL, however, I don't like it , so I would do that by using search rules alone:

  1. Register your ISDN gateway to a separated Subzone, for exmaple, ISDN-SubZone
  2. Create a search rule whose pattern matches 50*; on this search rule configuration, choose ISDN-SubZone as the "source" (you need VCS x7.2 or newer to use named subzones as source); use replace options on the configuration to translate the number to 99999@domain.com; the target might be localzone or a SIP Trunk to MCU (if it exists), whatever; the priority must to be over than other rules, just to avoid VCS to route calls through another rules

=> that's OK, I know how to do it !

=> I think this works, I will have to test it. However, I am not really familiar with the MCU auto attendant. Will the users dialing into the MCU auto attendant have to use the auto attendant menus and dial the conference number to join it or will they be able to directly dial the number to access the conference ?

Example:

- dial +33134355033

- call routed to the ISDN GW

- ISDN GW receives 4 last digits (5033), strips the 50 and transforms the received number into 9999933.

- call routed to the MCU auto attendant by VCS

- call connected to conference number 9999933 ?

Another "problem" is that external users will be able to list all the Ad-Hoc conferences and join them which means adding a PIN code will be necessary ... and the customer does not really want to add many steps to connection process.

Yes, MCU will route call to auto attendant, then the user will have to enter the conference ID when connected to auto attendant. And yes, the user will see the existent conferences on MCU, so using PIN is a nice option. You can also configure auto attendant to limit the access to scheduled conferences and allow only access to adhoc conferences, or both things, or only selected scheduled conferences.

To avoid having many steps, you could configure your ISDN gateway to route calls directly to MCU auto attendant, so that users only get connected to one auto attendants. You could, for example, have a single ISDN number to be used to access all the multipoints conferences by using MCU auto attendant.

As you use the same service prefix and register prefix on MCU, auto attendant is the best option to deny external users to create ad hoc conferences. I don't this you have a best option.

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".
Paulo Souza
Rising star

Hi Laffitte,

As I understand, you need to route a call to a destination checking if it is registered or not, if it is registered, you route the call, if not, you don't route. Is my understanding correct?

Unfortunatelly, CPL won't resolve the issue, because it cannot consider the registration status of the destination in order to decide whether allow a call or not.

But think with me, even if CPL could check the registration status of the destination, it wouldn't resolve the issue, because you will have the service prefix 50 registered all the time. The service prefix 50 matches the destination 50 and any destination 50*, then when CPL is checking if 509999, for example, is registered, the search will be true, because 509999 matches service prefix 50, so that VCS considers 509999 as a registered number even if only service prefix 50 is registered alone. This is a gatekeeper logic.

Well, even if CPL was able to resolve the issue, I wouldn't use it. There is a simplest solution . I would do this:

  1. Create a custom auto attendant on MCU and configure numeric ID to it (99999 for example); register the ID to VCS only using SIP, don't register H323 because you are using prefix 50 to H323, so it won't help; Disable the "creation of new conferences" on the auto attendant, but allow the "access to adhoc conferences" and allow access to scheduled conferences if desirable.
  2. Block ISDN gateway to dial anything starting with 50*; when ISDN gateway dial 50*, you should translate the number and route the calls to MCU's auto attendant 99999.
  3. On MCU's auto attendant, ISDN participants will be able to join in the conferences, but not to create new conferences
  4. The auto attendant of MCU is in english by default, if it is a problem, you can customize it and set the language you want; Refer to MCU documentation for further details.

To configure step 2, you can use CPL, however, I don't like it , so I would do that by using search rules alone:

  1. Register your ISDN gateway to a separated Subzone, for exmaple, ISDN-SubZone
  2. Create a search rule whose pattern matches 50*; on this search rule configuration, choose ISDN-SubZone as the "source" (you need VCS x7.2 or newer to use named subzones as source); use replace options on the configuration to translate the number to 99999@domain.com; the target might be localzone or a SIP Trunk to MCU (if it exists), whatever; the priority must to be over than other rules, just to avoid VCS to route calls through another rules

Well, I think this suggestion can help you.

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

Hi Laffitte,

Could you provide some feedback on this topic?

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".
rasimyigit
Beginner

Hi,

One Way is also to create a additional auto attendant for external users. You give a. Other register Id and you could disabled to create conferences ect...
On the ISDN GW for incoming call you can route to the external auto attendant ;-)

Sent from Cisco Technical Support iPhone App

One Way is also to create a additional auto attendant for external users. You give a. Other register Id and you could disabled to create conferences ect...

On the ISDN GW for incoming call you can route to the external auto attendant ;-)

This is exactly what I suggested above.

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".
Martin Koch
Advocate

Using the conductor (then you do not need the auto generation for multiway on the mcu

or adding a dedicated blade for multiway might also help here.

Like the others already described its not really possible to differentiate on the call control

or the mcu if its external new call or a multisite join. Using direct mappings for static rooms and auto attendants can be the way.

Check a bit more what kind of calls you want, what has to be blocked how conferences shall be have, ...

There are also other mechanisms like the guest-id of a virtual meeting room which can come handy for you.

As people can dial in to the mcu but they only get connected if somebody dialed in the chair-id.

There could be ways to combine that with a CPL, so you just dial 123 and internal users hit 12341 (=chair) and external

or isdn users hit 12342 (guest).

To secure everything also pin numbers could be something to look into.

Dont they have internet access via a vcs-e? In general the same issue would apply to external sip/h323 users

as well, so why do you wonder just explicitly about ISDN?

Please remember to rate helpful responses and identify

Content for Community-Ad