[Devel] Processing REGISTER requests

[Daniel-Constantin Mierla]

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