Hi Camille,
i've changed it in GIT master to the following behaviour:
1) Lookup based on Contact 1a) compare Received-Info (IP, Port, Proto), if Contact was found 2) Fallback to the old behaviour (directly looking for IP, Port, Proto) otherwise.
I've also changed the pcscf_assert_identity to do the lookup based on the contact.
If you modify the INVITE for initial requests (e.g. use a contact-alias "add_contact_alias()" for NAT-Traversal), you'll have to apply the changes first before you can do the check. I've added a warning, in case the lookup based on the contact fails. I've tested the changes with CSipSimple, Snom phones and AVM FritzBox.
Kind regards, Carsten
2013/11/27 Camille Oudot camille.oudot@orange.com:
Le Wed, 27 Nov 2013 18:30:32 +0100, Carsten Bock carsten@ng-voice.com a écrit :
Hi Carsten,
I've implemented it that way in order to cope with NAT; however i can probably simply replace it with the "add_contact_alias()" functions from Nathelper...
so, maybe the pcscf_is_registered() function could: * retrieve the pcontact record in O(1) using the Contact URI hash [should pcscf_is_registered() fail if no there is no Contact header? Could the Contact URI somehow change between REGISTER and other requests?] * compare the request's source ip & port with those stored in the pcontact record * if both steps succeed, return true
This should prevent performances issues if a lot of contacts are registered. Besides, this would allow to differentiate several UACs using the same network connection (as they very likely would provide different contact URIs). What do you think of this?
Cheers,
Camille