Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Incoming calls go to the wrong direction.

Background:

Cisco unity connection 9.1

Scope:

I have an external number from telco (let say 6041111111).

Also I have a forwarding service on telco site which  forwards all calls into the Cisco Unity Connection number (let say 6042222222).

However, instead of doing that, all calls go to another number on CUCM (let say 6043333333).

Hello,

What debug command could help to trace incoming call ?

Thank you,

Sergey

6 REPLIES

How to trace incoming call.

Install the RTMT tool and use the Unity Connection>Port Monitor. You can also install the "Remote Port Status Monitor" from the link below:

http://ciscounitytools.com/Applications/CxN/PortStatusMonitorCUC7x/PortStatusMonitorCUC7x.html

HTH

Regards,

Yosh

HTH Regards, Yosh
Community Member

How to trace incoming call.

HI,

I performed some debugging on the voice gateway and have found 1 interesting line:

             Redirecting Number i = '!', 0x008F, 6041111111

What it can be ????

Thanks,

Sergey

Cisco Employee

Re: How to trace incoming call.

If you don't elaborate on why the need to do this, or the problem you're facing, you cannot expect answers.

Sent from Cisco Technical Support iPad App

HTH

java

if this helps, please rate

www.cisco.com/go/pdi
Community Member

Re: How to trace incoming call.

Here is the scope:

I have an external number from telco (let say 6041111111).

Also I have a forwarding service on telco site which  forwards all calls into the Cisco Unity Connection number (let say 6042222222).

However, instead of doing that, all calls go to another number on CUCM (let say 6043333333).

So, the issue is that  incoming calls going to the wrong direction.

Also below is the log from the voice gateway:

Feb 28 07:12:52.572: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8  callref = 0x11E6

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98386

                Exclusive, Channel 6

        Facility i = 0x9F8B0100A117020114020100800F535552474559204C5542454E4B4F56

                Protocol Profile =  Networking Extensions

                0xA117020114020100800F535552474559204C5542454E4B4F56

                Component = Invoke component

                        Invoke Id = 20

                        Operation = CallingName

                                Name Presentation Allowed Extended

                                Name = SERGEY

        Calling Party Number i = 0x2183, '604XXXXX18'

                Plan:

bgd-bur-r2921-01#ISDN, Type:National

        Called Party Number i = 0x80, '2222'

                Plan:Unknown, Type:Unknown

        Redirecting Number i = '!', 0x008F, '6041111111'

                Plan:ISDN, Type:National

Feb 28 07:12:52.588: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x91E6

        Channel ID i = 0xA98386

                Exclusive, Channel 6

Feb 28 07:12:52.588: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x91E6

        Progress Ind i = 0x8088 - In-band info or appropriate now available

Feb 28 07:12:52.848: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x91E6

        Display i = 'VoiceMail'

Feb 28 07:12:52.912: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x11E6

bgd-bur-r2921-01#

Feb 28 07:12:52.916: ISDN Se0/0/0:23 Q931: RX <- STATUS pd = 8  callref = 0x11E6

        Cause i = 0x80E328 - Information element not implemented

        Call State i = 0x0A

bgd-bur-r2921-01#

Feb 28 07:12:57.812: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x11E6

        Cause i = 0x8090 - Normal call clearing

Feb 28 07:12:57.844: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x91E6

Feb 28 07:12:57.864: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x11E6

Re: How to trace incoming call.

So, the issue is that  incoming calls going to the wrong direction. -- Send across debug voice ccapi inout and  dial-peer config from your router.

Thanks

Manish

Community Member

OK, the solution was as usual

OK, the solution was as usual pretty simple:

Because calls came from  "Redirecting Number" (as you can see in  log), the cisco unity used the "Forwarded Routing Rule" instead of "Direct Rule" as in all other cases.

So, I just added one more "Forwarded Routing Rule" to redirect calls to the correct number and it solved the problem.

Thanks,

Sergey    

198
Views
0
Helpful
6
Replies
CreatePlease to create content