One thing I didn't mention previously that should help clarify this -- the Registrar maintains the Call-Id and CSeq at the Contact-level granularity not at the AOR-level. This allows the out-of-order algorithm to work independently for each contact/binding. Assuming that different bindings for an AOR are owned by different UAs, one UAs Call-Id/Cseq tuple will not be overwritten by another UA.
One exception to this rule is 3rd party registrations. However, I'd imagine in such systems by design the 3rd party and the 1st party (the original UA on behalf of which the 3rd party is working) will not update registrations simultaneously stepping on each others Call-Id/Cseq. On 2/10/07, Rajnish Jain <[EMAIL PROTECTED]> wrote: > > Mahipati, > > I don't think this question has anything to do w/ the number of bindings > for an AOR. The reason why a Registrar keeps track of Call-Id and CSeq of > the last REGISTER request that did some kind of a write is to detect and > drop delayed or out-of-order requests from the same UA that were not caught > at the transaction layer. The keyword here is *same UA*. If a REGISTER > request (that is meant to do some kind of a write) is generated from a > separate UA, then obviously it'll pass the Call-Id check. > > Rajnish > > > On 2/8/07, Mahipati Deshpande <[EMAIL PROTECTED]> wrote: > > > > Are you allowing mutiple registration per AOR? > > If so, I think, your procedure to update registrar binding may not > > work. If you are supporting multiple registration per AOR, then you need to > > check contact URI too, before updating bindings. If contact URI is same and > > call-id differs, then update calli-id alos. If contact URI is different, > > then REGISTER request is from a new location, so you need to create another > > binding for the given AOR. > > > > Regards, > > Mahipati Deshpande > > > > > > > > ----- Original Message ---- > > From: Marco Ambu <[EMAIL PROTECTED]> > > To: SIP-implementors mailing list < [email protected]> > > Sent: Wednesday, 7 February, 2007 10:05:15 PM > > Subject: [Sip-implementors] How to update registrar bindings when > > Call-ID is different > > > > > > Hi, > > 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? > > > > Following is what I have understood from the paragraph above in > > pseudo-code. > > Is this procedure correct to handle registrar requests? > > ** > > if "binding_not_exists" > > insert binding > > else ("binding_exists") > > if "callID for existing_binding" != "callID for new binding" > > if "expireTime" == 0 > > remove binding > > else > > update binding <<-- update also call-ID value??? > > else > > if "CSeq OK" > > if "expireTime" == 0 > > remove binding > > else > > update binding > > else > > abort request > > ** > > > > thanks. > > -- > > > > Marco Ambu > > R&D Software Engineering > > Abbeynet S.p.A. - www.abbeynet.com <http://www.abbeynet.com> > > > > phone: +39 070 2339331 > > > > <http://www.marco_ambu.sitofono.it> > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > __________________________________________________________ > > Yahoo! India Answers: Share what you know. Learn something new > > http://in.answers.yahoo.com/ > > _______________________________________________ > > 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
