<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 01 Jul 2014, at 13:19, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 1, 2014 at 2:25 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br>
On 30 Jun 2014, at 16:24, Walter Doekes <<a href="mailto:walter%2Basterisk-dev@osso.nl">walter+asterisk-dev@osso.nl</a>> wrote:<br>
<br>
> On 29-06-14 00:50, Matthew Jordan wrote:<br>
>> * app_readfile/app_dahdibarge/app_setcallerid/app_saycountpl -<br>
>> deprecated in Asterisk 1.8. While less important than the other<br>
>> previously listed modules, having been deprecated for 2 LTS's, it is<br>
>> probably time for these module to go.<br>
><br>
> May I also suggest removing:<br>
><br>
> - SetAMAFlags<br>
> - SetMusicOnHold<br>
> - WaitMusicOnHold<br>
</div>What are the replacements for the musiconhold functions?<br></blockquote><div><br></div><div>From WaitMusicOnHold:<br><br> ast_log(LOG_WARNING, "WaitMusicOnHold application is deprecated and will be removed. Use MusicOnHold with duration parameter instead\n");<br>
<br></div><div>From SetMusicOnHold:<br><br> ast_log(LOG_WARNING, "SetMusicOnHold application is deprecated and will be removed. Use Set(CHANNEL(musicclass)=...) instead\n");<br></div></div></div></div></blockquote>Ok, that seems like a good solution.<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">><br>
> in chan_sip:<br>
> - "username" (=defaultuser)<br>
</div>Username actually has multiple functions, which is why I separated one of them<br>
to defaultuser. username should remain the authentication username or be replaced<br>
by authuser=<br><div class=""></div></blockquote><div><br></div><div>Currently, these are aliased together:<br><br> } else if (!strcasecmp(v->name, "username") || !strcmp(v->name, "defaultuser")) { /* "username" is deprecated */<br>
ast_string_field_set(peer, username, v->value);<br> if (!strcasecmp(v->name, "username")) {<br> if (deprecation_warning) {<br> ast_log(LOG_NOTICE, "The 'username' field for sip peers has been deprecated in favor of the term 'defaultuser'\n");<br>
deprecation_warning = 0;<br> }<br> <br></div><div>The peer username field would not be removed or altered; I'd propose that the alias would merely be removed in favour of "defaultuser". This has been deprecated (and a NOTICE emitted) since 1.6.0.<br></div></div></div></div></blockquote>I did not add that deprecation and propably missed it being done. I think it's wrong until we have a solution</div><div>for auth user. We can separate them - but that means some code change.</div><div>I vote NO for removing this until we have solved the issues.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
> - SIPPEER accepting colon separator<br>
> - SIPCHANINFO<br>
</div>Why remove SIPCHANINFO?<br>
<span class=""></span></blockquote><div><br></div><div>It has a complete replacement in the CHANNEL function:<br><br> if (deprecated++ % 20 == 0) {<br> /* Deprecated in 1.6.1 */<br> ast_log(LOG_WARNING, "SIPCHANINFO() is deprecated. Please transition to using CHANNEL().\n");<br>
}<br><br></div><div>Looking at what can be obtained via SIPCHANINFO - peerip, recvip, from, uri, useragent, peername, and t38passthrough, each of these have an exact analogous parameter in the CHANNEL function. Plus, the CHANNEL function provides RTP/RTCP information for the SIP channel. <br>
</div></div></div></div></blockquote></div><br><div>Ok. I still don't see the point of moving everything to CHANNEL but that's only me.</div><div><br></div><div>/O</div></body></html>