Subject: [Simple] about Cseq sequence numbers

From: "Lamine Brahimi" <[email-masked]>
Date: Wed, 6 Mar 2002 11:07:13 +0100

Dear all,

Suppose a watcher subscribes to a presentity presence info with
an initial SUBSCRIBE msg  with a Cseq value of 1.
the watcher receives the corresponding NOTIFY  with a Cseq value of 1 (the
same).
Then the presentity updates several times its presence info and the watcher
receives several NOTIFY with incremented Cseq values. (ie if the presence
info changed twice
the last NOTIFY has a Cseq value of 3, right ?).
Then when the watcher wants to refresh its subscription I do that:
it sends a SUBSCRIBE with a CSeq value of 2 and a matching Dialog To tag.
 It receives its corresponding NOTIFY with a CSeq value of 2.
So my (little) problem is that I have two transactions which have the same
Cseq number of 2 in the same dialog :
the latest NOTIFY and the first one notifying an update in Presentity
presence info.
Is it correct like that ?
A possible solution to avoid that is to set the Cseq value of the
refreshing SUBSCRIBE to a value one
higher than the latest NOTIFY received in that dialog (in our case 4, if
presence info changed twice before the refresh)
and not the latest SUBSCRIBE sent.

Does someone knows what to do ?
Thanks,
Lamine.

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 6 Mar 2002 10:18:09 -0600

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lamine Brahimi
> Sent: Wednesday, March 06, 2002 4:07 AM
> To: [email-masked]
> Subject: [Simple] about Cseq sequence numbers
>
>
>
> Dear all,
>

No. Each endpoint has its own separate CSeq state for requests--that is,
each endpoint has its own numbering sequence for requests. In your example,
the NOTIFY after the re-subscribe would have a CSeq of 4 (the next in
sequence of all the NOTIFYs). The NOTIFY does not share the CSeq of the
INVITE. (Note that NOTIFY is a request, not a response.) In your example, it
is only coincidence that the initial SUBSCRIBE and NOTIFY had the same CSeq.
(In the real world, CSeqs should rarely start with 1, and each side would
probably choose a different initial CSeq.)

> and not the latest SUBSCRIBE sent.

No, that is incorrect behavior.  See above.