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:[EMAIL PROTECTED]
phone2: NAT yyy.yyy.yyy.yyy ;private IP 192.168.3.4 ->
contact = sip:[EMAIL PROTECTED]
so, for AOR [EMAIL PROTECTED], 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:[EMAIL PROTECTED] 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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
