[Devel] Processing REGISTER requests
Daniel-Constantin Mierla
daniel at voice-system.ro
Thu Oct 6 14:24:36 CEST 2005
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
>>
>>
>
>
>
More information about the Devel
mailing list