[Devel] Processing REGISTER requests

[Klaus Darilion]

Hi Dan!

I think this is something that should be addressed. I just want to 
mention, that the matching algorithm should work also in scenarios where 
fix_contact is not used, but fix_natted_register which stores the public 
IP:port in AVPs.

regards
klaus

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