[Devel] REGISTER & contact maching

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Nov 23 19:13:29 CET 2005 

Hi again,

after an intensive brainstorming with Daniel on this topic we come to 
the conclusion that you cannot make a generic algorithm to make 
everybody happy. So, we suggest a set of matching algorithms ; everybody 
will feel free to choose the one which fits better to his case.

0. 100% RFC compliant alg.
    A = filter_by_contact( AOR set);
    if (A==0) insert
        else update (with validity checking on callid and cseq)

1. received based extension on alg. 0
    A = filter_by_contact_and_receivedIP( AOR set);
    if (A==0) do_insert
        else do_update (with validity checking on callid and cseq)

2. callid based extension on alg. 0
    A = filter_by_contact_and_callid( AOR set);
    if (A==0) insert
        else update (with validity checking on cseq)

3. received&callid based extension on alg. 0
    A = filter_by_contact_and_receivedIP( AOR set);
    if (A==0)
        A = filter_by_contact( AOR set);
    A = filter_by_callid(A);
    if (A==0) do_insert
        else do_update (with validity checking on cseq)


this is a pseudo description of the algs. No 3 covers most of cases (IP 
changes, multiple NAT level, etc).

feedback? ;)

regards,
bogdan


Klaus Darilion wrote:

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

More information about the Devel mailing list