[Devel] Processing REGISTER requests

[Bogdan-Andrei Iancu]

Hi Dan,

please see my inline comments.

regards,
bogdan

Dan Pascu wrote:

>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:
>
>  
>
First let me make two things clear:
    1) by contact (which will be saved) I mean what the UAC sends and 
not the received address. you will have in UL the private contact all 
the time. This is what RFC says!
    2) if the private IP or port changes, the client *needs* to 
re-register with the new contact.

>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
>  
>
please read carefully the algorithm - *only* the IP is checked (only if 
more than one contact for the AOR matchs); So this is not the case

>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
>  
>
if the UAC uses a private IP, than the contact will match (it will be 
private); if more than one equal contact  are found, the received IP and 
callid will be used. So, no problem.
If the UAC use public IP, the UAC must re-register. So, no problem.

>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.
>  
>
fix_contact() must not be used in contact of registration - the contact 
sent by the UAC must be saved all the time.

>
>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).
>  
>
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.

>
>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)
>  
>
Again, please read carefully the algorithm. As said in step B), the 
saved contact is contact sent by UAC. Also, I made clear above that 
fix_contact() must not be used in registration context.

>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.
>  
>
this is explained above - it will not happen.

>3. There can be multiple phones with the same AOR in multiple networks 
>   using the possible same private IP address.
>  
>
Again, please read carefully the algorithm. As said in step B), the 
saved contact is contact sent by UAC. The difference will be the 
received IP.

>What you propose only works if we use fix_nated_register. 
>  
>
of course - see the top clarifications.

>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.
>  
>
I agree, this should be transparent, but this is another topic and let's 
try to fix first the matching algorithm.

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