[Devel] REGISTER & contact maching

[Bogdan-Andrei Iancu]

Hi,

I would like to bring into attention an issue that was large debated 
previously, but postponed for after the released : contact matching in 
USRLOC.

There are several problems with the current mechanism, problems well 
underlined by Dan in his original email:
    http://openser.org/pipermail/devel/2005-October/000645.html

the discussion stuck when came about the new matching algorithm. The 
basic idea is to use more info for matching: now only contact is used 
and the idea is to expend it to (contact, callid, source_addr). there 
were several proposal about the matching algorithms , each being 
different by the ordering of the info to be used for matching.

I thing the top requirement for the new algorithm is efficiency (as it 
is for the rest of openser): so the algorithm must be optimised for the 
general cases and in the same time to be able to cope with al corner cases.

Based on this, and on former proposal from Dan an Klaus, I suggest the 
following algorithm:
    1) once the AOR is identified, we have a set of records (with 
contacts, callids, source IP, etc)
    2) at first step use the contact. The result may be:
          2.1) several records match (that may be the case of a client 
registering from behind NATs with same configurations)
          2.2) one record matched -> match; exit;
          2.3) none -> no match; exit!
    3) if we have more than one record matching so far, we will use the 
source IP (only IP without port); this will be able to distinguish 
between the contacts of same client registered from behind NATs with 
same configurations; see 2.1) . Why only the IP part and not also the 
port? in order to avoid seeing as separate records same contact which 
was routed by NAT via different ports - avoid record duplication. The 
result may be:
          3.1) several records still match (that may be the case of a 
client registering from behind
               NATs - more than one level- with same configurations)
          3.2) one record matched -> match; exit;
          3.3) none - source IP changed
    4) for 3.1) and 3.3) cases proceed with callid matching. The result 
may be:
          4.1) more than one...I thing is rather bogus, but we can 
choose the first one -> matched ; exit
          4.2) one -> matched ; exit
          4.3) none -> not matched ; exit

looks complicated, but not so much. The general cases will exit via 2.2) 
or 2.3). Then "common" corner cases generated by NATs will exit via 3.2) 
and highly corner cases (multiple level NAT with special config  + IP 
changing) will exit via 4.2) or 4.1)


I would like to have some comments on this like:
    case which are not covered (example please)
    optimisation (example please)

...and to proceed to facts ;)


regards,
bogdan

PS: no reply means everybofy agree eith it :D