Subject: [SIP] RE: [Sip-implementors] Crashed and rebooted UAS scenario and CSeq s

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 8 May 2001 15:46:30 -0400

Moved to sip, as this involves a proposed change to the spec.

> -----Original Message-----
> From: Ajay Chitturi [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 3:24 PM
> To: [email-masked]; [email-masked]
> Subject: [Sip-implementors] Crashed and rebooted UAS scenario 
> and CSeqs
> 
> 
> Hi,
> 
> Section 11.5 of 2543bis says the UAS MAY reject the INVITE with a new
> Call-Id and a To header
> with a tag. Should we reject such an INVITE with a 481 ?

That is the preferred response, yes.

> Does this hold for SUBSCRIBE / MESSAGE (also an INVITE for an IM
> session).

The server can do whatever it likes. However, a subscription is different
from a call. In many cases, if you get a re-invite for a call that you don't
know about, you want to terminate the call on the other side. However, if
you get a subscription refresh you don't know about, reinstating the
subscription is probably more desirable. So, the processing may depend on
the method.

> Could there be any scenarios where rejecting such sessions 
> could create
> problems ?

So long as your server never loses state for active "sessions" of any sort
(subscriptions, calls), there are no problems rejecting all requests with a
tag in the To field.

> 
> Also this section suggests that UAs wishing to handle such INVITEs
> robustly must choose
> monotonically increasing CSeq numbers even across reboots. Is 
> there any
> simple mechanism
> for choosing CSeqs in such a manner ?

Use the system clock.

> 
> draft-ietf-simple-im-00 (section 6.7)strongly recommends that CSeq
> should be computed using a clock (it refers to the SIP 
> section on CSeq).
> This section also says "This allows for the CSeq to increment without
> requiring the UA to store the previous CSeq values". The SIP bis draft
> suggests that a client could use a 32 bit second clock for generating
> the CSeqs.
> This mechanism would work only if the client could guarantee that it
> will not generate more
> than one request per second.

No. The clock is used to generate the initial timestamp. Subsequent values
increment by one from the initial, independent of the time. The result is
that you could only recover from a reboot if you recreate the call N seconds
after it started, where N is the number of requests that were sent since the
call was established. This might possibly be a problem, although I suspect
it will never be one in practice. 

In any case, the whole bit about recovering from crashes really belongs in
an extension, which I am currently preparing. I think the spec should simply
say that the initial CSeq value can be computed in many different ways, and
that the only requirement is that the initial value be less than 2**31.

-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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.