[Devel] REGISTER & contact maching

[Klaus Darilion]

I still do not get it. We have to start with an empty location table. 
Thus, no records yet.

phone1 registers -> 1 records
phone2 registers -> rule 2.2 matches, still 1 record

So how do we get the second record?

klaus

Bogdan-Andrei Iancu wrote:
> 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
>>>
>>>
>>
>>
> 
>