[Devel] Processing REGISTER requests

[Daniel-Constantin Mierla]

Hello,

the call-id is not reliable, as the rfc says "SHOULD", I also checked 
that the sip phones usually uses the same call-id, but in the case of a 
sipphone crash, upon restart/reboot you will get another SIP id, which, 
indeed, should be a new registration, but looking from user's point of 
view is an update. I think that is the reason the RFC keeps "SHOULD" 
there, although would have been more convenient to be "MUST".

There is a draft which adds an extension to identify the devices:
http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance-id-01.txt

It will be added when after the release.

Cheers,
Daniel


On 10/03/05 11:37, Klaus Darilion wrote:

> 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).
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>