05-13-2017 05:43 AM - edited 03-17-2019 10:19 AM
Hello,
sorry for including the 2 in the title but i have seen a similar post here in the forums but didn't find the answer i was looking for
so i have configured mva for CUCM 10.5(2) with a SIP vgw
CUCM Configuration
Serviceability
MVA Service Enabled
Service Parameters
MVA Enabled
MVA DN : 44007
VGW SIP Trunk
Inbound Digit Manipulation - significant digits (4) / Prefix 4
Media Resources MVA
DN: 44007
Translation Pattern
4XXX [Urgent Priority]
RDP Associated Line
44022
Also i have configured the rd with an associated enabled mva user and checked all the CSSs
Behavior:
when i call the mva dn 4007 configured on the vgw i hear mva prompts so i enter the pin and 1 to dial a number and then when i complete dialing and i press the # sign the call drops i discovered later the call manager always tries to ring the MVA DN configured under media resources
and to make sure of this i have added the same DN (44007) on an ip set (with a different partition of course) also the DN used for rdp shows in remote in use state when 44007 is called
it also shows in the rtmt real time data the call from 44022 to 44007 for the termination cause as
unallocated - unassigned number
any idea what am i missing here?
i have attached the vgw running config also debug isdn q931 and debug voip dialpeer
05-15-2017 04:05 AM
Hi Anas,
I did not quite understand what you are trying to achieve here. For MVA to work, the calling number of the incoming call should match the RD configured. If it cant match completely, you need to change the service parameter "matching callerid with remote destination" as partial and provide the exact no of digits to match.
From the debugs you attached, it seems like the gateway is sending the calls back to PSTN which fails. I am not sure whether this is expected.
May 13 12:01:18.388: ISDN Se0/1/3:15 Q931: TX -> SETUP pd = 8 callref = 0x1E82
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9839E
Exclusive, Channel 30
Calling Party Number i = 0x0083, '01066635797'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x81, '44007'
Plan:ISDN, Type:Unknown
May 13 12:01:18.404: ISDN Se0/1/2:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x9E81
COuld you provide more information like why you have a translation pattern in place and the complete configuration and call flow ?
how you have confirmed that the call is hitting CUCM ?
Thanks
Rajan
05-15-2017 07:51 AM
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.
05-16-2017 01:34 AM
can you attach cucm traces for one test call with the call details to check?
05-16-2017 12:00 PM
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.
05-20-2017 12:06 AM
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:
VGW:
notes:
06-05-2017 02:29 AM
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
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