VoIP - MWI?

[seanwg]

Hi,

I have my E-series phone running succesfully with asterisk. Now one last problem - MWI.


The E-series stack can't seem to process this MWI message - any idea why?

Here is the NOTIFY sent to my phone -


ythtv*CLI> sip reload
Scheduling destruction of SIP dialog '1b1a51cc1ca07c6f705ba2da699d39f7@X.157' in 32000 ms (Method: NOTIFY)
Reliably Transmitting (NAT) to X:5060:
NOTIFY sip:X@X:5060 SIP/2.0
Via: SIP/2.0/UDP X:5060;branch=z9hG4bK3cbba354;rport
From: "asterisk" <sip:asterisk@X>;tag=as3ebb2bd9
To: <sip:X@X:5060>
Contact: <sip:asterisk@X>
Call-ID: 1b1a51cc1ca07c6f705ba2da699d39f7@X
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 95


Messages-Waiting: yes
Message-Account: sip:asterisk@X
Voice-Message: 2/0 (0/0)

---
mythtv*CLI>

And the responce from the E65


<--- SIP read from X:5060 --->
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP X:5060;branch=z9hG4bK3cbba354;rport=5060;received=X
To: <sip:X@X>;tag=7atc4bl62hhc6m6pdm16
From: "asterisk" <sip:asterisk@X>;tag=as3ebb2bd9
Call-ID: 1b1a51cc1ca07c6f705ba2da699d39f7@X
CSeq: 102 NOTIFY
Content-Length: 0



Any ideas?

Sena

[Andas]

I think nokia does not support MWI messages

[nly]

This seems to be a known malfunction, the message parser expected to get an optional field in the simple-message-summary payload. It's not known if this fix will be included in the future E65 SW upgrade releases.

If it would be possible to configure the server to send the additional urgent message count (e.g. always dummy 0/0 value) it would conceal this problem.

[seanwg]

Can you take the above text and modify it to what you believe the E61 wants?

Reading over RFC 3842, the text is supposed to look like this:

5.2. Body Format Syntax

The formal syntax for the application/simple-message-summary MIME
type is described below. The message-context-class production is
defined in Section 6.2 of RFC 3458 [7]. Note that all productions
described here are case insensitive.

message-summary = msg-status-line CRLF
[msg-account CRLF]
[*(msg-summary-line CRLF)]
[ *opt-msg-headers ]

msg-status-line = "Messages-Waiting" HCOLON msg-status
msg-status = "yes" / "no"
msg-account = "Message-Account" HCOLON Account-URI
Account-URI = SIP-URI / SIPS-URI / absoluteURI

msg-summary-line = message-context-class HCOLON newmsgs SLASH oldmsgs
[ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ]

opt-msg-headers = CRLF 1*(extension-header CRLF)

newmsgs = msgcount
oldmsgs = msgcount
new-urgentmsgs = msgcount
old-urgentmsgs = msgcount
msgcount = 1*DIGIT ; MUST NOT exceed 2^32-1


Asterisk ends out exactly whats in the spec. Does the E65 want some opt-msg-headers field? 1*(something CRLF)

[kolbi-nokia]

Hello!

I own a Nokia E70 and see the same sequence of SIP message
BUT just since a did an update of the firmware from an 1.x version to the current 3.x version.
Before the content of the NOTIFY endet as (something like an) SMS
in the Inbox of the Message Application with the text like:

Messages-Waiting: yes
Message-Account: sip:asterisk@X
Voice-Message: 2/0 (0/0)

I would like to see the old behaviour again - maybe i can send custom messages with sipsak too - as the bigger plan...

Yours

[forceps]

Has there been any progress or follow-up on this issue?

I never saw a SIP based MWI on my E70. I recently purchased an E51, and although the wireless connectivity issues that plagued my E70 have largely been worked out in the E51 (thank you!), it sadly still does not seem to show an MWI for SIP based voicemail when registered to an asterisk server.

Any thoughts or ideas?

[forceps]

Just bouncing this again. Hoping that there is some news. I believe Niklas tagged this as a bug back in June of 07, but I haven't seen any corrections in any of the VOIP deployments to date.

Is there a planned fix for this bug in upcoming firmware versions? It would be really nice to have my VOIP voice mailbox illuminate the MWI on my E51 when there are messages waiting (just as it does on the GSM side).

[forceps]

Just another related question...

VoIP Support Chart
http://www.forum.nokia.com/main/reso...a_devices.html

