Summary:ASTERISK-02032: SIP SUBSCRIBE - NOTIFY Wrong Call-ID Match
Reporter:kurtwp (kurtwp)Labels:
Date Opened:2004-07-16 07:51:34Date Closed:2011-06-07 14:10:32
Versions:Frequency of
Environment:Attachments:( 0) cme-subscribe.log
( 1) putty.log
Description:I noticed when my Cisco device sends a SUBSCRIBE message to Asterisk for voice mail subscription.  The Asterisk server will send the wrong call ID back.  Thus, the Cisco sends a 481 back to the Asterisk.

I believe the below section in RFC 3265 is relevant:

NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header "tag" parameter which matches the "From" header "tag" parameter of the SUBSCRIBE, and the same "Event" header field.  Rules for comparisons of the "Event" headers are described in section 7.2.1.  If a matching NOTIFY request contains a "Subscription-State" of "active" or "pending", it creates
a new subscription and a new dialog (unless they have already been created by a matching response, as described above).

Below is a portion of the trap I obtained from the Asterisk Server.  A complete trap can be found at

I will keep this link up until the is resoved.

Sip read:
SUBSCRIBE sip:2486@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bKFC2
From: "2486" <sip:2486@>;tag=6C30-149
To: <sip:2486@>
Call-ID: 2C1ED0F6-2BDE11D6-80048294-A080CC2F
Timestamp: 1089723760
Contact: <sip:2486@>
Event: message-summary
Expires: 600
Accept: application/simple-message-summary
Content-Length: 0
13 headers, 0 lines
Using latest SUBSCRIBE request as basis request
Sending to : 5060 (non-NAT)
Looking for 2486 in voice-mail

Reliably Transmitting:
NOTIFY sip:2486@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK19c0b453
From: "asterisk" <sip:asterisk@>;tag=as288443e6
To: <sip:2486@>
Contact: <sip:asterisk@>
Call-ID: 57f3d594208235d27e796fd27db42c1b@
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 37
Messages-Waiting: yes
Voicemail: 7/0
(no NAT) to 192.168.0

Asterisk Version:  3/16

I then upgraded to version: Asterisk CVS-HEAD-07/14/04-16:28:29 built by root@asterick.wlb2.xxx.com on a i686 running Linux

And now it states that it:

Destroying call '4c94648a770bc4de2fee7cfb7ffde5e8@'
Destroying call '2C2316A7-2BDE11D6-80069825-9D67EB86'
Destroying call '2C227A7F-2BDE11D6-80059825-9D67EB86'
Destroying call '2C1D98A7-2BDE11D6-80039825-9D67EB86'
Destroying call '2C1CFC7F-2BDE11D6-80029825-9D67EB86'

I have attached a trap of the call flow:
Comments:By: Olle Johansson (oej) 2004-07-16 11:14:41

Do you also have a mailbox= in your sip.conf entry for this phone?

By: kurtwp (kurtwp) 2004-07-16 12:03:09

See my configs below:

[root@asterick root]# cd /etc/asterisk/
[root@asterick asterisk]# cat sip.conf
port=5060                       ; Port to bind to
bindaddr=                ; Address to bind SIP channel to
context=voice-mail              ; Default context for incoming calls




[root@asterick asterisk]# cat extensions.conf


exten => 7967614502,1,Answer()
exten => 7967614502,2,Milliwatt()

exten => 22014,1,Wait(5)
exten => 22014,2,Milliwatt()
exten => 22014,3,Hangup
exten => 22999,1,VoicemailMain(${CALLERIDNUM})
exten => 22999,2,Wait(2)
exten => 22999,3,Hangup
exten => _22XXX,1,Setvar(ext=${EXTEN:1})
exten => _22XXX,2,Wait(1)
exten => _22XXX,3,ResponseTimeout,10
exten => _22XXX,4,Voicemail(u${EXTEN:1})
exten => _22XXX,5,Hangup

exten => _2XXX,1,Setvar(ext=${EXTEN})
exten => _2XXX,2,Wait(1)
exten => _2XXX,3,ResponseTimeout,10
exten => _2XXX,4,Voicemail(u${EXTEN})
exten => _2XXX,5,Hangup

[root@asterick asterisk]# cat voicemail.conf


fromstring=Voice Mail Server


2486 => 1234,Kurt,kurtwp@yahoo.com

[root@asterick asterisk]#

