[Devel] Re: Devel Digest, Vol 5, Issue 2

Tue Oct 4 16:59:07 CEST 2005

On 10/04/05 17:20, Adrian Georgescu wrote:

> Daniel, the point is to improve the way the registration is saved now  
> in OpenSER. This is an implementation issue of how to make the proxy  
> work better regardless of any Internet Drafs. What Dan proposed into  
> consideration the Registrar will be more accurate in real life  
> deployment, the observation was made based on real data.

Yes, I know that, but these are results based on several observations. 
As I said, my observations concluded to same result and, perhaps, many 
people can confirm same result. Anyhow, I am not sure that someone took 
the time to do real research for this case (testing many devices, 
rebooting them, ... -- nothing fancy, just usual cases). Do not forget 
that a lot of phones generate same call-id (if I recall correctly 
granstream phones had/have this problem).

What I wanted to point out is whether this approach worth to be 
implemented or not. This issue must be addressed somehow, but what is 
the best option?!?!

Cheers,
Daniel

>
> Regards,
> Adrian
>
>> 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
>>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>
>>
>> End of Devel Digest, Vol 5, Issue 2
>> ***********************************
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>