I noticed that this page states that VoIP release 2.3 supports MWI. However, I have not found this to be the case. Has anyone had success with MWI? It does not work for me. I get the "400 Bad Request Back" error as described in this thread when registered to an asterisk server using an E51 (100.34.20).

Is there a Nokia representative that can shed some light on this issue? Why is VoIP MWI marked as supported in release 2.3 when it does not appear to work? If it is indeed supported, in what context does it work?

[joelevo]

Why is VoIP MWI marked as supported in release 2.3 when it does not appear to work? If it is indeed supported, in what context does it work?

1. Because it's working

2. even with *

U can contact me, if you like.

CU
Joel

[forceps]

I tried to contact you directly, but you have member contacting blocked.

I would really like to know what you did to get this working.
Can you paste the relevant sections of your sip.conf here?

I'm currently running asterisk 1.4.19. The E51 is firmware 100.34.20.

Here's my sip.conf for my E51

[E51]
type = friend
host = dynamic
secret = *****
dtmfmode = rfc2833
callerid = "E51"
context = outgoing
nat = yes
qualify = 60000
canreinvite = no
mailbox = 1@user

I've tried this with both an E70 and an E51. The phone registers, can make calls, can receive calls. Everything works wonderfully. I just get that horrid "400 Bad Request Back" when asterisk tries to send the MWI status. If you have a fix to this, I would love to see it. Thanks.

[forceps]

Even though joelevo never got back to me with his solution, his assertion that MWI does in fact work made me revive my efforts.

After struggling with several settings, I was delighted to get VoIP MWI somewhat working!

The key was adding a "fromdomain" entry for the phone in the sip.conf file. I previously only had this up as a global parameter, thinking that it would blanket for all sip devices, but I discovered that having a fromdomain in the [general] heading is different from having a fromdomain for a particular peer (asterisk is quite confusing sometimes).

Setting this parameter to the FQDN of the server will allow the server's SIP NOTIFY packets that contain the message waiting information to be properly delivered to the phone. My E51's MWI icon lights up and I get an SMS-like message delivered, the contents of which are identical to the message that I reported last year on my E70:

http://discussion.forum.nokia.com/fo...d.php?t=118751

At the time, I had no idea how that message was delivered. I think it was some kind of fluke because I didn't have the fromdomain parameter set in my sip.conf for that device. In any case, I have discovered how to nearly consistently reproduce this feature on the E51 and I believe the two messages are the same. This means is that even back in VoIP Release 1.0, the phones had the MWI feature enabled. Unfortunately, no one had documented this lovely little feature.


Additionally, you can set the "vmexten" parameter for the phone in the sip.conf to set the callback extension for the phone to access voicemail. This should be set to the same value as the "Internet Voicemailbox Number" that you can set on the phone (dialed when you hold down 1). By setting this parameter correctly, the "Message account" of the SMS-like notification received will contain the proper callback extension to retreive voicemail. I can just click on this to call and retreive my voicemail directly. How neat! The structure of the callback URI is as follows: <vmexten>@<fromdomain>

Thus, the updated entry for my sip.conf is the following:

[E51]
type = peer
host = dynamic
secret = *****
dtmfmode = rfc2833
callerid = "E51"
context = outgoing
nat = yes
qualify = no ;saves battery
canreinvite = no
mailbox = 1@<vm context>
fromdomain = <FQDN of asterisk server>
vmexten = <extension to retrieve voicemail>

With this, a VoIP MWI works! Yay!

[forceps]

Despite the good news, all is not perfect.

Adjusting the settings as I described does enable the VoIP MWI, but it is not consistent. It does not work every time the phone tries to send an MWI. There are still many instances where I see the "400 Bad Request" bounced back to my server from the phone. I do not know what the cause of these error messages are. There should be no difference between the SIP NOTIFY messages that work and those that don't (and there aren't any, I have personally checked the SIP debug and they are all the same).

Additionally, I have noticed that the phone does not appear to receive more than one MWI notification per registration. If multiple MWIs are received during one registration session, the phone will generally reject all but the first one. Sometimes it rejects the first one and later picks up and accepts a subsequent one. However, as far as I can tell, the phone will not accept more than one MWI per SIP registration session. When the SIP registration expires, and the phone re-registers, it will almost invariably receive and accept the newly delivered MWI.

