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

[Adrian Georgescu]

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.

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