Bugs item #1763799, was opened at 2007-07-30 18:14
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1763799&group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.2.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Aron Rosenberg (amr42)
Assigned to: anca (anca_vamanu)
Summary: presence CSeq values wrong after reSUBSCRIBE
Initial Comment:
This issue was found with the 1.2 stable tree but most likely happens with HEAD
as well.
The problem is that the presence module does not keep seperate CSeq values for
the SUBSCRIBE and NOTIFY pathways. Per RFC 3261. each direction of a dialog
must have seperate increasing CSeq values.
When the presence module receives a SUBSCRIBE or reSUBSCRIBE it sets the DB
CSeq value to the CSeq number from the actual re/SUBSCRIBE message. In most
cases this is lower than the DB value was before since in general more NOTIFY's
go out than reSUBSCRIBE requests. The result of this is that the NOTIFY that is
sent as a result of the reSUBSCRIBE has a lower CSeq value than the previous
NOTIFY before the reSUBSCRIBE. Proper UAC agents (per RFC 3261) ignore all
lower CSeq values than they have already received and this results in the
subscription timing out from the UAC's standpoint.
See the attached pcap file for an example of this. Notice that in frame 11, the
OpenSER side NOTIFY CSeq is 7, but the reSUBSCRIBE has CSeq 4 (Frame 13). The
next NOTIFY (Frame 15) that OpenSER sends (as a result of the reSUBSCRIBE) has
CSeq of 6 which is wrong. The UAC only sends the next reSUBSCRIBE since it
received two more NOTIFY's before the expires time.
A brief glance at the code indicates that the problem is in notify() at
notify.c line 1615 (called at subscribe.c:484) when the passed in reSUBSCRIBE
message is used to set the DB CSeq value. The code is complex since that
pathway is used from multiple places so I don't know what the best fix is.
----------------------------------------------------------------------
>Comment By: anca (anca_vamanu)
Date: 2007-08-02 07:42
Message:
Logged In: YES
user_id=1614776
Originator: NO
Thank you for finding the bug. I've commited the fix.
I will now close this bug report as fixed.
regards,
Anca Vamanu
----------------------------------------------------------------------
Comment By: Aron Rosenberg (amr42)
Date: 2007-08-01 19:34
Message:
Logged In: YES
user_id=43318
Originator: YES
There is a bug in the new code which was causing DB issues. When we
applied the following patch to your change it now works properly.
Index: modules/presence/subscribe.c
===================================================================
--- modules/presence/subscribe.c (revision 2556)
+++ modules/presence/subscribe.c (working copy)
@@ -406,7 +406,7 @@
n_update_cols++;
update_keys[n_update_cols] = "remote_cseq";
- update_vals[n_update_cols].type = DB_STR;
+ update_vals[n_update_cols].type = DB_INT;
update_vals[n_update_cols].nul = 0;
update_vals[n_update_cols].val.int_val = subs->cseq;
n_update_cols++;
----------------------------------------------------------------------
Comment By: anca (anca_vamanu)
Date: 2007-07-31 08:24
Message:
Logged In: YES
user_id=1614776
Originator: NO
Hello,
I have made the commit that should fix the bug. Please test and say if it
works ( notice that the active_watchers db table has been modified.)
Thanks,
Anca
----------------------------------------------------------------------
Comment By: anca (anca_vamanu)
Date: 2007-07-31 07:14
Message:
Logged In: YES
user_id=1614776
Originator: NO
Hello,
This problem has been reported and fixed in the trunk since 1917 version
( see thread '[Devel] Notify CSeq number not increased?'). However, the
fixed hasn't been ported to the 1.2.x branch, but it should have been. I
will make the changes.
regards,
Anca Vamanu
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1763799&group_id=139143
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
