Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE

From: "David Simons" <[email-masked]>
Date: Sun, 20 May 2001 20:36:11 -0700

In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE
request with the same Call-ID and higher CSeq.  The issue we are having
is that if a PA  losses state, because deletion after timeout or a crash
how does the PA know if a SUBSCRIBE request is a new SUBSCRIBE request
or a re-SUBSCRIBE request?  This is significant in that the client is
expecting a NOTIFY with a greater CSeq but the PA will start over.  I
suppose that one could just use a time stanp as the CSeq but that won't
work if the clocks our synchronized. 

The solution that I'm proposing is that a new SUBSCRIBES should have a
CSeq of 1 and then each re-SUBSCRIBE can have a CSeq greater then one.
If a PA receives a SUBSCIBE with a CSeq greater then 1 and it has no
record of the SUBSCRIBE it should return a 481.  The client could then
issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1. 

Regards,

David J. Simons

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 May 2001 08:58:46 -0400

-----Original Message-----
From: David Simons [mailto:[email-masked]]
Sent: Sunday, May 20, 2001 11:36 PM
To: [email-masked]
Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE

>In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE
request with the 
>same Call-ID and higher CSeq.  The issue we are having is that if a PA
losses state, 
>because deletion after timeout or a crash how does the PA know if a
SUBSCRIBE request is a 
>new SUBSCRIBE request or a re-SUBSCRIBE request?  This is significant in
that the client 
>is expecting a NOTIFY with a greater CSeq but the PA will start over.  I
suppose that one 
>could just use a time stanp as the CSeq but that won't work if the clocks
our 
>synchronized. 

The same problem exists for INVITE (look for a pending draft on the subject,
out soon). In that case, we have proposed using a timestamp for CSeq. It
doesn't require any kind of clock synchronization, though, so I'm not sure
what the problem is that you are describing.

>
>The solution that I'm proposing is that a new SUBSCRIBES should have a CSeq
of 1 and then 
>each re-SUBSCRIBE can have a CSeq greater then one.  If a PA receives a
SUBSCIBE with a 
>CSeq greater then 1 and it has no record of the SUBSCRIBE it should return
a 481.  The 
>client could then issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1.

To date, we've tried to maintain that a re-SUBSCRIBE = SUBSCRIBE, as that is
core to the concept of soft-state (which is what this is). In fact, there
are recovery scenarios where you REALLY want that property, such as when a
backup, without state of a subscription, comes online, and we need to
establish subscription state there from a refresh. This would not work with
your proposal.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com