[Devel] Processing REGISTER requests

[Dan Pascu]

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.

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.

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.

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

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

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

-- 
Dan