Mobile Voice access Call Drop 2

[Anas Hafez]

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

[Rajan]

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

[Anas Hafez]

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.

[Rajan]

can you attach cucm traces for one test call with the call details to check?

[Anas Hafez]

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.

[Anas Hafez]

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:

1. MVA DN in service parameters
2. MVA DN in media resources

VGW:

1. destination pattern of the MVA service dial peer
2. destination pattern of the MVA outgoing voip dial peer to CUCM

notes:

1. 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
2. In sip trunk mtp required and redirecting diversion header for inbound and outbound were checked

[Anas Hafez]

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