[Devel] REGISTER & contact maching

[Klaus Darilion]

Hi Bogdan!

If I understand the algorithm correctly, 2.1 can never happen.

1 user, 2 phones: the first phone registers -> rule 2.3 will be used

the second phone registers (same NAT settings, same private IP:port)
--> rule 2.2 will be used, the existing contact will be refreshed.

Thus, with this algorithm there can't be 2 matching records (2.1)

Why not use always the rcv_ip:rcv_port instead of the real contact?

regards
klaus

Bogdan-Andrei Iancu wrote:
> 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
>                
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
> 
>