[Devel] Processing REGISTER requests

[Dan Pascu]

On Wednesday 12 October 2005 11:14, Dan Pascu wrote:
> > basically, it's very similar to what Klaus suggested - the difference
> > is I give more credit to received IP than to call-id, in the send the
> > I use first received IP and only if needed I use the call-id. Why? I
> > find more reliable to identify a UAC based on it's IP (it's change is
> > a corner case) than using call-id which is just a recommendation of
> > the RFC.

After thinking about this a bit more, I got an idea that can simplify my 
initial algorithm proposal. The reason I consider IP checks more 
unreliable than callid checks, is because the scenario I have shown, 
where you can see that they clearly fail and I have just realized the 
reason. Behind 1 IP you have a potential of 65000 clients. So if you only 
check for IP you have a very big uncertainty which makes is very 
unreliable. You considered it reliable only because you used a very 
specific scenario where IP checks were fine (the case where the client 
uses the same NAT and only the port changes). But as you can see in my 
example there are other scenarios where IP only checks are anything but 
reliable.

But the I realized that there is 1 case where IP checks can be made more 
reliable than callid checks: if we check both the IP and the port of the 
received request. That is quaranteed to not fail if the NAT address 
doesn't change. This is because while a client has a channel open in the 
NAT and is using that port, the same port cannot be assigned to a 
different client. This will only happen after the pinhole is closed but 
at that point I don't care if the contact is overwritten because the 
original client is no longer accessible.

So we can use this algorithm, which is simpler and addresses my example 
with equal success:

1. match contact (which is private). yields a list of contacts.
2. if 0 entries it's a new entry. add
3. if 1 entry, update that and stop
4. check if among the entries obtained at 3 we have one with the same
   received IP and port. If yes update it and stop
5. use callid to trim down the list obtained at point 3
6. if trimmed list has 0 entries, is a new entry. add
7. if trimmed list has 1 entry, update and stop
8. is trimmed list has more than 1 entry we have a conflict.

Now this may look a bit longer than the previous but is only because I 
detailed the steps more. In reality is shorter and simpler.
Now after step 8 we can try to match on received IP only to solve that 
conflict but because IP only is not reliable we may have little success 
and I'm not sure if we gain much by the extra test.


-- 
Dan