Hi,
I'm currently using the pcscf modules to build an IMS proxy. The pcscf_is_registered() function uses the source IP, port and protocol to search a record in the pcscf location database. In my case, I could have to deal with several UACs using the same source IP and ports, so this approach won't work for me.
The pcscf location database is indexed by the contact URI hash, so is there a reason not to use the contact URI to do the lookup? Besides, this should increase the performances when dealing with hundreds of records (the ip/port/protocol lookup is linear).
Regards,
Hi Camille,
i'll take a look at that. 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...
Kind regards, Carsten
2013/11/6 Camille Oudot camille.oudot@orange.com:
Hi,
I'm currently using the pcscf modules to build an IMS proxy. The pcscf_is_registered() function uses the source IP, port and protocol to search a record in the pcscf location database. In my case, I could have to deal with several UACs using the same source IP and ports, so this approach won't work for me.
The pcscf location database is indexed by the contact URI hash, so is there a reason not to use the contact URI to do the lookup? Besides, this should increase the performances when dealing with hundreds of records (the ip/port/protocol lookup is linear).
Regards,
-- Camille
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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,
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
Le Mon, 9 Dec 2013 23:30:44 +0100, Carsten Bock carsten@ng-voice.com a écrit :
Hi Camille,
i've changed it in GIT master to the following behaviour:
- 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.
Hi Carsten,
this looks nice, thanks. As Hugh Waite pointed, getContactP() always fails (no fallback) when no Contact header is present, and would prevent from using pcscf_is_registered() and pcscf_assert_identity() to be used on Contact-less requests. For my use, this is not a problem, and I see the fallback method as a potential way to make DoS attacks on a P-CSCF, when a lot of contacts are registered, since id does a sequential search, so I would rather not use it at all.
Maybe this fallback behavior should be made optional by configuration. I'll add this when possible.
Cheers
Hi Camille,
i've just made the fallback configurable (default: off) in git-master. I will commit the change later.
Thanks & merry christmas, Carsten
2013/12/11 Camille Oudot camille.oudot@orange.com:
Le Mon, 9 Dec 2013 23:30:44 +0100, Carsten Bock carsten@ng-voice.com a écrit :
Hi Camille,
i've changed it in GIT master to the following behaviour:
- 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.
Hi Carsten,
this looks nice, thanks. As Hugh Waite pointed, getContactP() always fails (no fallback) when no Contact header is present, and would prevent from using pcscf_is_registered() and pcscf_assert_identity() to be used on Contact-less requests. For my use, this is not a problem, and I see the fallback method as a potential way to make DoS attacks on a P-CSCF, when a lot of contacts are registered, since id does a sequential search, so I would rather not use it at all.
Maybe this fallback behavior should be made optional by configuration. I'll add this when possible.
Cheers
-- Camille
-
Camille Oudot -
Carsten Bock