[asterisk-bugs] [Asterisk 0012560]: [patch] Problems with NOTIFY due to Asterisk sending wrong CALL-ID and duplicate sip: tag in header of NOTIFY

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12560 
====================================================================== 
Reported By:                vsauer
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   12560
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-30-2008 14:10 CDT
Last Modified:              07-02-2008 07:20 CDT
====================================================================== 
Summary:                    [patch] Problems with NOTIFY due to Asterisk sending
wrong CALL-ID and duplicate sip: tag in header of NOTIFY
Description: 
Hi,

(first of all: I'm not an expert on SIP. So I might be completly wrong.
Don't take it personally).

I have the following problem with 1.4.19:

Leaving ore deleting a message on/from the voicemail does not correctly
trigger the MWI LED on a Siemens Gigaset S685 while it does on a Snom 370.
A lot of people may claim this is a bug of the 685, but I think it isn't.
It's related to Asterisk.
For some reason the Snom behaves more tolerant (Snoms have options like
"accept broken registrar" etc), but the 685 doesn't.

Here's the exakt problem:

Step 1) Restart Asterisk, Shut down Siemens S685

Step 2) Leave a message on voicemail
VM is registerd in all phones and setup in voicemail.conf
Snom phone (which is on all the time) starts blinking

Step 3) Power on Siemens S685
Siemens get subscription:

arthur*CLI> sip show subscriptions
Peer             User        Call ID      Extension        Last state    
Type            Mailbox
192.168.0.15     gigaset11   1259484430@  --               <none>        
mwi             101 at defaul

MWI LED starts blinking.


Step 4) Take another phone (like the Snom), goto mailbox and delete
message
-> Snom stops blinking
-> S685 doesn't, MWI still blinking

After deletion of the messgae, CLI shows:
[Apr 30 20:33:27] WARNING[16137]: chan_sip.c:12814 handle_response: Remote
host can't match request NOTIFY to call
'67ffd8e6092c427f3e23547d06841655 at volker-sauer.de'. Giving up.

See dump of packages in additional information.

You can see, that in Packet 1, the Call-ID of the subscriprion is
1259484430 at 192_168_0_15

In Packet 3 - which is the notify of changed count of messages in VM, the
Call-ID is:
67ffd8e6092c427f3e23547d06841655 at volker-sauer.de

which is therefore rejected by the Siemens in Packet 4:
481 Call Leg/Transaction Does Not Exist


Somehow Snom phons accept this, though.

What is weired, too:
Look at the To field in packet 1:
        To: <sip:sip:gigaset11 at 192.168.0.15:5060>;tag=4293876579
why "sip:sip:...." is this correct? Lookes like a typo..
and somehow it's correct in package 3:
        To: <sip:gigaset11 at 192.168.0.15:5060>

I'll add a wireshark dump of the 4 packages in case additional information
is needed.

To my understanding, the Siemens seems to be right by rejecting the
NOTIFY. And this could be a bug of Asterisk.

Maybe it's related too:

http://bugs.digium.com/view.php?id=6848

See the message of caspy on 04-03-06 06:25

"It seems, that this is because NOTIFY request come with 'tag' field in
"From:" header different to one, that was given by phone in SUBSCRIBE
request."
Maybe this could be related, too.

Regards
Volker

====================================================================== 

---------------------------------------------------------------------- 
 ramonpeek - 07-02-08 07:20  
---------------------------------------------------------------------- 
You mentioned peers 1101 and 1102, but from these peers I do not see any
succesfull SUBSCRIBE messages.
However peer 1100 does have a succesfull SUBSCRIBE and further on in the
trace a failed NOTIFY. (And you said it worked??)

Anyway... looking at this peer I can see that that it uses a different
CALL-ID in the NOTIFY then what was used in the SUBSCRIBE.
It looks like subscriptions get messed up or an older subscriptions is not
deleted.
Also I can see to different domainparts;  "@192.168.1.16" and
"@192_168_1_100"? 
You would't happen to have two devices trying to register under the same
name and thus Voicemail name? (one at 192.168.1.100 and one at
192.168.1.16)
(I trimmed the trace down a bit and you can see the sequence more clearer
in the attached "trimmedtrace.txt" file)

But I guess it would be even better to supply even cleaner traces than
this one, just as you already suggested.
I especially would like to see those since you are mentioning problems
with 1101 and 1102 of which no SUBSCRIBE is available in this trace.
Also you could create this trace from the boot of asterisk, meaning we
won't miss any subscribes and also no other interfering peers or old
call-legs.


I get the feeling we are getting closer..  ;-)

PS:
When you mentioned that the patch did not fix the problem...
Did you meant it didn't fix the "sip:sip" issue or the "Call leg does not
exist" issue? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-02-08 07:20  ramonpeek      Note Added: 0089592                          
======================================================================