03-28-2010 01:29 PM - edited 03-21-2019 02:22 AM
Have UC520 box, voicemail is working, but MWI light not light up after left the message. Following is the configuration for CUE.
ephone-dn 5
number 8001... no-reg primary
mwi off
!
!
ephone-dn 6
number 8000... no-reg primary
mwi on
and with two Test phones
, with extenstion 810 and 811. the voice extension is 401, when extension 810 call 811, phone 811 trasfer to 401 with no anwser, left the messge, but no WMI light, go to extension 811, press "message" and could retrieve the message. if call 8000811 the phone 811 MWI light up, and call 8001811 the MWI light out.Attached please find the full UC520 and CUE configuration and the trace ccn stacksip dbug.Please shed some light on this, thanks in advance.Rawson
Solved! Go to Solution.
04-05-2010 07:44 AM
I think I see the issue now.
In your CME config, you have...
sip
bind control source-interface FastEthernet0/0
This means that signaling is expected to go here. You could change this to loopback 0, remove the bind command, or change the IP address in CUE of where you send to be the WAN IP address of the system.
Is there something in particular you are trying to accomplish with having the bind command there?
04-05-2010 09:06 AM
Did you try to capture "debug voice ccapi inout". My thoughts are since you may have changed the MWI numbers from A800 to 8000 maybe a dial-peer that matches 800 numbers is redirecting it somewhere else...
Also your dial-peer 1005 seems to be extra.. it is not needed and doesn't even match your WMI configurations. (where you testing?)
Also under your ephones you have mwi-line commands that are not needed.
Also have you checked to see if your setmwi.aef script exists or is corrupted?
03-30-2010 02:38 PM
I think the problem is this.
interface Loopback0
description $FW_INSIDE$
ip address 10.1.10.2 255.255.255.252
ip access-group 101 in
ip nat inside
ip virtual-reassembly
ACL 101 is not defined. I believe this would cause the traffic from CUE to be blocked. Noticed, you do not see the invite coming from 10.1.10.1 in the sip debugs from CME, but you do see the outbound messages. You could try defining this ACL or removing it from the interface.
Not that it matters, I would also change the SIP address in CUE to point to 10.1.10.2 instead of 10.1.1.1. Both should work, that is just my preference.
03-31-2010 03:18 PM
Hi Steve,
I have applied both changes you proposed,and MWI still not working, please find the attached trace after change, so some reason trace showed the the source of the SIP as 72.0.224.83, which is the IP for Internet port, not sure if this contribute to the issue? Thanks
The Call Setup Information is:
Call Control Block (CCB) : 0x84EF8578
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 810
Called Number : 401
Source IP Address (Sig ): 72.0.224.83
Destn SIP Req Addr:Port : 10.1.10.1:5060
Destn SIP Resp Addr:Port : 10.1.10.1:5060
Destination Name : 10.1.10.1
03-31-2010 03:23 PM
Can you provide a debug ccsip messages on the CME side? The other SIP debugs don't show an MWI call.
03-31-2010 08:17 PM
04-01-2010 03:04 PM
I do not see the calls either. Can you get the SIP traces from CME again and get the SIP traces from CUE? Be sure to leave a new message and to check your messages from a phone so that we know we should get a MWI change during that time.
04-03-2010 06:37 PM
04-04-2010 05:55 AM
Can you run a "debug voice ccapi inout" and see what dial-peer it is using? I see a few things different from your configuration vs. a default configuration. I am guessing since you changed the default ephone-dn for the MWI, I think a different dial-peer is picking up the calls befoer wmi gets it...
---------------------I have:-----------------------------
ephone-dn 55
number A801....
mwi off
!
!
ephone-dn 56
number A800....
mwi on
------------------------------------------------------
----------You have:------------------------------------
ephone-dn 5
number 8001... no-reg primary
mwi off
!
!
ephone-dn 6
number 8000... no-reg primary
mwi on
----------------------------------------------------------------
This dial-peer does not exist on my configurations either...
dial-peer voce 1005 voip
description ** Passthrough Inbound MWI from CUE **
b2bua
session protocol sipv2
session target ipv4:10.1.10.1
incoming called-number A80T
dtmf-relay sip-notify
codec g711ulaw
no vad
04-05-2010 08:14 PM
Hi John,
The issue has been resolved by remove the sip signaling binding to interface FastEthernt0/0. Thanks for your help.
I tried to collect some trace by using " debug voice ccapi inout " and MWI stop working, and it resumed to work after turnning off the debug command.
strange, this could be a bug.
04-05-2010 07:44 AM
I think I see the issue now.
In your CME config, you have...
sip
bind control source-interface FastEthernet0/0
This means that signaling is expected to go here. You could change this to loopback 0, remove the bind command, or change the IP address in CUE of where you send to be the WAN IP address of the system.
Is there something in particular you are trying to accomplish with having the bind command there?
04-05-2010 08:38 AM
This UC520 is connect to SIP ITSP provider, and they expect the SIP singling come from routeable registered IP. if we remove this binding, not sure it will break SIP registration with SIP trunking? but will try. Thanks
04-05-2010 08:48 AM
The SIP ALG should take care of this.
04-05-2010 09:06 AM
Did you try to capture "debug voice ccapi inout". My thoughts are since you may have changed the MWI numbers from A800 to 8000 maybe a dial-peer that matches 800 numbers is redirecting it somewhere else...
Also your dial-peer 1005 seems to be extra.. it is not needed and doesn't even match your WMI configurations. (where you testing?)
Also under your ephones you have mwi-line commands that are not needed.
Also have you checked to see if your setmwi.aef script exists or is corrupted?
04-05-2010 08:11 PM
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: