MJ and Oej wrote:
I did not add that deprecation and propably missed it being done. I
think it's wrong until we have a solution
for auth user. We can separate them - but that means some code change.
I vote NO for removing this until we have solved the issues.
I'm not sure how strongly Walter feels about removing this option, but I
could go either way. I definitely understand the desire to have a more
permanent solution than simply moving the name (with many purposes) from
'username' to 'defaultuser', and I'm okay with keeping this option until
a more complete solution is provided.
I'm fine with ignoring this for now.
Username actually has multiple functions, which is why I separated one of them
to defaultuser. username should remain the authentication username or be
replaced
by authuser=
In trainings it fun though. People get very confused and need more hours, which
is good from a consultant point of view, but not good for users.
I initially thought we could set the peername (peer->name) through the
username= setting; that what is matched for type=user incoming requests
by From/authuser.
But there only the context name worked.
The phrase username could mean any one of:
- authuser (outbound auth username, or inbound?)
- fromuser (outbound From user-part)
- defaultuser (user-part-of-INVITE-RURI-if-not-supplied)
- peername (inbound From user-matching)
- the identifier that's used with ast_log/ast_debug (currently one of
peer->name and peer->username is chosen, sometimes seemingly at random)
.. and possibly more.
Plenty of room for confusion. IMHO, enough to avoid using just
"username" at all ;)
P.S. While we're trimming stuff:
/*
* XXX This is experimental code to grab the search key from the
* Auth header's username instead of the 'From' name, if
available.
* Do not enable this block unless you understand the side
effects (if any!)
I'm in favor of removing the "experimental" from that comment in
chan_sip.c. In sip.conf there is no such warning. And as far as I can
tell, it works as advertised.
Cheers,
Walter
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
