02-27-2014 04:21 PM - edited 03-16-2019 09:57 PM
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
02-27-2014 04:35 PM
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
02-27-2014 08:27 PM
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
02-27-2014 09:40 PM
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
02-27-2014 11:01 PM
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
02-28-2014 12:25 AM
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
03-12-2014 10:09 AM
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
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