By: Olle Johansson (oej) 2004-07-16 13:13:21

Disable the mailbox= in sip.conf if the phone is subscribing for notification. You are getting one notification in answer to your subscribe, which the cisco accepts. You are getting another as ordered in sip.conf, which the cisco does not accept.

Please confirm if this works for you.


By: kurtwp (kurtwp) 2004-07-16 13:38:53

I deleted the line from my sip.conf.  I attached a file containing the sip trap.
You will noticed that after the Cisco sends the SUBSCRIBE the Asterisk send a
403.  When using an early release of Asterisk, I did not get the 403.  


By: Mark Spencer (markster) 2004-07-16 22:31:28

not major.  asterisk doesn't have the phone subscribe, we just send notify's unsolicited.

By: kurtwp (kurtwp) 2004-07-17 08:41:26

Can you be more explicit in your explanation?  Does this mean that Asterisk has a minor bug?  Is some one going to fix this?  What is the ETA for a fix?  Is there a work around?

I not trying to get on any bodies case, but these are typical questions I would ask vendors I deal with if a bug was found in their code.  In addition, I can go to my boss and tell him an approximate time for this to fix.    

I know for a fact that the Cisco device cannot accept unsolicited notifies.



By: Mark Spencer (markster) 2004-07-17 18:10:50

Well, Asterisk originally was designed to send NOTIFY without having a corresponding SUBSCRIBE since (at least in the draft that existed at the time) the SUBSCRIBE was optional.  It may be possible to work around it by *not* specifying a mailbox in the configuration on the phone's config but leaving the mailbox= on the asterisk side so that the unit doesn't try to request it within the subscribe.

It is a minor bug on the asterisk side, but it's not-at-all an easy one to fix.

By: kurtwp (kurtwp) 2004-07-20 14:51:33

Let me know when you complete the fix and I'll test it.


By: twisted (twisted) 2004-08-09 12:18:29

oej - since you have taken ownership, what is the status of this?

By: Olle Johansson (oej) 2004-08-09 12:35:09

twisted: Been on holiday, trying to catch up with mail to see if I've gotten responses on my questions in this matter.

I suspect that some phones that SUBSCRIBE to mailbox status do not accept our mailbox= notify option at all. With Mark's recent patch, we accept the subscribe, but sending NOTIFY with a different call-id: The phones just answer that the call leg doesn't exist.

As Mark said, maybe they will accept our MWI NOTIFY messages if you do not configure a mailbox account on the phone. I can't test, since I haven't got a Cisco phone.

Also, I think that the mailbox SUBSCRIBE accept patch is a bit too much of a quick hack, but I'll come back to that. I don't know why it was put there in the first case.

By: Olle Johansson (oej) 2004-08-14 04:31:22

Anyone with a Cisco phone that can check if it's possible to disable subscribe of mailbox status in config menus?

If so, will mailbox= notification work or still generate an error message?

I need to know if mailbox notification works at all with Cisco phones nowadays.

By: kurtwp (kurtwp) 2004-08-15 14:38:16

I see that we are assuming that the problem is with a Cisco phone.  It is not.
The Asterisk server is having a problem with a Cisco PBX.  To be more accurate Cisco's Call Maganer Express.  I will not be able to test this becuase the phone
is running Skinny to the PBX and the PBX is doing SIP trunking to Asterisk.


By: Olle Johansson (oej) 2004-08-15 15:28:35

kurtwp: Yes, I assumed "Cisco device" was a phone :-)

Also, I've seen other reports on the same issue on the mailing list and on IRC, with phones.

As Mark said, this has become design error in Asterisk, based on an old RFC. We are sending NOTIFY on MWI without relating it to a SUBSCRIBE. It's not an easy quick-fix to fix that. It's a re-design.

Closing this bug report now, will reopen when we have a patch or a fix. Find us on IRC or mail us if you have any questions.

By: Olle Johansson (oej) 2004-08-15 15:32:28

Closing until we have a coder that wants to re-design MWI so Asterisk does it two ways:
* With mailbox= config in [peer] in sip.conf

To support MWI SUBSCRIBE, we need to find out what to subscribe for (extension for mailbox in dialplan), context to look in and if this will disable mailbox= notification or not. Also, who can subscribe to an extension? Anyone, any peer or only peer that "owns" the mailbox? We need to construct an ACL solution.

As we said, not a simple task. But needed.