[asterisk-dev] Proposed removal of deprecated modules in Asterisk 13 (cdr_sqlite, chan_gtalk, chan_jingle, res_jabber, chan_h323, app_readfile, app_dahdibarge, app_setcallerid, app_saycountpl)

[Walter Doekes]

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