<div dir="ltr"><div dir="ltr">On Tue, Apr 19, 2022 at 7:41 PM Michal Rybarik <<a href="mailto:michal@rybarik.sk">michal@rybarik.sk</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello folks,<br>
<br>
I'd like to submit some of my Asterisk patches (which might be useful <br>
for other users) to the master source tree, and I'd like to do it most <br>
efficient way (time is short). I have read info about submitting on Wiki <br>
and I'd like to ask:<br>
<br>
- Is it OK to submit following patches to Asterisk?<br>
- Which is the oldest branch that these patches can be submitted to?<br>
- For every patch, should I open JIRA issue and then submit patch to Gerrit?<br></blockquote><div><br></div><div>Current supported branches are 16, 18, 19, and master. A JIRA issue per change is desired, along with submitting to Gerrit.</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">
<br>
Proposed patches:<br>
<br>
1/ Patch to CDR_PROP and CDR engine, which allows to mark last CDR level <br>
(from the last Dial) as disabled, so it won't be written to the CDR <br>
storage. It allows to restore similar CDR behaviour as before Asterisk <br>
12, when only one CDR was stored for one call from A-party, regardless <br>
of how many subsequent Dial()s has been made to reach B-party. With <br>
Asterisk 12 and above and this patch, after unsuccessfull Dial() attempt <br>
to B-party is made, CDR_PROP(disable_last)=1 can be used to disable <br>
(discard) last CDR before another Dial() attempt is made.<br>
This patch also adds displaying of CDR flags to listing of CDRs (core <br>
show channel ...) to help debug CDR issues.<br></blockquote><div><br></div><div>As long as it is optional then it is fine.</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">
<br>
2/ Patch to security events and chan_sip which adds "useragent" field to <br>
ARI security events and to chan_sip events (Register, Unregister, Failed <br>
authentication, etc). We found this very useful in several cases - for <br>
example when SIP user authentication fails, AMI event contains useragent <br>
field which can be used to check if attempt was from regular phone or <br>
some SIP scanner.<br>
<br>
3/ Patch to chan_sip which improves processing of incoming UPDATE (RFC <br>
3311) to allow interoperability with some IMS/SBC implementations. Basic <br>
handling of UPDATE of RPID/PAI headers, SDP attachment and <br>
session-timers is supported. Feature must be enabled in sip.conf <br>
(allowupdate=yes).<br>
<br>
4/ Patch to chan_sip which adds basic support for P-Early-Media header <br>
(RFC 5009) and enables early-media interoperability with IMS.<br></blockquote><div><br></div><div>The chan_sip module is deprecated and will be removed. Except for bug fixes, at this point I'm not personally willing to accept new features or changes like this because of the potential impact on the current state of chan_sip and high risk of breaking something unintentionally. Things like this should strictly be done with PJSIP instead.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>