Re: [Devel] Processing REGISTER requests
Hi Dan! Would you provide a patch? Because there are other important things that should be added and I do not want our developers to get overloaded (too much). klaus Dan Pascu wrote: On Thursday 06 October 2005 19:07, Klaus Darilion wrote: First registration. Phone 1: callid = somecallid cseq = 101 ip = 10.0.0.1 port = 5060 Ok! Now the second phone will register: Phone 2: callid = anothercallid cseq = 101 ip = 10.0.0.1 port = 5060 Now ser will use your algorithm: 1. Check for callid: not found 2. if previous step failed to find an entry use the current algorithm to lookup by contact. This will match the registration from phone 1. Thus, combining call-id and the existing algorithm won't work! That's true if you use fix_nated_register() and store private contacts, but still this will improve the case where you store public contacts. Overall won't work worse, but the same or better. I don't claim it's a panacea. ___ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
Re: [Devel] Processing REGISTER requests
Are you sure that 98% implements it? There are different phones that generate same call-id, maybe that's the charm of SIP, nothing is reliable 100% :-) ... never boring ... all the time something to fix ... I understood that you propose to lookup by call-id only, otherwise I see no sense to do the lookup based on (call-id, contact address) since the contact is different (due to port change, in this case) = never matches. Maybe you can sketch the lookup algorithm so I understand better what you propose and we can spot the proper solution. I met the situation when same call-id was used by many phones and a lot of contact addresses were registered. The short term solution was to lower the expire interval to reduce the number of stored contact addresses. Cheers, Daniel On 10/04/05 17:53, Dan Pascu wrote: On Monday 03 October 2005 21:01, Daniel-Constantin Mierla wrote: Hello, the call-id is not reliable, as the rfc says SHOULD, I also checked It doesn't matter how reliable is. The whole point of my proposal was to improve the behavior for those phones that respect this recommendation and keep the current behavior for those that don't. I didn't propose that we replace the current lookup-by-contact with lookup-by-callid, I proposed to use the 2 together to improve the accuracy. And as a matter of fact 98% of the phones implement this recommendation which means it would improve behavior for 98% of the cases. I'd say it's reliable enough to worth it. 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, This is not even an example against using callid. If the phone crashed/is restarted it will have a new callid indeed but most likely the same contact and because we use callid together with contact in the lookup we will correctly identify the usrloc entry even across restarts/crashes. Now even if we assume it wouldn't identify them correctly (but it does) still this is a marginal behavior not the rule. How many times does a phone crash or is restarted in a row? 5? 10? 20? Then if both callid and contact are changed you end up with 20 records in usrloc for the registration period. This happens so rarely I don't care. But currently I have phones that because of broken NATs have 200 contacts in my database 24/7 for a single phone. 20 contacts on occasion do not bother me. 200 all the time do. 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 It will be an update, because failing callid match it will use contact match which will succeed. 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-0 1.txt It will be added when after the release. That's very nice, but I don't think this will fix the 200 contacts problem, or any other of the mentioned problems, since this draft is currently not implemented by any phone. And in 2 years from now I don't think that more than 40% of phones will use this. The point is to improve behavior with existing phones and alleviate current problems. Using callid together with contact can do this right now and as phones will start implementing that draft (which may take a long time) they will benefit from that solution which will be even better. But I don't see any of these mutually exclusive, so why shouldn't we use all of them together if they can improve things? Cheers, Daniel ___ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
Re: [Devel] Processing REGISTER requests
Daniel-Constantin Mierla writes: I understood that you propose to lookup by call-id only, otherwise I see no sense to do the lookup based on (call-id, contact address) since the contact is different (due to port change, in this case) = never matches. i thought that one of the purposes of the gruu stuff is to identify a particular sip ua instance and it might also help to solve dan's problem. -- juha ___ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
Re: [Devel] Processing REGISTER requests
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:[EMAIL PROTECTED]: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