Although bouncing the "400 Bad Request" error back to the server is a bug, the interesting functionality described above does allow for a workaround. If the registration expiration time is short enough (1/5/10 minutes), then the user is almost guaranteed to receive the MWI in a reasonable time period after a message has been left (because there is no guarantee that the one delivered immediately after the voicemail was left will actually be accepted by the phone). My registration expiration is set to five minutes, and I don't mind having to occasionally incur up to a 10 minute delay to receive the MWI.

The behavior I have described above appears quite variable. There are times where even after re-registration, the phone will reject the MWI notification with the 400 error. Why this happens, I do not know. In this scenario, the MWI is missed, but is usually picked up by the next re-registration. I suppose in an environment where receiving MWIs on an very timely basis is of extreme importance, one could lower the registration expiration to 20/30 seconds if needed. However, I am not in any mission critical environment, so if my MWI is delayed by 10 or 15 minutes, that is fine by me. Compared to the previous situation where I would often miss voicemails left for me for days on end (until I manually checked my voicemail), this is a dream come true.

Nonetheless, there is still an outstanding bug with even VoIP Release 2.3 (E51 100.34.20) where not all SIP NOTIFY based MWI messages are accepted (as should be the situation per the RFC).

One other suggestion I would make based on the current implementation is to perhaps modify the way the MWI is interpreted. In the current implementation, if I have not retrieved my voicemail, the MWI notification will continue to be delivered by the server (as it should), and I will continue to receive copies of the SMS-like MWI notification in my phone's inbox, even though only one unheard voicemail has been left (not good, it floods my inbox). The contents of the delivered message are correct (X message(s) waiting), but I receive many of these (approximately one for every expiration period that passes without me retrieving my voicemail). I am guessing this is probably why the phone rejects any additional MWIs delivered per a given SIP registration session, but this is a pretty bad hack that causes other problems. I think the way MWIs are received should be reworked so there is a small little location that gets updated which lists how many messages are waiting without having to pile up SMS-like messages in the inbox. Maybe this could be worked into the MWI icon itself, or perhaps the line that is set in the active standby could be modified or something. SIP NOTIFY MWIs were not designed to be interpreted as SIP MESSAGE method packets. They should not be delivered to an inbox, but were designed to modify a notification icon with an optional message count. This way, the MWI on the Nokia would behave as intended by the SIP protocol.

All in all though, this is just a minor bug. At least now it is working and I have a VoIP MWI!

[marnivala]

Nonetheless, there is still an outstanding bug with even VoIP Release 2.3 (E51 100.34.20) where not all SIP NOTIFY based MWI messages are accepted (as should be the situation per the RFC).

Could you describe more of this situation?

One other suggestion I would make based on the current implementation is to perhaps modify the way the MWI is interpreted. In the current implementation, if I have not retrieved my voicemail, the MWI notification will continue to be delivered by the server (as it should), and I will continue to receive copies of the SMS-like MWI notification in my phone's inbox, even though only one unheard voicemail has been left (not good, it floods my inbox). The contents of the delivered message are correct (X message(s) waiting), but I receive many of these (approximately one for every expiration period that passes without me retrieving my voicemail). I am guessing this is probably why the phone rejects any additional MWIs delivered per a given SIP registration session, but this is a pretty bad hack that causes other problems. I think the way MWIs are received should be reworked so there is a small little location that gets updated which lists how many messages are waiting without having to pile up SMS-like messages in the inbox. Maybe this could be worked into the MWI icon itself, or perhaps the line that is set in the active standby could be modified or something. SIP NOTIFY MWIs were not designed to be interpreted as SIP MESSAGE method packets. They should not be delivered to an inbox, but were designed to modify a notification icon with an optional message count. This way, the MWI on the Nokia would behave as intended by the SIP protocol.

As far as I know there isn't any plans to change MWI state indication method(SMS to inbox). But message functionality has been changed so that new SMS about waiting voice messages is generated only when voice mailbox status has changed. Though, I'm not sure which phones will receive this change.

What do you mean with "additional MWIs delivered per a given SIP registration"? Do you mean situation where multiple MWIs are received during one registration session? And do you mean that only this sequence works as it should:
REGISTER -> SUBSCRIBE -> NOTIFY -> REGISTER -> SUBSCRIBE -> NOTIFY ...

and in this scenario:
REGISTER -> SUBSCRIBE -> NOTIFY -> SUBSCRIBE -> NOTIFY ... all MWI's aren't processed until new REGISTER?

[forceps]

