cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3199
Views
0
Helpful
13
Replies

UC520 Voicemail MWI not working

rawsonfang
Level 1
Level 1

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

2 Accepted Solutions

Accepted Solutions

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?

View solution in original post

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?

View solution in original post

13 Replies 13

Steven Smith
Level 7
Level 7

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.

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



Can you provide a debug ccsip messages on the CME side?  The other SIP debugs don't show an MWI call.

Hi Steven

Please find the attached debug capture of " debug ccsip message" I do not see the MWI call from CUE to CME. it should be call extension 8000XXX or 8001XXX.

Thanks in advnace.

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.

Hi Steve,

I have made test call from ext 810 to 811, and left message, no WMI light, check voice mail and delete the voice mail at ext 811. please find the attached trace from both UC520/CME and CUE.

Thanks for your help.

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



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.

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?

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

The SIP ALG should take care of this.

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?

Hi Steve,

I have removed the bind control source-interface FastEthernet0/0

and MWI start to work magically. Thank you so much for the patient and help. attached please find the good trace for MWI.

Getting Started

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: