[Devel] REGISTER & contact maching

Dan Pascu dan at ag-projects.com
Wed Nov 23 22:11:57 CET 2005 

On Friday 18 November 2005 13:16, Bogdan-Andrei Iancu wrote:
> ups.....you have a point here....I will have to re-evaluate the
> algorithm...
>
> nice catch ;)

As I said in a previous email, you should not attempt to use the received 
IP alone (without port) in tests, because instead of reducing the space 
you search in, you increase the uncertainty (behind each IP there are 
possibly more than 65000 users).

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