[Devel] Processing REGISTER requests

Dan Pascu dan at ag-projects.com
Tue Oct 11 12:54:03 CEST 2005


On Tuesday 11 October 2005 12:13, Bogdan-Andrei Iancu wrote:
> Here is the idea we came up is:
>     A) as done so far, based on the AOR, we get the set of contacts
> registered by a user - this dismissed case 3) which cannot happen at
> all. B) the first used element will be the contact (what was registered
> by the client). why?
>                 - this it's what the RFC says
>                 - since this info is all the time present
>         the contact matching will be done via complete string
> comparison. After this step, you may have sublist of records having the
> same contacts (as pointed out in case 2) )
>     C) to received IP matching - use only the IP part of the received
> address. This check will solve the case 2). Why only the IP part and
> not also the port? in order to avoid seeing as separate records same
> contact which was routed by the NAT via separate ports (as it was
> pointed out in case 1) )

This won't work, as the IP address may change as well. There are 2 cases 
here:

1. the port changes as a result of the NAT box relocating the mappings.
   1st time 1.2.3.4:5060 next time 1.2.3.4.1025 then 1.2.3.4:1031

2. the ip address changes because the adsl connection is reset and you 
receive a new IP address. in this case the port may change as well but it 
may not.
   1st time 1.2.3.4:5060 then 1.2.7.8:5060 then 1.2.9.10:1031

You cannot rely on anything remaining the same, except the private contact
But if in addition you use fix_contact() with register, then the contact 
you check is also completely changed from the previous register because 
the private contact was overwritten and the received address changed.


I think that Klaus' suggestion is the best approach. Store the private 
contact unmodified, plus the received ip/port in the user location table.
That way we can compare the private contact which should never change, 
then use the callid to isolate possible multiple clients with the same 
AOR in different networks. IP/port checks have a high risk of failure and 
should be used only as a last resort after anything else failed (if 
IP/port didn't change you have a chance to catch them with ip/port 
comparison, else in the worst case you end up with a duplicate entry).


To make the picture clear, I have this case which won't work with the 
proposed check order (it will stop after step B considering it a new 
contact):
1. Use fix_cotact() with register (safer to have multiple contacts with a 
   phone than to have them overwritten as with fix_nated_register)
2. The same phone may come with every register from a different IP/port
   1st 1.2.3.4:31257, 2nd 5.6.7.8:21483, 3rd 2.5.3.8:12567, ...
   When this happens they shouldn't have multiple entries in usrloc,
   because it's the same phone.
3. There can be multiple phones with the same AOR in multiple networks 
   using the possible same private IP address.

What you propose only works if we use fix_nated_register. 

Now why can't we simply store all the info (private contact + received 
address in usrloc) and avoid any need to use fix_contact() or 
fix_nated_register() on a REGISTER request?
If the contact is marked as nated (by setting the nat flag) then 
mediaproxy/nathelper should use the received IP/port stored in usrloc
All this should be done transparently IMO. Manually calling fix_xxx() with 
a register request shouldn't be needed.

>     D) so far the algorithm will be able to properly match the contact,
> excepting one case: if you have a 2 level nat where the second levels
> have same network configuration and you have same phone with same user
> is each of this networks, the contacts will be identical and the
> outside IP the same - the port will be different, but this will be
> ignore by step C). In this case, do a further Call-ID matching.
>
> I think this algorithm covers as may problems as possible, and it's
> also reasonable as logic (the selection steps and RFC compliance).
>
> if there are some aspects that were missed or some space for
> improvements, we will be happy to fix it.
>
> regards,
> bogdan

-- 
Dan



More information about the Devel mailing list