×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CUE MWI

Endorsed Question
Mar 14th, 2013
User Badges:
  • Silver, 250 points or more

I had a problem today where a customer reported that the message waiting indicator lights did not always turn on. I did some testing by initating a full mwi refresh and immediately noticed that almost all of the attempted "calls" to turn on/off mwi got "486 busy" from CME.


Upon further review it looks like the first call got "180 Ringing" indefinetely and just locked up the dn for awhile. I removed/readded the dn'

s for both mwi on and off, turned outcalling off and on in CUE... no effect.


I ended up just switched to unsolicited notify... which took care of the issue.


This is not the first time I have experienced this and have never gotten a good answer from TAC on the cause... it has always just been "switch to notify and it will work again".


Has anyone else experienced this? Any thoughts on what the cause could be?


Thanks.

Endorsed by paolo bevilacqua
Alexander Maroukian about 4 years 5 months ago

Hello Daniel,


The issue you are facing is most probably connected with connection-reuse under sip-ua, please correct me if I am wrong, you can check if this is set under sip-ua.

When you use it then the connection for sip will be answered to the originating port e.g.

THE ISSUE:


You receive a message from the CUE with source port 44444 with destination port 5060 on CME. This is normal behaviour as usualy the source port is not important and it is random. You cannot change this behaviour in CUE.

Then the CME answers from 5060 to 44444 (making connection reuse). But the CUE is not listening for SIP messgaes on port 44444 but on well known 5060.

This way the communication is not happening that is the reason that why ringing never reaches the CUE because it is received on 44444.

On the other hand if the CME is sending message first it is using 5060 source port to 5060 destination port - this way the communication is working fine.


THE SOLUTION:

You have applied one of the solutions already:

1. Change the notification to unsolicited.

2. Remove connection-reuse under sip-ua if it is not needed by the SIP provider.

3. Use the latest IOS 15.1(4)M5 where this is resolved and you may add "connection-reuse via-port" which look in the SIP header for the VIA port which is usually 5060 and answers to this port with the next SIP message.


HTH,

Alex


*Please rate helpful posts

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Alexander Maroukian Thu, 03/14/2013 - 14:24
User Badges:
  • Cisco Employee,

Hello Daniel,


The issue you are facing is most probably connected with connection-reuse under sip-ua, please correct me if I am wrong, you can check if this is set under sip-ua.

When you use it then the connection for sip will be answered to the originating port e.g.

THE ISSUE:


You receive a message from the CUE with source port 44444 with destination port 5060 on CME. This is normal behaviour as usualy the source port is not important and it is random. You cannot change this behaviour in CUE.

Then the CME answers from 5060 to 44444 (making connection reuse). But the CUE is not listening for SIP messgaes on port 44444 but on well known 5060.

This way the communication is not happening that is the reason that why ringing never reaches the CUE because it is received on 44444.

On the other hand if the CME is sending message first it is using 5060 source port to 5060 destination port - this way the communication is working fine.


THE SOLUTION:

You have applied one of the solutions already:

1. Change the notification to unsolicited.

2. Remove connection-reuse under sip-ua if it is not needed by the SIP provider.

3. Use the latest IOS 15.1(4)M5 where this is resolved and you may add "connection-reuse via-port" which look in the SIP header for the VIA port which is usually 5060 and answers to this port with the next SIP message.


HTH,

Alex


*Please rate helpful posts

Actions

This Discussion