[Devel] Processing REGISTER requests

[Bogdan-Andrei Iancu]

Hi everybody,

there was some bandwidth used on this topic, so let us focus on 
practical solution which should solve the problems that were pointed 
out, in a simple as possible manner.

I had a talk with Daniel, and based on what was discussed so far on this 
thread, we tried to put things together and come up with a better 
matching algorithm.  I will use as reference  Dan's email since it's a 
good  resume of the problems.

Shortly: we have couple of elements which can help identifying properly 
the contact - the contact, the received address and the call-id. The 
idea is how to use them (in what order) in order to be as close as 
possible to the RFC specs, to do a matching in the most cases and to 
have a fast matching also.

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


Dan Pascu wrote:

>I've checked the registrar module and noticed that openser uses only the 
>contact to match a REGISTER request against an older REGISTER request (that 
>is to know if it has to add an entry to user location or if it has to update 
>an older entry).
>
>Now I think there are several problems with this approach and I can outline 3 
>here (all refer to cases where phones are behind NAT):
>
>1. If you save the contact after calling fix_contact() you get the NAT address 
>in the user location, but this address may change from one REGISTER request 
>to another. I've seen this case with a NAT that uses a different port every 
>request and that phone ended up with 200 contacts in the user location table.
>This is not something you'd want in your user location table, even though the 
>proxy and phone will work correctly: the proxy will send 200 INVITE request 
>when someone calls that phone and the phone will pick one branch to answer 
>and reject the other 199, but the traffic is multiplied by 200.
>
>2. If you save the unmodified contact (the private address behind NAT) then 
>there is a chance of contact collision. Consider someone with a SIP account 
>and multiple phones in different locations. If he uses the same private IP 
>address in multiple networks for his phones, those phones will overwrite each 
>others entries in usrloc and only 1 phone will be available at a time (the 
>one that sent the last REGISTER request).
>You may think that this situation is very rare, but I think it has big chances 
>to appear because people tend to standardize the environment they work in for 
>simplification. This makes it very likely that someone will use the same 
>network classes in setting up private networks in different locations and 
>that he uses the same IP addresses for his phones in those locations, so he 
>knows that his phone is always found at the same address no matter what 
>network he is in.
>
>3. If you save the unmodified contact (the private address behind NAT) then 
>there is another chance of collision: if the proxy serves multiple domains 
>and there are 2 users with the same username but in different domains and 
>they use the same private IP address for their phone then both contacts will 
>look like sip:username at ip:port and they will overwrite each others 
>subscription as explained above.
>
>To overcome these problems I think we should use a different approach to 
>identify the phone to which a REGISTER request belongs to. I've checked the 
>RFC and there is the following recommendation for the Call-ID and CSeq fields 
>with REGISTER requests:
>
>      Call-ID: All registrations from a UAC SHOULD use the same Call-ID
>           header field value for registrations sent to a particular
>           registrar.
>
>           If the same client were to use different Call-ID values, a
>           registrar could not detect whether a delayed REGISTER request
>           might have arrived out of order.
>
>      CSeq: The CSeq value guarantees proper ordering of REGISTER
>           requests.  A UA MUST increment the CSeq value by one for each
>           REGISTER request with the same Call-ID.
>
>As you can see they recommend (not mandate) that phones use the same callid 
>for a given registrar. I've checked with the phones and almost all of them 
>follow this recommendation.
>
>So I think we can use this in our advantage, by first checking the callid and 
>if it's the same and the cseq is bigger than the old one, then update that 
>entry and also overwrite the contact with the new one if different. Next, if 
>there is no entry with that callid but there is an entry with the same 
>contact field than update that entry. Of course we can use extra checks like 
>cseq shouldn't be bigger than old_one+2, or that contact is the same with old 
>one if using private IPs to make sure we find the right entry, but overall 
>this way we have less chances to get the wrong entry than currently.
>
>Using this we can eliminate the above mentioned problems for phones that 
>follow the RFC recommendation, while for the others we continue to function 
>the same way as before.
>
>I've checked the user agents in use on my platform and how they behave in this 
>regard and among them I found only one which doesn't follow this 
>recommendation (DrayTek UA versions 1.1.5 through 1.2.1) and a lot that do 
>(over 41 different user agents).
>
>  
>