Tang Xi wrote:
> 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)?
No
or add a new binding and the binding becomes
> to AOR_1( (callID_1, contactURI_1), (callID_2, contactURI_2))?
Yes. This should be clear from 3261.
Paul
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
