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

From: "David Simons" <[email-masked]>
Date: Wed, 23 May 2001 08:33:27 -0700

When a subscribe server losses session state, i.e. from server failure
or subscription timeout, and then it receives a re-SUBSCRIBE the
subscriber has session state and is simply updating the session whereas,
the server has no session state and sees the SUBSCRIBE as a new call.
The most relevant issue would be with NOTIFY CSeq and tag.  But, there
may be other implementation specific state issues.  The server would
start the NOTIFY CSeq at its normal starting point and the client would
be expecting a CSeq greater then the CSeq of the last NOTIFY it
received.  If the server sends notifies with a lower CSeq then the
client expects those notifies will be discarded, thus information lost.
We can try to patch this issue with things like seeding CSeq with a
timestamp but we could still be out of sync.  I believe that it is much
better to simply start the session over.  As I read RFC-2543 status code
481 would be the correct way for a subscribe server to indicated that it
doesn't have session state and needs to start over.  The client can then
reset its session state and generate a new Call-ID.

The next best proposal would be to have the NOTIFY CSeq always start as
an increment to the SUBSCRIBE CSeq.  This doesn't strictly follow
RFC2543 because the SUBSCRIBE CSeq wouldn't be contiguous.  But, it does
keep the CSeq counts up-to-date.

Regards,

David J. Simons
Development Lead
Microsoft Windows RTC

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, May 23, 2001 5:52 AM
To: David Simons
Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE

I'm still not following you here... I don't see why you want to generate
481
in response to SUBSCRIBE.

-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

> -----Original Message-----
> From: David Simons [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:57 PM
> To: Jonathan Rosenberg
> Subject: RE: [Simple] Difference between a SUBSCRIBE and a 
> re-SUBSCRIBE
> 
> 
> It was my thinking that the 481 be sent in reply to the SUBSCRIBE.
> 
> David J. Simons
> Development Lead
> Microsoft Windows RTC
> 
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, May 22, 2001 6:12 PM
> To: David Simons; [email-masked]
> Subject: RE: [Simple] Difference between a SUBSCRIBE and a 
> re-SUBSCRIBE
> 
> 
> 
>   
> -----Original Message-----
> From: David Simons [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 4:14 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.
> >
> >[David Simons] I would like to point out that time stamps 
> for anything
> but
> seeding a CSeq 
> >are a clear violation of RFC2543.  The RFC clearly states that CSeq's
> are
> consecutive 
> >increasing integers that don't wrap.  Time stamps would increase my
> jumps
> greater then 1.  
> 
> Right. I was only talking about the initial CSeq value.
> 
> 
> >>
> >>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.
> >
> >[David Simons] The problem with making re-SUBSCIRGBE = SUBSCRIBE is
> that
> you may be trying 
> >to reestablish the state of a session a priori. One side has 
> a complete
> image of the 
> >session state and the other has none.  It is clearly stated in
> draft-roach-sip-subscribe-
> >notify-03.txt that it is expected that notifier users a 
> different CSeq
> space then the 
> >subscriber. 
> 
> I don't follow. I don't see what the CSeq space in the 
> reverse direction
> has
> to do with re-establishing a subscription, where the subscriber thinks
> its
> new, and the server thinks it exists.
> 
> >So we really can't require that that the CSeq of SUBSCRIBE be related
> to
> the 
> >CSeq of NOTIFY. 
> 
> I wasn't proposing that.
> 
> 
> >There needs to be a mechanism by which the notifier can 
> reset the state
> 
> >of the transaction.  I believe the 481 would accomplish this.
> 
> A 481 to a NOTIFY does delete the subscription, but I still don't see
> what
> this has to do with re-SUBSCRIBE = SUBSCRIBE.
> 
> -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
>

---

From: "Christian Jansson" <[email-masked]>
Date: Mon, 28 May 2001 14:58:32 +0200

> This doesn't strictly follow

This requirement about contiguous CSeqs, is it really necessary? Is it valid
at all? For example if there is one or more proxy servers that requires
Proxy-Authentication some CSeqs may be used for resending request with valid
credentials. So, a UAS should never expect to receive contiguous CSeqs. But,
it should expect to receive strictly monotonically increasing CSeqs. And if
this is the case, why do we put the requirement on the UAC to send with
contiguous CSeqs. I think the requirement should be changed to: "send with
strictly monotonically increasing CSeqs".

Christian Jansson
Hotsip
www.hotsip.com