[asterisk-dev] Problems with the ASTERISK-27206 patch.
Richard Mudgett
rmudgett at digium.com
Tue Jan 2 17:14:33 CST 2018
The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206 which
is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a
configuration regression by requiring the endpoint and identifier method
to agree to match the endpoint. Doing so is redundant for methods that
explicitly specify which endpoints they match. The redundancy allows
configuration errors that cannot be caught when the configuration is
loaded.
Relevant endpoint 101 configuration values:
[global]
; The order by which endpoint identifier methods are given priority.
; The endpoint_identifier_order default is
;endpoint_identifier_order=ip,username,anonymous
[101]
type=endpoint
; The identify_by default is
;identify_by=username
[identify_me]
type=identify
endpoint=101
; Match by some IP address
match=127.0.0.1/24
Before the patch, the 101 endpoint above would identify by either the
username endpoint identifier method or the
res_pjsip_endpoint_identifier_ip endpoint identifier method's
[identify_me] section.
After the patch, the 101 endpoint is still matched by either method.
However, the identify_by default had to change to "username,ip" and the
option meaning had to change slightly do it. I think this is wrong. If
you went to the trouble to create an [identify_me] section which must
explicitly specify the endpoint it matches then the endpoint should not
need to also specify in the identify_by value that it is identified by the
res_pjsip_endpoint_identifier_ip method. Doing so is redundant and will
cause unnecessary configuration errors.
The goal of ASTERISK-27206 is to prevent the endpoint from being
identified by the username identification method so it could only be
identified by the res_pjsip_endpoint_identifier_ip method. The key
difference between the two methods is the username identification method
has no other configuration than the endpoint's identify_by value available
to specify to which endpoint the method applies.
I think the previous and current identify_by documentation is a bit
misleading in any case. The identify_by option historically specified
which identification methods that have no other configuration requirements
can match the endpoint. i.e., The username and auth_username
identification methods. To satisfy ASTERISK-27206, what is needed for the
identify_by option is a value to prevent methods that have no other
configuration requirements from matching the endpoint.
Proposed candidates for the new identify_by value are: "", "none", and
"other". The "" or "none" value to indicate that none of the methods
without configuration will match. The "other" value to indicate that the
endpoint is matched by only other matching mechanisms with their own
configuration.
Looking at the some some more, I think the empty value "" is already
allowable in the pjsip.conf file so the entire patch for ASTERISK-27206
would not be needed. You could have configured identify_by to an empty
value and it would have satisfied the issue. However, I think database
backends would have an issue with an empty value since the column is
declared as an enum while the code works with it as a string of comma
separated enum values.
Fortunately, the first ASTERISK-27206 patch hasn't come out in a release
yet. However, it is currently in the 13.19.0-rc1 version. As a result,
we may have to keep the "ip" value that the first ASTERISK-27206 patch
added to indicate_by as an alias and fix the database column definition.
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180102/2c29be01/attachment.html>
More information about the asterisk-dev
mailing list