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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] and [EMAIL PROTECTED] 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" [EMAIL PROTECTED]: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 _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
