Clean expired SIP registrations of FS internal database
Hi, I have seen that in the FS internal database the account SIP registrations are stored during a lot of time and it seems that they are not deleted never. Is there any mode or parameter to automatically delete these database records after X time, by expired time or number of records for example? To be better explained, I refer to the SIP profile records that appear when the command is executed: fs_cli> sofia status profile external reg Thank a lot. Regards, José David Jurado Alonso.
On Tue, Feb 12, 2019, 15:13 Jose David Jurado Alonso <josedavid@zennio.com wrote:
Hi,
I have seen that in the FS internal database the account SIP registrations are stored during a lot of time and it seems that they are not deleted never.
You are registering on external profile. You are not supposed to. So, maybe there are not parameters for cleaning up. Look into internal profile configuration, and copy to external the relevant (to registration AND presence AND auth) parameters. Hth, -giovanni
Is there any mode or parameter to automatically delete these database records after X time, by expired time or number of records for example?
To be better explained, I refer to the SIP profile records that appear when the command is executed:
fs_cli> sofia status profile external reg
Thank a lot.
Regards,
José David Jurado Alonso. _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
Yes, I am using the external profile but it is a copy of the internal one. I imagine that having the desired configuration it is irrelevant to use one or the other. Can you tell me what parameters and exactly what values should be configured for cleaning? I have the next configuration file: <profile name="external"> <!-- http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files --> <!-- This profile is only for outbound registrations to providers --> <gateways> <X-PRE-PROCESS cmd="include" data="external/*.xml"/> </gateways> <aliases> <!-- <alias name="outbound"/> <alias name="nat"/> --> </aliases> <domains> <domain name="all" alias="false" parse="true"/> </domains> <settings> <param name="debug" value="0"/> <!-- If you want FreeSWITCH to shutdown if this profile fails to load, uncomment the next line. --> <!-- <param name="shutdown-on-fail" value="true"/> --> <param name="sip-trace" value="no"/> <param name="sip-capture" value="no"/> <!-- <param name="watchdog-enabled" value="no"/> <param name="watchdog-step-timeout" value="30000"/> <param name="watchdog-event-timeout" value="30000"/> <param name="forward-unsolicited-mwi-notify" value="false"/> --> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <!-- RFC 5626 : Send reg-id and sip.instance --> <!--<param name="enable-rfc-5626" value="true"/> --> <param name="sip-port" value="$${external_sip_port}"/> <param name="dialplan" value="XML"/> <param name="context" value="public"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${outbound_codec_prefs}"/> <param name="hold-music" value="$${hold_music}"/> <param name="rtp-timer-name" value="soft"/> <!--<param name="enable-100rel" value="true"/>--> <!--<param name="disable-srv503" value="true"/>--> <param name="local-network-acl" value="rfc1918.auto"/> <param name="apply-nat-acl" value="rfc1918"/> <!-- <param name="apply-register-acl" value="domains"/>--> <!-- This could be set to "passive" --> <param name="manage-presence" value="false"/> <!-- used to share presence info across sofia profiles manage-presence needs to be set to passive on this profile if you want it to behave as if it were the internal profile for presence. --> <!-- Name of the db to use for this profile --> <!--<param name="dbname" value="share_presence"/>--> <param name="presence-hosts" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <!--all inbound reg will stored in the db using this domain --> <!--<param name="force-register-db-domain" value="$${domain}"/>--> <!-- ************************************************* --> <param name="aggressive-nat-detection" value="true"/> <param name="inbound-codec-negotiation" value="generous"/> <param name="nonce-ttl" value="60"/> <param name="auth-calls" value="true"/> <param name="inbound-late-negotiation" value="true"/> <param name="inbound-zrtp-passthru" value="true"/> <!-- (also enables late negotiation) --> <!-- DO NOT USE HOSTNAMES, ONLY IP ADDRESSES IN THESE SETTINGS! --> <param name="rtp-ip" value="$${local_ip_v4}"/> <param name="sip-ip" value="$${local_ip_v4}"/> <param name="ext-rtp-ip" value="$${external_rtp_ip}"/> <param name="ext-sip-ip" value="$${external_sip_ip}"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <!--<param name="enable-3pcc" value="true"/>--> <!-- TLS: disabled by default, set to "true" to enable --> <param name="tls" value="$${external_ssl_enable}"/> <!-- Set to true to not bind on the normal sip-port but only on the TLS port --> <param name="tls-only" value="false"/> <!-- additional bind parameters for TLS --> <param name="tls-bind-params" value="transport=tls"/> <!-- Port to listen on for TLS requests. (5081 will be used if unspecified) --> <param name="tls-sip-port" value="$${external_tls_port}"/> <!-- Location of the agent.pem and cafile.pem ssl certificates (needed for TLS server) --> <!--<param name="tls-cert-dir" value=""/>--> <!-- Optionally set the passphrase password used by openSSL to encrypt/decrypt TLS private key files --> <param name="tls-passphrase" value=""/> <!-- Verify the date on TLS certificates --> <param name="tls-verify-date" value="true"/> <!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate --> <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe --> <param name="tls-verify-policy" value="none"/> <!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none --> <param name="tls-verify-depth" value="2"/> <!-- If the tls-verify-policy is set to subjects_all or subjects_in this sets which subjects are allowed, multiple subjects can be split with a '|' pipe --> <param name="tls-verify-in-subjects" value=""/> <!-- TLS version ("sslv23" (default), "tlsv1"). NOTE: Phones may not work with TLSv1 --> <param name="tls-version" value="$${sip_tls_version}"/> <param name="aggressive-nat-detection" value="true"/> <param name="multiple-registrations" value="true"/> <param name="ext-rtp-ip" value="$${external_rtp_ip}"/> <param name="ext-sip-ip" value="$${external_sip_ip}"/> <param name="NDLB-received-in-nat-reg-contact" value="true"/> <param name="NDLB-force-rport" value="safe"/> <param name="NDLB-broken-auth-hash" value="true"/> <param name="enable-timer" value="false"/> <param name="auth-calls" value="true"/> </settings> </profile> Thanks. Jose David Jurado Alonso El mar., 12 feb. 2019 a las 15:46, Giovanni Maruzzelli (<gmaruzz@gmail.com>) escribió:
On Tue, Feb 12, 2019, 15:13 Jose David Jurado Alonso <josedavid@zennio.com wrote:
Hi,
I have seen that in the FS internal database the account SIP registrations are stored during a lot of time and it seems that they are not deleted never.
You are registering on external profile. You are not supposed to. So, maybe there are not parameters for cleaning up.
Look into internal profile configuration, and copy to external the relevant (to registration AND presence AND auth) parameters.
Hth, -giovanni
Is there any mode or parameter to automatically delete these database records after X time, by expired time or number of records for example?
To be better explained, I refer to the SIP profile records that appear when the command is executed:
fs_cli> sofia status profile external reg
Thank a lot.
Regards,
José David Jurado Alonso. _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
_________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
Yes, I am using the external profile but it is a copy of the internal one and modified by me. I imagine that having the desired configuration it is irrelevant to use one or the other. Can you tell me what parameters and exactly what values should be configured for cleaning? I have the next configuration file: <profile name="external"> <!-- http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files --> <!-- This profile is only for outbound registrations to providers --> <gateways> <X-PRE-PROCESS cmd="include" data="external/*.xml"/> </gateways> <aliases> <!-- <alias name="outbound"/> <alias name="nat"/> --> </aliases> <domains> <domain name="all" alias="false" parse="true"/> </domains> <settings> <param name="debug" value="0"/> <!-- If you want FreeSWITCH to shutdown if this profile fails to load, uncomment the next line. --> <!-- <param name="shutdown-on-fail" value="true"/> --> <param name="sip-trace" value="no"/> <param name="sip-capture" value="no"/> <!-- <param name="watchdog-enabled" value="no"/> <param name="watchdog-step-timeout" value="30000"/> <param name="watchdog-event-timeout" value="30000"/> <param name="forward-unsolicited-mwi-notify" value="false"/> --> <param name="log-auth-failures" value="true"/> <param name="rfc2833-pt" value="101"/> <!-- RFC 5626 : Send reg-id and sip.instance --> <!--<param name="enable-rfc-5626" value="true"/> --> <param name="sip-port" value="$${external_sip_port}"/> <param name="dialplan" value="XML"/> <param name="context" value="public"/> <param name="dtmf-duration" value="2000"/> <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${outbound_codec_prefs}"/> <param name="hold-music" value="$${hold_music}"/> <param name="rtp-timer-name" value="soft"/> <!--<param name="enable-100rel" value="true"/>--> <!--<param name="disable-srv503" value="true"/>--> <param name="local-network-acl" value="rfc1918.auto"/> <param name="apply-nat-acl" value="rfc1918"/> <!-- <param name="apply-register-acl" value="domains"/>--> <!-- This could be set to "passive" --> <param name="manage-presence" value="false"/> <!-- used to share presence info across sofia profiles manage-presence needs to be set to passive on this profile if you want it to behave as if it were the internal profile for presence. --> <!-- Name of the db to use for this profile --> <!--<param name="dbname" value="share_presence"/>--> <param name="presence-hosts" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <!--all inbound reg will stored in the db using this domain --> <!--<param name="force-register-db-domain" value="$${domain}"/>--> <!-- ************************************************* --> <param name="aggressive-nat-detection" value="true"/> <param name="inbound-codec-negotiation" value="generous"/> <param name="nonce-ttl" value="60"/> <param name="auth-calls" value="true"/> <param name="inbound-late-negotiation" value="true"/> <param name="inbound-zrtp-passthru" value="true"/> <!-- (also enables late negotiation) --> <!-- DO NOT USE HOSTNAMES, ONLY IP ADDRESSES IN THESE SETTINGS! --> <param name="rtp-ip" value="$${local_ip_v4}"/> <param name="sip-ip" value="$${local_ip_v4}"/> <param name="ext-rtp-ip" value="$${external_rtp_ip}"/> <param name="ext-sip-ip" value="$${external_sip_ip}"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="1800"/> <!--<param name="enable-3pcc" value="true"/>--> <!-- TLS: disabled by default, set to "true" to enable --> <param name="tls" value="$${external_ssl_enable}"/> <!-- Set to true to not bind on the normal sip-port but only on the TLS port --> <param name="tls-only" value="false"/> <!-- additional bind parameters for TLS --> <param name="tls-bind-params" value="transport=tls"/> <!-- Port to listen on for TLS requests. (5081 will be used if unspecified) --> <param name="tls-sip-port" value="$${external_tls_port}"/> <!-- Location of the agent.pem and cafile.pem ssl certificates (needed for TLS server) --> <!--<param name="tls-cert-dir" value=""/>--> <!-- Optionally set the passphrase password used by openSSL to encrypt/decrypt TLS private key files --> <param name="tls-passphrase" value=""/> <!-- Verify the date on TLS certificates --> <param name="tls-verify-date" value="true"/> <!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate --> <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe --> <param name="tls-verify-policy" value="none"/> <!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none --> <param name="tls-verify-depth" value="2"/> <!-- If the tls-verify-policy is set to subjects_all or subjects_in this sets which subjects are allowed, multiple subjects can be split with a '|' pipe --> <param name="tls-verify-in-subjects" value=""/> <!-- TLS version ("sslv23" (default), "tlsv1"). NOTE: Phones may not work with TLSv1 --> <param name="tls-version" value="$${sip_tls_version}"/> <param name="aggressive-nat-detection" value="true"/> <param name="multiple-registrations" value="true"/> <param name="ext-rtp-ip" value="$${external_rtp_ip}"/> <param name="ext-sip-ip" value="$${external_sip_ip}"/> <param name="NDLB-received-in-nat-reg-contact" value="true"/> <param name="NDLB-force-rport" value="safe"/> <param name="NDLB-broken-auth-hash" value="true"/> <param name="enable-timer" value="false"/> <param name="auth-calls" value="true"/> </settings> </profile> Thanks. El mar., 12 feb. 2019 a las 15:46, Giovanni Maruzzelli (<gmaruzz@gmail.com>) escribió:
On Tue, Feb 12, 2019, 15:13 Jose David Jurado Alonso <josedavid@zennio.com wrote:
Hi,
I have seen that in the FS internal database the account SIP registrations are stored during a lot of time and it seems that they are not deleted never.
You are registering on external profile. You are not supposed to. So, maybe there are not parameters for cleaning up.
Look into internal profile configuration, and copy to external the relevant (to registration AND presence AND auth) parameters.
Hth, -giovanni
Is there any mode or parameter to automatically delete these database records after X time, by expired time or number of records for example?
To be better explained, I refer to the SIP profile records that appear when the command is executed:
fs_cli> sofia status profile external reg
Thank a lot.
Regards,
José David Jurado Alonso. _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
_________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
On Wed, Feb 13, 2019 at 11:04 AM Jose David Jurado Alonso < josedavid@zennio.com> wrote:
Yes, I am using the external profile but it is a copy of the internal one and modified by me. I imagine that having the desired configuration it is irrelevant to use one or the other.
Yes, I would think the same. Maybe you want to check with a sip trace if the registrations are ok and coherents with what the system expects... Maybe there is a mismatch of some kind... (force registration domain name?) Other than this, you probably need a consultant to look into it. You can write to consulting@freeswitch.org -giovanni
participants (2)
-
Giovanni Maruzzelli
-
Jose David Jurado Alonso