Thank you for the useful video but you mentioned in the video that virtual account tagging will be mentioned in the description ? ... View more

Thanks for the useful video as always but can you please point me to your previous video describing how to setup the site ? ... View more

I had the same error message but with EMCC not enabled and it was solved by checking home cluster check box in End User configuration page ... View more

How is the poll duration 16 Seconds is different from the polling server value of 64 Seconds ? ... View more

Thank you for the useful information but the Bootable_UCSInstall_UCCX_10_6_1_UCOS_10.6.1.10000-39.sgn.iso is supposed to be UCSInstall_UCCX_10_6_1_UCOS_10.6.1.10000-39.sgn to make it work ... View more

Sorry for the late reply but the solution was 1. in service parameters call manager service set local route group for redirected calls to it's default value 2. remove digit manipulation from voice gateway sip trunk on call manager ... View more

Thank you Rajan for your reply the problem has been solved and without going into details i will post the working configuration we had local route group set in our dial plan so we had to change local route group in the service parameters > call manager service to it's default (calling party) - instead of last redirecting party which made mva call drops after entering the called number. also for the mobile voice access to work aside from activating the service from the service parameters and adding an rd,rdp and end user configuration. 4 directory numbers need to be configured that need to be the same actually not sure if it's mandatory for them to be the same but at least must have the same number of digits (in our case we had them all the same number) CUCM: MVA DN in service parameters MVA DN in media resources VGW: destination pattern of the MVA service dial peer destination pattern of the MVA outgoing voip dial peer to CUCM notes: VGW MVA dial peers didn't have any digit manipulation on them also no prefixing digits on the vgw sip trunk on called number - inbound section In sip trunk mtp required and redirecting diversion header for inbound and outbound were checked ... View more

sorry for the late reply i'm not sure what do you mean exactly by the call details to check in the call traces but i've attached the call traces from the trace log central section and the trace of the sip message of the call between the call manager and the sip trunk for the voice gateway from the real time data trace section, hope it will be helpful. ... View more

First thank you for your reply second as for the calling number matching the remote destination in the remote destination profile it actually matches successfully since i'm prompted to enter the PIN directly  not the remote destination then the PIN i've tested this calling the MVA from another remote destination not configured on any remote destination profile i've configured the service parameters with a partial match to achieve that as you described regarding the debugs we can see from the voip dial peer debugs //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:    Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=100        where dial-peer 100 the dial-peer for the mva service matching    so the dial peer is actually matched and thrown back to the PSTN at this stage    where from the isdn q931 debug we can see a list of matchings         1: Dial-peer Tag=44007      2: Dial-peer Tag=2      3: Dial-peer Tag=3      4: Dial-peer Tag=4      5: Dial-peer Tag=5      6: Dial-peer Tag=6      7: Dial-peer Tag=7      where the dial-peer 44007 is a dial-peer i've configured in order to throw the call back again to the call manager since the DN configured on the VGW for the MVA service matching doesn't equal the one configured in the call manager MVA DN in media resources as for the part where Calling Party Number i = 0x0083, '01066635797' Plan:Unknown, Type:Unknown Called Party Number i = 0x81, '44007' i don't actually fully understand how this match has happens since the dial-peer 44007 is configured with a destination pattern 44007 and calls comes from the PSTN as "4 digits only" not 5 digits so it will match the dial-peer with tag 100 as i mentioned above the only explanation that i could think this happened that the first call leg is from the calling party (remote destination) that comes from the PSTN to the VGW and the other call leg originate from the call manager to the VGW to match the 44007 dial peer but why does the call drops , does it have something to do with matching the dial peers that throws the call back to the PSTN as you have mentioned , i don't know as for the last part about the translation pattern it doesn't have anything to do with the MVA configuration i just thought that may calls was matched to it so that's why the call drops so i included it in the post as it may a useful information i have confirmed that the DN 44007 (MVA DN configured on call manager) is called by 2  things 1st the matching on the VGW dial-peer 44007 and secondly i have configured a DN with the same extension but different partition since MVA DN on call manager doesn't allows shared and it was ringing on that ip set and the line associated with the remote destination was in remote in use state when that DN was ringing then removed back again in order not to ruin the configuration sorry for the long explanation but i hope i've been able to describe the problem and thanks again in advance and if you need any more information about any of the configuration or the behavior let me know. ... View more

unfortunately that didn't work and it seems that the problem was with the voice gateway not the call manager which works fine now. thank you for your reply and sorry for the late answer. the problem was solve by adding this command to the voice gateway voice call disc-pi-off ... View more