Anders Kristensen 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).
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
This is reasonable. But it also means that if the client never sends one
registration until the prior one is complete, then changing the callid
isn't going to hurt anything.
Paul
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
