06-18-2013 07:22 AM - edited 03-18-2019 01:18 AM
Hi,
The MCU 8510 is registered on the VCS-Control with
- Prefix for MCU registrations = 50
THe MCU allows ad-Hoc conferences to be created.
The problem is the following:
- 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.
06-22-2013 01:03 AM
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
06-24-2013 01:23 AM
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
07-01-2013 02:59 AM
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:
=> 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:
=> that's OK, I know how to do it !
07-01-2013 04:51 AM
=> 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.
06-24-2013 08:07 AM
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:
To configure step 2, you can use CPL, however, I don't like it , so I would do that by using search rules alone:
Well, I think this suggestion can help you.
Regards
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-25-2013 11:49 AM
Hi Laffitte,
Could you provide some feedback on this topic?
Regards
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
06-25-2013 03:01 PM
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
06-25-2013 06:40 PM
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.
06-26-2013 09:20 AM
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
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