[Devel] REGISTER & contact maching
Dan Pascu
dan at ag-projects.com
Wed Nov 23 22:14:33 CET 2005
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
--
Dan
More information about the Devel
mailing list