[Devel] Processing REGISTER requests

[Daniel-Constantin Mierla]

Hello,

On 10/06/05 11:14, Dan Pascu wrote:

>On Wednesday 05 October 2005 11:28, Klaus Darilion wrote:
>  
>
>>Hi!
>>
>>I'm trying to summarize things. So, how can we match re-REGISTER to a
>>previous REGISTER.
>>    
>>
>
>Thanks for your support, but right now I think that you and me are the 
>only ones that have an interest in this discussion.
>
>  
>
>>1. Call-ID:
>>  +: RFC conform
>>  -: Some phones use same call-id. Thus, if a user has 2 phones from
>>the same brand, they will interfere.
>>    
>>
>
>I assume that who said this meant that the same phone can reuse the 
>call-id, not that different phones can use the same call id which is not 
>really a problem. If what he meant was that different phones reuse the 
>same call-id I'd like to see some evidence of this because it hasn't 
>happen in my experience. I have seen the same phone reuse a call-id for 
>different calls, but not that different phones use the same call-id.
>If this really happens, it must happen so rarely that I wasn't able to 
>detect it until now.
>  
>
since most of the phones uses the IP address in the call-id, the phones 
have to have same (private address) to have this collision. It is not a 
common usage scenario, but it happens.

>I have systematically traced the contacts database on a running platform 
>and out of 800 contacts generated by more than 40 different user agents, 
>there is not a single duplicate entry when considering the call-id + cseq 
>combination. If I consider the call-id alone there are between 3 and 7 
>call-id's that have 2 duplicate entries each, but not because different 
>phones used the same call-id. They are duplicated because the same phone 
>sent a REGISTER request from a different IP/port and was considered a 
>different registration by the current algorithm (something I'm trying to 
>avoid). The call-id is the same, the username and domain is the same, the 
>cseq is the old one + 2 and the user agent is the same, only the contact 
>differs in the IP/port. This happens because adsl providers reset 
>connections and offer them new IPs with DHCP once in a while, or because 
>some NAT boxes decide to use different ports when sending out a new 
>request. If the lookup by call-id were to be used these duplicates 
>wouldn't be there.
>
>Now if we put this in perspective, even if this is true, how often do you 
>expect it to happen? It amazes me how such a corner case, erratic and 
>non-reproduceable issue that _may_ appear once in the blue moon is 
>considered a show stopper. In comparison I can consistently and 
>persistently sabotage the current lookup algorithm in a reproduceable 
>way:
>
>If you use fix_nated_register() and save private contacts in your databse:
>
>1. take one sip account joe at domain.com and configure 2 phones in 2 
>different networks with that account and assign the same private IP to 
>both phones. They will overwrite each ones registration.
>  
>
With same private ip, the risk to have same call-id increases.

>2. take 2 sip accounts with the same username in 2 different domains say 
>joe at domains.com and joe at foo.com and do the same. Same outcome.
>  
>
In this case, I do not think so. You have to enable multidomain support 
in registrar/usrloc and then will be no overwrite. What you give as 
example is not a proper deployment and will break not only the 
registration, but everything related to these two users.

>  
>
>>2. Contact: IP address
>>  -: problems when 2 clients on the same IP address, NAT...
>>
>>3. Contact: IP address+port
>>  -: problems when 1 client with two lines on the same port, NAT...
>>
>>4. Contact: SIP URI
>>  -: problems when 2 clients behind different NATs with same private
>>SIP URI.
>>
>>5. src_IP:src_port
>>  -: problems when 1 client with two lines on the same port, NAT...
>>    
>>
>
>any IP/port based lookup is flawed from start. IP's may overlap in private 
>networks, and ports may change on the NAT box.
>People using fix_nated_register() are far worse exposed to the problem as 
>phones may overwrite each other's registration in this case, but they 
>can't get duplicate entries.
>People using fix_contact() on the other hand are immune to contact 
>overwriting but they suffer from the multiple entries for the same phone 
>problem. Which is not as bad as contact overwriting, more of an 
>annoyance.
>  
>
Agree, it is what I want to avoid, better have multiple contact 
addresses rather that overwrite other's contact. Lowering the expire 
interval (this can be controlled from openser 
http://openser.org/docs/modules/0.10.x/registrar.html#AEN83) will 
decrease the number of registered contacts.

>  
>
>>6. "public URI" username at src_IP:src_port
>>  -: some broken NATs tend change the src_port for every request
>>leading to multiple entries
>>
>>Thus, 1 and 6 are useful methods. But I see no way to combine them.
>>Either we use 6 or 1. Dan, do you see a way to combine them?
>>    
>>
>
>I already said in my first email what algorithm I'd use and how to combine 
>them and I still think that is a far better solution than what we have 
>even if it _may_ suffer from these corner case issues (though I haven't 
>seem these issues manifest in my experience).
>  
>
All of these SIP problems could be considered "corner case", it is up to 
each one's experience and deployment infrastructure. If would be a 
common case most of the people will complain about. I do not want o 
generalize personal experiences to go over specifications and lose time 
implementing something which does not work. We should first discuss and 
find the proper solution.

I am advocating that call-id and cseq (username+domain are taken in 
consideration anyhow, useragent does not add much accuracy) are not 
reliable and prefer to keep the expire value to low values to get rid a 
bit of this problem. I do not say that my opinion is the best and 
correct, and I do not see a clear solution right now, so we have to 
figure out what is the best possible.

Cheers,
Daniel


>Anyway since everybody seems to have missed that I'll put it here again:
>
>1. look for and entry that has the same username, domain, call-id and 
>user-agent plus a cseq that is greater than the previous one. Eventually 
>put a limit of how greater it can be to make this more accurate.
>Say old + 2 (because of an auth request there may be 2 REGISTER requests 
>per registration - I'm not sure if anybody uses something where more than 
>2 REGISTER requests are sent per registration; if so we can increase this 
>limit)
>Also if fix_nated_register() is used and the contact is private we can 
>also require that the contact is the same since that should not change 
>from one request to another.
>
>2. if previous step failed to find an entry use the current algorithm to 
>lookup by contact.
>
>3. if both steps failed consider it a new entry.
>
>  
>
>>regards
>>klaus
>>    
>>
>
>  
>