Hi Dale, here is another question for register request: if we have 1 binding for AOR_1 to (callID_1, contactURI_1, ...) and we receive another REGISTER request for AOR_1 with callID_2 and contactURI_2 but the expiration time is not zero, should we just update AOR(callID_1, contactURI_1) to AOR( (callID_2, contactURI_2)? or add a new binding and the binding becomes to AOR_1( (callID_1, contactURI_1), (callID_2, contactURI_2))?
thanks On 2/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > From: Marco Ambu <[EMAIL PROTECTED]> > > implementing a registrar server we found some problems with this part of > RFC 3261 - 10.3 (page 66): > "For each address, the registrar then searches the list of > current bindings using the URI comparison rules. If the > binding does not exist, it is tentatively added. If the > binding does exist, the registrar checks the Call-ID value. If > the Call-ID value in the existing binding differs from the > Call-ID value in the request, the binding MUST be removed if > the expiration time is zero and updated otherwise." > > For example if we have 1 binding for AOR_1 to (callID_1, contactURI_1, > ...) > and we receive another REGISTER request for AOR_1 with callID_2 and > contactURI_1 but the expiration time is not zero, we should update the > binding. > > Must we update also the call-ID value? from CallID_1 to callID_2? > > Yes, you should, and you should store the CSeq. > > I believe that the point of the rule is not that a change in call-id > causes something strange to be done in regard to updating the binding. > Note that "must be removed if the expiration time is zero and updated > otherwise" is what would happen with an ordinary REGISTER. The idea > is that if the call-id changes, the usual check for out-of-order CSeq > values is bypassed. If the call-id changes, the last received > REGISTER is assumed to update any previously received REGISTER. But > if the call-ids are the same, ordering is done via cseq. > > This rule makes the situation of a rebooted UA work correctly. > > Dale > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
