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

Reply via email to