[OpenSER-Devel] [ openser-Bugs-1763799 ] presence CSeq values wrong after reSUBSCRIBE

[SourceForge.net]

Bugs item #1763799, was opened at 2007-07-30 18:14
Message generated for change (Comment added) made by amr42
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: Open
Resolution: None
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: 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