cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1449
Views
0
Helpful
6
Replies

Mobile voice access dialout issue

pratik.rb
Level 3
Level 3

Hi Pros,

I have configured MVA on CUCM 6.1 and on 2 * H.323 gateways having shared DID ISDN PRI.

I am able to reach the IVR menu and authenticate via PIN.

When I select 1 for making a call and enter a PSTN number or internal extension the call doesnt go thru and error "The number you dialled cannot be reached. Please check the number and try again" comes up and also notice that the gateway tries to send out the call thru same PRI (even though I have not configured hairpin). Even the internal extension it tries to route via PRI.

Config is:

1) MVA service parameters enabled and number 5597 defined

2) Media resources MVA number 5597 defined

3) Service started of MVA

!
application
  service CCM http://10.0.0.1:8080/ccmivr/pages/IVRMainpage.vxml
  !

!
dial-peer voice 5597 pots
service ccm
incoming called-number 5597
no digit-strip
!

======================================================================================

gw#
Dec 10 19:46:37.672 UTC: ISDN Se2/1:15 Q931: RX <- SETUP pd = 8  callref = 0x434
B
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98393
                Exclusive, Channel 19
        Calling Party Number i = 0x2183, '0501547381'
                Plan:ISDN, Type:National
        Called Party Number i = 0x81, '5597'
                Plan:ISDN, Type:Unknown
Dec 10 19:46:37.684 UTC: ISDN Se2/1:15 Q931: TX -> CALL_PROC pd = 8  callref = 0
xC34B
        Channel ID i = 0xA98393
                Exclusive, Channel 19
Dec 10 19:46:37.684 UTC: ISDN Se2/1:15 Q931: TX -> CONNECT pd = 8  callref = 0xC
34B
Dec 10 19:46:38.208 UTC: ISDN Se2/1:15 Q931: RX <- CONNECT_ACK pd = 8  callref =
0x434B
gw#
Dec 10 19:46:38.208 UTC: %ISDN-6-CONNECT: Interface Serial2/1:18 is now connecte
d to 0501547381 N/A
gw#
Dec 10 19:46:52.824 UTC: ISDN Se2/1:15 Q931: Applying typeplan for sw-type 0x2 i
s 0x2 0x1, Calling num 0501547381
Dec 10 19:46:52.824 UTC: ISDN Se2/1:15 Q931: Applying typeplan for sw-type 0x2 i
s 0x0 0x1, Called num 5597
Dec 10 19:46:52.824 UTC: ISDN Se2/1:15 Q931: TX -> SETUP pd = 8  callref = 0x1C2
C
        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 = 0x2183, '0501547381'
                Plan:
gw#ISDN, Type:National
        Called Party Number i = 0x81, '5597'
                Plan:ISDN, Type:Unknown
        Redirecting Number i = 0x01008A, '5007'
                Plan:ISDN, Type:Unknown
Dec 10 19:46:52.908 UTC: ISDN Se2/1:15 Q931: RX <- SETUP_ACK pd = 8  callref = 0
x9C2C
        Channel ID i = 0xA9839E
                Exclusive, Channel 30
Dec 10 19:46:53.368 UTC: ISDN Se2/1:15 Q931: RX <- DISCONNECT pd = 8  callref =
0x9C2C
        Cause i = 0x8283 - No route to destination
        Progress Ind i = 0x8288 - In-band info or appropriate now available
Dec 10 19:46:53.368 UTC: ISDN Se2/1:15 Q931: call_disc: PI received in disconnec
t; Postpone sending RELEASE for callid 0x9BAD
Dec 10 19:46:53.368 UTC: %ISDN-6-DISCONNECT: Interface Serial2/1:18  disconnecte
d from 0501547381 , call lasted 15 seconds
gw#
Dec 10 19:46:53.372 UTC: ISDN Se2/1:15 Q931: TX -> DISCONNECT pd = 8  callref =
0xC34B
        Cause i = 0x8083 - No route to destination
Dec 10 19:46:53.540 UTC: ISDN Se2/1:15 Q931: RX <- RELEASE pd = 8  callref = 0x4
34B
Dec 10 19:46:53.540 UTC: ISDN Se2/1:15 Q931: TX -> RELEASE_COMP pd = 8  callref
= 0xC34B
Dec 10 19:46:53.552 UTC: ISDN Se2/1:15 Q931: TX -> RELEASE pd = 8  callref = 0x1
C2C
Dec 10 19:46:53.816 UTC: ISDN Se2/1:15 Q931: RX <- RELEASE_COMP pd = 8  callref
= 0x9C2C
gw#

======================================================================================

Please help.

6 Replies 6

pratik.rb
Level 3
Level 3

Hi Pros,

Little help here.

I tried configuring the first method using PRI.

Should I be using hairpin instead?

Can somebody elaborate this PRI or hairpin method definition in simple terms.

i`m also looking for an answer, I can not believe so many people are having the same problem with the same CUCM  response- "your can not

be dialed....." - we can`t all be wrong or doing the same thing. When you press 1 can you dial an internal  DN as I also get the same response for this. The only reply I`ve got back is check the CSS and make use it is the correct one and not the one for for Mobile access, SNR. Also the other suggestion someone gave me was to recreate a new CSS and not reuse an existing one as sometimes this also causes problems. From my thinking once the call is accepted  by CUCM and the MVA service i.e entering the pin, pressing 1 to make the call what else would stop it - the response from CUCM seems to state it may be a CSS issue but I`ve also rechecked , deleted, re-created , put every partition in to the CSS but it still gets the same response- I`m using a lab CUCM so the partitions, CSS are very limited- can anyone help further

I cant dial internal extensions. I get same error.

Secondly which CSS are you talking about? Can you explain in detail. I have configured the same Line CSS on the remote destination profile CSS, Rerouting CSS and Transformation CSS.

The Remote Destiantion Profile has two CSS

CSS - is used for MVA

Re-CSS is used for SNR

Most replies back on this subject state make sure the CSS you use to make a call after pressing 1 is the "CSS"  and not Re-CSS as this is used for the SNR option but as like you , I added the same partitions in to both but the MVA still fails. What version  CUCM are you running I`m 6.1.2..XXXXX

Im running 6.1 Im in process of opening tac case as this is urgent for us. I will update when issue resolves.

We were able to resolve the problem after removing a TP in the way of MVA number.

We were adding a 8 prefix to incoming called number on the CUCM H.323 gateway configuration which was then translated to the actual called number adding a 9 to the calling number.

After removing the prefix and hence skipping the translation pattern (note the called (MVA) number was never modified - just processed by translation pattern for modifying calling number) the MVA started working and was able to make outgoing calls properly.

TAC are recreating this issue in their environment and may take ime to revert.

iptuser55 if you have any translations remove them and give a shot.