The problem I see is exactly the same one that was described by seanwg at the start of this thread, except I don't get the error every single time anymore like I used to. With the changes I discovered, some of the the NOTIFY MWIs are accepted. However, not all are. Some of them are rejected with a "400 Bad Request" as seanwg has shown. The SIP debug I see looks identical to what he pasted (except, of course, with the respective changes to the usernames/domain names/IPs for my network). There isn't much more I can explain about the error itself. I don't know why it's happening, but I have discovered some patterns of behavior that, though don't always generalize, are relatively consistent.


----------


Here's what I mean by the "additional MWIs delivered per a given SIP registration".

Imagine the phone begins a SIP session like this:

REGISTER -> SUBSCRIBE -> NOTIFY (MWI 1/0)

Let's say for this example, the phone accepted the NOTIFY and alerted that there is a message waiting (MWI icon + SMS message delivered). So far so good.

During this session, let's say that another call came in that the user didn't pick up. So you had the following:

INVITE -> TRYING -> RINGING -> CANCEL -> OK -> ACK

Both the server and the phone understood that there was a call attempted and that the server canceled the call (e.g. it timed out and went to voicemail). The caller would leave voicemail, and now the server would, as it should, notify all subscribed clients that there is a new voicemail waiting. Let's say that the user didn't pick up the first voicemail that was present when subscribed. So, the packets will now look like this:

NOTIFY (MWI 2/0) -> 400 Bad Request

And that's where I see the problem very consistently every time. It is possible that I just haven't tried this enough times to get a second MWI delivered...but I have yet to see a counterexample. The phone will not accept an additional MWI per a given SIP session. It will not be until the phone's SIP registration expires and the phone re-registers, will it get the new MWI:

REGISTER -> SUBSCRIBE -> NOTIFY (MWI 2/0)

I'd say about 60-70% of the time, the phone will accept the NOTIFY MWI upon registration. I have seen occasions where it rejects this with a "400 Bad Request", so nothing is delivered until the next registration attempt (or sometimes the one after that, or after that...etc). Since my SIP sessions have a 5 minute expiration, this isn't too bad since my voicemail isn't ever that time sensitive. I have never seen an MWI been delayed more than 10 minutes with my current expiration time (no more than three total NOTIFY MWI attempts: one at time that voicemail was left, a second at the first re-registration, a third at the second re-registration). It is theoretically possible that it could be delayed longer than that, but it has yet to happen in my trials.

What is very curious about this behavior is that in the case that upon registration, there were no messages waiting, a new voicemail left (NOTIFY MWI packet) during that SIP session will be accepted with roughly the same success rate as having an MWI notification at registration. This is what leads me to believe there is a separate problem when there has already been one MWI delivered already.

The chain of packets looks like this:

REGISTER -> SUBSCRIBE -> NOTIFY (MWI 0/0)
INVITE -> TRYING -> RINGING -> CANCEL -> OK -> ACK
- voicemail left by caller
NOTIFY (MWI 1/0) -> OK

I've noticed that this scenario tends to work (60-70% of the time). However, if during the registration, if there was a waiting message that was successfully delivered, the phone will not accept any subsequent MWIs during that session, even if the packet would be updating the messages waiting count.


----------


Regarding the piling up of those NOTIFY MWIs, it would be wonderful if additional SMS-like messages were not delivered unless a change in voicemail status had occurred. That would be fabulous. It would be even better if that could somehow persist across SIP registration sessions too. In the ideal world, there would just a single, constant SMS-like message (or window/screen/etc) that was always present and would always be updated that I could navigate to view the number of messages that I have (including 0, if that is the case) and get linked to my voicemail from there as well (as it is now).

[marnivala]

Ok, thanks for the reply. I will look into this, but it might take some weeks before I have some info, because I don't have direct access to Asterisk server (and holidays are also quite close).

Regarding the piling up of those NOTIFY MWIs, it would be wonderful if additional SMS-like messages were not delivered unless a change in voicemail status had occurred. That would be fabulous. It would be even better if that could somehow persist across SIP registration sessions too. In the ideal world, there would just a single, constant SMS-like message (or window/screen/etc) that was always present and would always be updated that I could navigate to view the number of messages that I have (including 0, if that is the case) and get linked to my voicemail from there as well (as it is now).

You are right that implementation could be better (separate UI, message count in indication icon etc.). However, functionality is intended to be similar to message waiting indication of cellular side.