cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
671
Views
0
Helpful
1
Replies

CUE MWI

danplacek
Level 4
Level 4

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.

1 Accepted Solution

Accepted Solutions

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

View solution in original post

1 Reply 1

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