http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52506 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1944/ ----------------------------------------------------------- (Updated May 25, 2012, 7:19 p.m.) Review request for Asterisk Developers. Changes ------- Fixed comments and log messages Summary ------- While 'real' channels use AST_CAUSE_ANSWERED_ELSEWHERE, local channels and queues use AST_FLAG_ANSWERED_ELSEWHERE for the same purpose. This patch replaces all occurrences of the flag by the cause code, removing the duplicated functionality and the flag itself. Diffs (updated) ----- trunk/apps/app_dial.c 367361 trunk/apps/app_queue.c 367361 trunk/channels/chan_local.c 367361 trunk/channels/chan_sip.c 367361 trunk/channels/chan_unistim.c 367361 trunk/include/asterisk/channel.h 367361 trunk/main/channel_internal_api.c 367361 trunk/main/features.c 367361 Diff: https://reviewboard.asterisk.org/r/1944/diff Testing -------</pre> Birger Harzenetter 2012-05-26T00:19:54 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52505 <pre> changed changed changed changed As I have no idea if any 3rd party modules might make use of the flag, I thought it might be a good idea to leave this reference so developers or users can easily see what happened. Replaced by a more generic comment as that looks rather SIP specific. - Birger ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1944/#review6322 ----------------------------------------------------------- On May 23, 2012, 8:44 a.m., Birger Harzenetter wrote: -- _____________________________________________________________________ </pre> Birger Harzenetter 2012-05-26T00:17:52 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52504 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1946/#review6332 ----------------------------------------------------------- Ship it! With the minor changes below, this looks good to me. /trunk/channels/chan_sip.c &lt;https://reviewboard.asterisk.org/r/1946/#comment11817&gt; This shouldn't be necessary now. /trunk/configs/sip.conf.sample &lt;https://reviewboard.asterisk.org/r/1946/#comment11818&gt; Add "It implies 'yes'." like the 'update' option has. - Kevin On May 25, 2012, 2:12 p.m., Mark Michelson wrote: -- _____________________________________________________________________ </pre> Kevin Fleming 2012-05-25T19:25:40 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52503 <pre>Hi! Sorry, I forgot. JIRA issue opened and patch posted there. With regards, Pavel -- _____________________________________________________________________ </pre> Pavel Troller 2012-05-25T19:13:02 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52502 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1946/ ----------------------------------------------------------- (Updated May 25, 2012, 2:12 p.m.) Review request for Asterisk Developers. Changes ------- I have made the changes suggested by Kevin. Summary ------- There are times where multiple Asterisk servers are peered together over SIP. In such situations, it is possible for both Asterisk servers to attempt to send direct media reinvites to each other simultaneously. This results in a glare situation in which each of the Asterisk servers sends a 491 to the other. After a waiting period, the reinvites are re-attempted. This waiting period can potentially be distracting since it can cause the media to take multiple seconds to finalize, especially if more than 2 Asterisk servers are involved. This patch introduces a new SIP peer option called "directmedia_outgoing". If enabled, then when comm</pre> Mark Michelson 2012-05-25T19:12:15 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52501 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1950/ ----------------------------------------------------------- (Updated May 25, 2012, 2:06 p.m.) Review request for Asterisk Developers, Mark Michelson, rmudgett, and Matt Jordan. Summary (updated) ------- This should be the last set of programming changes. This review's diff file includes uncommitted changes to dahdi+iax and some other stuff that may be covered by the phase 3 review, but focus should stay on the four things mentioned. Diffs ----- /trunk/channels/chan_agent.c 367420 /trunk/channels/chan_dahdi.c 367420 /trunk/channels/chan_iax2.c 367420 /trunk/channels/chan_local.c 367420 /trunk/channels/sig_analog.c 367420 /trunk/channels/sig_pri.c 367420 /trunk/main/autoservice.c 367420 /trunk/main/bridging.c 367420 /trunk/main/logger.c 367420 /trunk/main/pbx.c 367420 Diff: https://reviewboard.asterisk.org/r/19</pre> jrose 2012-05-25T19:06:59 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52500 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1950/ ----------------------------------------------------------- Review request for Asterisk Developers, Mark Michelson, rmudgett, and Matt Jordan. Summary ------- This should be the last set of programming changes. This review's diff file includes uncommitted changes to dahdi+iax and some other stuff that may be covered by the phase 3 review, but focus should stay on the four things mentioned. Diffs ----- /trunk/channels/chan_agent.c 367420 /trunk/channels/chan_dahdi.c 367420 /trunk/channels/chan_iax2.c 367420 /trunk/channels/chan_local.c 367420 /trunk/channels/sig_analog.c 367420 /trunk/channels/sig_pri.c 367420 /trunk/main/autoservice.c 367420 /trunk/main/bridging.c 367420 /trunk/main/logger.c 367420 /trunk/main/pbx.c 367420 Diff: https://reviewboard.asterisk.org/r/1950/diff Testing ------- Each channel driver</pre> jrose 2012-05-25T19:05:56 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52499 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1950/ ----------------------------------------------------------- (Updated May 25, 2012, 2:06 p.m.) Review request for Asterisk Developers, Mark Michelson, rmudgett, and Matt Jordan. Summary (updated) ------- This should be the last set of programming changes. This review's diff file includes uncommitted changes to dahdi+iax and some other stuff that may be covered by the phase 3 review, but focus should stay on the four things mentioned. Diffs ----- /trunk/channels/chan_agent.c 367420 /trunk/channels/chan_dahdi.c 367420 /trunk/channels/chan_iax2.c 367420 /trunk/channels/chan_local.c 367420 /trunk/channels/sig_analog.c 367420 /trunk/channels/sig_pri.c 367420 /trunk/main/autoservice.c 367420 /trunk/main/bridging.c 367420 /trunk/main/logger.c 367420 /trunk/main/pbx.c 367420 Diff: https://reviewboard.asterisk.org/r/19</pre> jrose 2012-05-25T19:06:31 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52498 <pre> By the way, I still feel on this review that the focus should remain on chan_dahdi and iax2. Autoservice changes, chan_agent and chan_local will be split into a separate review. - jrose ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1927/#review6325 ----------------------------------------------------------- On May 24, 2012, 4:32 p.m., jrose wrote: -- _____________________________________________________________________ </pre> jrose 2012-05-25T18:59:52 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52497 <pre> ----- Original Message ----- It was discussed in depth near the end of last year. If I recall correctly, when (which is to be determined) we upgrade to a newer version of JIRA, the issue Triage process will have to undergo serious changes. Those changes could start from the work Leif has documented on that wiki page; however, there will most likely have to be changes beyond that as well. -- Matthew Jordan Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com &amp; http://asterisk.org -- _____________________________________________________________________ </pre> Matthew Jordan 2012-05-25T18:46:42 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52496 <pre> Please do not send patches to the mailing list. Patches need to be attached to a JIRA issue with a signed license contributor agreement. -- Matthew Jordan Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com &amp; http://asterisk.org -- _____________________________________________________________________ </pre> Matthew Jordan 2012-05-25T18:42:48 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52495 <pre> Maybe it's just because it's Friday, but I have no idea what your conclusion from your first paragraph is. Regarding your second paragraph, flag it is! - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1946/#review6307 ----------------------------------------------------------- On May 23, 2012, 5:46 p.m., Mark Michelson wrote: -- _____________________________________________________________________ </pre> Mark Michelson 2012-05-25T18:42:13 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52494 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1947/ ----------------------------------------------------------- (Updated May 25, 2012, 12:20 p.m.) Review request for Asterisk Developers, Mark Michelson, rmudgett, and Rob Gagnon. Changes ------- Adding rmudgett Summary ------- Add ANI2 / OLI parsing for SIP. The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags. If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element. This allows SIP functions that reference ANI2 to work properly for SIP. Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script. This addresses bug ASTERISK-19912. https://issues.asterisk.org/jira/browse/ASTERISK-19912 Diffs ----- /trunk/channels/chan_sip.c 367783 D</pre> Rob Gagnon 2012-05-25T17:20:50 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52493 <pre> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1947/ ----------------------------------------------------------- (Updated May 25, 2012, 12:20 p.m.) Review request for Asterisk Developers, Mark Michelson and Rob Gagnon. Changes ------- Updated code per rmudgett's comment Summary ------- Add ANI2 / OLI parsing for SIP. The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags. If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element. This allows SIP functions that reference ANI2 to work properly for SIP. Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script. This addresses bug ASTERISK-19912. https://issues.asterisk.org/jira/browse/ASTERISK-19912 Diffs (updated) ----- /trunk/channels/ch</pre> Rob Gagnon 2012-05-25T17:20:25 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52492 <pre>A few moons ago, Leif and I created a wiki page[1] for an update triage process in JIRA. I can't remember if we talked about it before or not. [1] https://wiki.asterisk.org/wiki/display/~lmadsen/Issue+Triage+Process </pre> Paul Belanger 2012-05-25T17:10:41 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52491 <pre> Hi! There is a patch, which IMHO fixes the problem. It's for 1.8 trunk. It utilizes the hangup_sip2cause() function instead of the hardcoded cause values. Does already exist an issue for this problem ? If yes, I would submit the patch there. Otherwise, I can open the issue (and from my point of view, its a really SERIOUS issue because clear causes are _very_ important values in the telco business and giving totally incorrect ones can ruin your network (no joking, think of crankback and other advanced routing techniques based on the CC values) and thus even your business). With regards, Pavel --- chan_sip.c.old2012-05-25 18:44:25.898834370 +0200 +++ chan_sip.c2012-05-25 18:45:28.405343312 +0200 &lt; at &gt;&lt; at &gt; -20371,7 +20371,7 &lt; at &gt;&lt; at &gt; ast_log(LOG_WARNING, "Received response: \"Forbidden\" from '%s'\n", get_header(&amp;p-&gt;initreq, "From")); if (!req-&gt;ignore &amp;&amp; p-&gt;owner) { ast_set_hangupsource(p-&gt;owner, p-&gt;owner-&gt;name, 0); -ast_queue_hangup_with_cause(p-&gt;owner, AST_CAUSE_CONGESTION); +ast_queue_hangup</pre> Pavel Troller 2012-05-25T16:56:12 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52490 <pre>Hi! We (or at least not I) are not speaking about passing SIP cause to another UA, I'm talking just and only about the HANGUPCAUSE variable. Formerly it was set to AST_CAUSE_UNALLOCATED. Please be so kind and look at chan_sip.c, around line 6066, function hangup_sip2cause(): ... case 404: /* Not found */ return AST_CAUSE_UNALLOCATED; ... There is the CORRECT mapping of 404 to Cause Value. And now look at the same source, around line 20378 (1.8 branch): case 404: /* Not found */ xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE); if (p-&gt;owner &amp;&amp; !req-&gt;ignore) { ast_set_hangupsource(p-&gt;owner, p-&gt;owner-&gt;name, 0); ast_queue_hangup_with_cause(p-&gt;owner, AST_CAUSE_CONGESTION); } break; An evidently _!_INCORRECT_!_ cause code is used there. Btw, the same problem is with the 403 Forbidden, which should return 21 (Call Rejected), but returns 34 (Con</pre> Pavel Troller 2012-05-25T16:33:41 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52489 <pre>----- Original Message ----- As has already been pointed out, Asterisk is a B2BUA, not a proxy. There is no guarantee that a response from one UA will be 'passed through' Asterisk to another UA. I won't weigh in on whether or not this qualifies as a bug or merely a change in behavior. The fact that Asterisk is not a proxy gives weight to this being not a bug; that being said, there is a definite difference between a 4xx and a 5xx response, which would give some weight to this being a bug. The change in behavior was mostly likely introduced by r351130. This fixed some issues wherein, on a response to a 404, merely queueing a congestion control frame was not sufficient to tear down the channel. The congestion control frame was replaced with an explicit channel hang up with a cause of AST_CAUSE_CONGESTION, which maps to a SIP response type of "503". -- Matthew Jordan Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com &amp; http://asteri</pre> Matthew Jordan 2012-05-25T16:10:29 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52488 <pre>I have and automated call-in dispatch system where hundreds of people call in daily for 2-3 minutes each. The extension is set up to get their information, then text-to-speech the dispatch information (via odbc). It then loops 5 times then ends the call. These calls are being handled by an 8 port analog digium card. Sometimes though, I see calls via 'core show channel dahdi/1-1' that have a time of &gt; 16 hours. When a channel gets in this state, the call doesn't seem to progress through the dialplan, they always display the TTS line. Doing a 'dahdi destroy channel 1-1' doesn't seem to be effective - the only way I've been able to clear the calls is to do a 'dahdi restart' and/or restart the asterisk service. After some investigating and help from the asterisk-users list, problem has been narrowed down to the Swift() app getting stuck (the Swift app is a wrapper around the cepstral text-to-speech engine). Here is the output from the cli: dozer*CLI&gt; core show channels Channel Location State Application(Data) D</pre> Justin Killen 2012-05-25T16:09:09 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52487 <pre>Hi! Oh, Mamma mia, Alex is right!!!! I've just tested a void public number through PRI and I've got CC=1 - Unallocated number. Then I dialled the same number through SIP trunk and I've got CC=34, but on the SIP the response code was really 404 Not Found, which is equivalent to 1 - Unallocated number. Something is really broken here! Of course I'm paying attention to $HANGUPCAUSE and I'm handling it in my own intercept scripts, and they are proved OK, so the problem must be in wrong $HANGUPCAUSE contents. It's 1.8 branch. I hope I will find the cause soon and I'll post it here. With regards, Pavel. -- _____________________________________________________________________ </pre> Pavel Troller 2012-05-25T15:59:24 http://permalink.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/52486 <pre>Hi, That is the problem, asterisk receive 404 but hangupcause is 34 and not 1. When i try with version 1.8.8.0 or before, I have the hangupcause 1 and with all newer version, I have hangupcause 34. alex ----- Original Message ----- -- _____________________________________________________________________ </pre> alexandre Moutot 2012-05-25T15:35:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.telephony.pbx.asterisk.devel