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

From: "David Simons" <[email-masked]>
Date: Tue, 22 May 2001 13:13:44 -0700

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, May 21, 2001 5:59 AM
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: 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.

[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.  

>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.  So we really can't require that that the CSeq of SUBSCRIBE
be related to the CSeq of NOTIFY.  There needs to be a mechanism by
which the notifier can reset the state of the transaction.  I believe
the 481 would accomplish this.

-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 <http://www.dynamicsoft.com/> 

Regards,

David J. Simons

SDE Lead

Window RTC

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 May 2001 21:11:34 -0400

-----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 
>>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. 
>
subject,
>doesn't require any kind of clock synchronization, though, so I'm not sure
>[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.

CSeq
>>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
>establish subscription state there from a refresh. This would not work with
>your proposal.
>
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.

---
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 May 2001 15:31:55 -0400

> Sent: Wednesday, May 23, 2001 11:33 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> 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.

There is also record-route, but bis specifies that proxies record-route
requests even if they have a Route header. The reason is to allow
reconstruction of state.

>  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.  

How?

> 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.

481 would indeed accomplish this, but you would need to specify that for
SUBSCRIBE, a client SHOULD create a brand new subscription. I still think
its easier just to start your CSeq using the clock, and then you don't need
any additional work on the client or server.
So, the question is if we ALSO want to specify that a client should retry
the SUBSCRIBE on 481. Its not clear that thats always the right behavior.

-Jonathan R.

---

> Sent: Wednesday, May 23, 2001 5:52 AM
> To: David Simons
> I'm still not following you here... I don't see why you want 
> to generate
> 481
> in response to SUBSCRIBE.
> 
> -Jonathan R.
> 
> ---
> > Sent: Tuesday, May 22, 2001 9:57 PM
> > To: Jonathan Rosenberg
> > It was my thinking that the 481 be sent in reply to the SUBSCRIBE.
> > 
> > David J. Simons
> > Development Lead
> > Microsoft Windows RTC
> > 
> > 
> > Sent: Tuesday, May 22, 2001 6:12 PM
> > >out soon). In that case, we have proposed using a 
> timestamp for CSeq.
> > It
> > but
> > >are a clear violation of RFC2543.  The RFC clearly states 
> that CSeq's
> > are
> > consecutive 
> > >>each re-SUBSCRIBE can have a CSeq greater then one.  If a 
> > PA receives
> > a
> > >SUBSCIBE with a 
> > of
> > that
> > 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
> > >So we really can't require that that the CSeq of SUBSCRIBE 
> be related
> > to
> > the 
> > >CSeq of NOTIFY. 
> > 
> > I wasn't proposing that.
> > 
> > 
> > A 481 to a NOTIFY does delete the subscription, but I still 
> don't see
> > what

---

From: Robert Sparks <[email-masked]>
Date: Tue, 29 May 2001 10:06:54 -0400

gentlefolk -

Please move this discussion to the SIP list.

RjS

> From: Christian Jansson [mailto:[email-masked]]
> Sent: Monday, May 28, 2001 7:59 AM
> To: David Simons; Jonathan Rosenberg
> Subject: Re: [Simple] Difference between a SUBSCRIBE and a 
> re-SUBSCRIBE
> 
> 
> 
> > This doesn't strictly follow
> > RFC2543 because the SUBSCRIBE CSeq wouldn't be contiguous.  
> But, it does
> > keep the CSeq counts up-to-date.
> >David J. Simons
> 
> 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
> 
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>