I think the same Call-Id restriction adds protection from the transaction timeout case.
Assume Call-Id restriction is not there. UA sends a REGISTER and if transaction times out, UA will send a second request with a different Call-Id. If the registrar receives the previous request out of order, bindings will not be as desired, where as with the same Call-Id this is taken care of. In the restart case, as you mentioned inorder processing is not gauranteed. Same Call-Id for all registrations may be the solution(depends on how easy/required to implement). -Ramakrishna -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeroen van Bemmel Sent: Thursday, November 17, 2005 11:46 AM To: Anders Kristensen; Paul Kyzivat Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] Call-ID usage by UA within the same boot cycle,after a network failure >I believe the reason 3261 says this is that without it there's no >mechanism for ensuring registrations are processed in order. With the >same Call-ID, this property comes from the CSeq (as within a dialog). > .. but at the same time, the UA MUST NOT send a new REGISTER while another one is still in progress. So this out-of-order should only occur for non-conformant UAs; if a UA were to crash just after sending a REGISTER and then immediately starts a new one, the second one will generally have a different Call-ID (and different out-of-order CSeq), so the in order processing would not be guaranteed. It does not appear to be a critical issue, the "MUST NOT send new one while another in progress" is sufficient for in-order processing and the "same Call-ID" is only extra safety, somewhat redundant. Would it be recommended to use the same call-ID for *all* registrations if possible, and perhaps a CSeq number based on a monotonically increasing clock that survives crashes? > Also from section 10.2: > > CSeq: The CSeq value guarantees proper ordering of REGISTER > requests. A UA MUST increment the CSeq value by one for each > REGISTER request with the same Call-ID. > > Anders > > Paul Kyzivat wrote: > >> Monica, >> >> I know it specifies this, but it has always been a big mystery to me why. >> There is only trivial impact on the UA or registrar if the UA changes >> the callid. >> >> If you are asking from the point of view of a UA, I would just say to >> use the same one as long as it is convenient. If you are asking from >> the point of view of a registrar, I would say that you should not >> have any important dependency on this. >> >> Paul >> >> [EMAIL PROTECTED] wrote: >> >>> Hi All, >>> >>> RFC 3261 states that "A UA SHOULD use the same Call-ID for all >>> registrations during a single boot cycle." And technically a UA is >>> still within the same boot cycle even when the network connection is lost. >>> Right? >>> >>> Hence is it fair to assume that UA should generate the same Call-ID >>> when UA remains powered on, and got reconnected to network after a >>> network failure ? (maybe Home gateway or DSL/cable modem or Internet >>> SP failure). Will be great if anyone can confim if my assumptions >>> are correct. >>> >>> RFC 3261, Section 10.2 >>> Call-ID: All registrations from a UAC SHOULD use the same Call-ID >>> header field value for registrations sent to a particular registrar. >>> If the same client were to use different Call-ID values, a >>> registrar could not detect whether a delayed REGISTER request might >>> have arrived out of order. >>> >>> RFC 3261, Section 10.2.4 >>> A UA SHOULD use the same Call-ID for all registrations during a >>> single boot cycle. Registration refreshes SHOULD be sent to the >>> same network address as the original registration, unless redirected. >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - >>> - - >>> Thanks & Regards >>> Monica Ingudam (Mail: [EMAIL PROTECTED]) Signal Engineer AOL >>> Dulles _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
