Jeroen van Bemmel wrote:
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.
I agree that a restriction saying that a UA can have only one
outstanding registration per AOR at any one time would address the
problem. 3261 has such a restriction for INVITEs but I don't recall it
having one for REGISTERs?
Anders
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
