[Devel] Processing REGISTER requests

[Klaus Darilion]

Hi!

I'm trying to summarize things. So, how can we match re-REGISTER to a 
previous REGISTER.

1. Call-ID:
  +: RFC conform
  -: Some phones use same call-id. Thus, if a user has 2 phones from the 
same brand, they will interfere.

2. Contact: IP address
  -: problems when 2 clients on the same IP address, NAT...

3. Contact: IP address+port
  -: problems when 1 client with two lines on the same port, NAT...

4. Contact: SIP URI
  -: problems when 2 clients behind different NATs with same private SIP 
URI.

5. src_IP:src_port
  -: problems when 1 client with two lines on the same port, NAT...

6. "public URI" username at src_IP:src_port
  -: some broken NATs tend change the src_port for every request leading 
to multiple entries

Thus, 1 and 6 are useful methods. But I see no way to combine them. 
Either we use 6 or 1. Dan, do you see a way to combine them?

regards
klaus


Dan Pascu wrote:
> On Tuesday 04 October 2005 18:32, Daniel-Constantin Mierla wrote:
> 
>>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'm very sure. I have only one phone that has CSeq=101 in the database all 
> the time, all the others have a CSeq that is incremented by each 
> register. It's all in my first email.
> 
> 
>>...
>>
>>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'm a bit surprised and disappointed at this point. You are hammering down 
> my proposal while you don't seem to know what it contains. I didn't 
> propose to replace lookup-by-contact and I didn't propose to do the 
> lookup using both the callid and contact at the same time (that wouldn't 
> make any sense). The algorithm I proposed is in my first email and I 
> don't want to replicate it here. We may be able to continue this 
> discussion after you read it because till now you dismissed 2 solutions I 
> never proposed.
> 
> 
>>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.
> 
>