Subject: [Simple] Re: [Sip-implementors] Crashed and rebooted UAS scenario and CSeqs

From: "Ranjit Avasarala" <[email-masked]>
Date: Mon, 30 Apr 2001 14:50:37 -0500

Hi Ajay,

   That depends on the implementation of the server. so if the server
reboots and all the prevoius transactions are lost, then the transaction
will be rejected with a 481 response code , but if the server is able to
retrieve prevoius transactions , then you can say
trying (100) .

Regards
Ranjit

----- Original Message -----
From: Ajay Chitturi <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, April 30, 2001 2:24 PM
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 ?
Does this hold for SUBSCRIBE / MESSAGE (also an INVITE for an IM
session).
Could there be any scenarios where rejecting such sessions could create
problems ?

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 ?

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. But this could be a problem in IM/Presence
scenarios where we
could have multiple MESSAGE or NOTIFY requests per second.

Thanks
Ajay.
_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

---

From: "Ajay Chitturi" <[email-masked]>
Date: Mon, 30 Apr 2001 12:24:21 -0700

Hi,

Thanks
Ajay.