[Devel] REGISTER & contact maching

[Bogdan-Andrei Iancu]

Hi Klaus,

it can happen...if you have a user (userX) with 2 phones behind NATs 
with same configuration:

    userX
          phone1: NAT xxx.xxx.xxx.xxx ;private IP 192.168.3.4 -> contact 
= sip:userX at 192.168.3.4
          phone2: NAT yyy.yyy.yyy.yyy ;private IP 192.168.3.4 -> contact 
= sip:userX at 192.168.3.4

so, for AOR userX at domian, you will have two identical records (as contact).

The idea is not to refresh in this context, but to keep two records 
(differentiated by source IP and callid). After all there are 2 separate 
phones. That's the idea behind (2.1).


now...about using IP:port ...port is not reliable to be used since it 
may be changed by NATs; Scenario: a phone registers contact 
sip:userX at 192.168.3.4 and get external bind on xxx.xxx.xxx.xxx:5060; if 
the phone is crashes or powers down, etc and register again with same 
contact, but it will may get a different bind xxx.xxx.xxx.xxx:5061. In 
this case is essential to match the original contact and to perform 
refresh instead of adding a new contact record - especially in 
configurations where multiple registrations are forbidden.
 
I'm still doing some research on this topic - Daniel pointed me out an 
interesting section in RFC 10.3.

regards,
bogdan

Klaus Darilion wrote:

> 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
>>
>>
>
>