[Devel] REGISTER & contact maching

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Nov 25 16:38:15 CET 2005


By using only IP you avoid to consider different records a phone that 
gets assigned by NAT different ports for each REGISTER.

Since you do not relay only on rvc IP, but in combination with contact , 
the only corner case which is not covered is when you have phones of 
same user behind two level nats which are using same IP range and by 
change the phones got the same IP......I think this is a very corner case..
If you are not comfortable with this, use alg 3.

As I said, based on the knowledge about the network and used phones, you 
have to choose the best alg for you.

bogdan

Dan Pascu wrote:

>On Wednesday 23 November 2005 20:13, Bogdan-Andrei Iancu wrote:
>  
>
>>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? ;)
>>    
>>
>
>I still don't like the idea of matching only the received IP (where you 
>use this kind of test) and ignore the port. It gives a big uncertainty 
>and can fail for multiple levels of NAT.
>
>  
>
>>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
>>>>>>            
>>>>>>
>>_______________________________________________
>>Devel mailing list
>>Devel at openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/devel
>>    
>>
>
>  
>




More information about the Devel mailing list