| 00:04.00 | *** join/#asterisk-dev zh-home (~zerohalo@74.61.196.236) |
| 01:19.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 01:44.03 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@38.100.211.103) |
| 02:01.29 | *** join/#asterisk-dev Kobaz (~kobaz@64.27.7.21) |
| 05:10.05 | *** join/#asterisk-dev irroot (~gregory@41.52.7.7) |
| 06:25.35 | *** join/#asterisk-dev irroot (~gregory@41.49.162.129) |
| 06:26.21 | *** part/#asterisk-dev irroot (~gregory@41.49.162.129) |
| 07:05.53 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-76-98-170-static.hfc.comcastbusiness.net) |
| 07:07.12 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 08:16.09 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 08:46.31 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e11a:5cfc:9e4:edd5) |
| 08:51.03 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 08:51.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:52.30 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 08:52.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:58.41 | *** join/#asterisk-dev merbanan (~benjamin@h217-27-188-82.cust.tyfon.se) |
| 09:03.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:03.07 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:04.43 | *** join/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 09:28.12 | wedhorn | JunK-Y: ping |
| 09:34.30 | *** join/#asterisk-dev gokulnath (~gokulnath@115.111.177.122) |
| 09:57.11 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 09:57.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:48.24 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 11:48.27 | schmidts | hello |
| 12:08.19 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:08.19 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:20.02 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:20.02 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:23.26 | *** join/#asterisk-dev irroot (~gregory@196-215-57-38.dynamic.isadsl.co.za) |
| 12:23.48 | *** part/#asterisk-dev irroot (~gregory@196-215-57-38.dynamic.isadsl.co.za) |
| 12:41.03 | *** join/#asterisk-dev tamiel (~tamiel@85-171-170-252.rev.numericable.fr) |
| 12:44.56 | *** join/#asterisk-dev b3nt_pin (~b3ntpin@142.162.36.51) |
| 12:48.43 | *** join/#asterisk-dev b3nt_pin (~b3ntpin@142.162.36.51) |
| 13:54.37 | *** join/#asterisk-dev Dovid (Dovid@office.mypbxmanager.net) |
| 13:59.42 | JunK-Y | wedhorn: pong, but ive to go soon, sup? |
| 14:03.08 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 14:03.33 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-twrexwxnkzkdnobu) |
| 14:03.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:05.40 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-kurjxfavbqzndsrb) |
| 14:13.33 | schmidts | can someone help me about generic_fax_exec function, it looks like this function is not threaded in any kind so it would cause some problems when running more than once at a time, or is the channel which call this application (SendFax) threaded? IMHO no |
| 14:14.09 | file | each channel executing SendFax has its own thread |
| 14:16.33 | schmidts | file thanks, it just looked strange to me, cause when i have 4 paralell calls all using sendfax i only see one process in htop with a high cpu load, with normal calls i usual see more ;) |
| 14:43.10 | *** join/#asterisk-dev t_dot_zilla (~t_dot_zil@unaffiliated/t-dot-zilla/x-2830497) |
| 14:43.21 | *** part/#asterisk-dev t_dot_zilla (~t_dot_zil@unaffiliated/t-dot-zilla/x-2830497) |
| 15:15.21 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:15.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:19.04 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:19.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:38.07 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:38.07 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:51.50 | JunK-Y | wedhorn: hello? |
| 15:53.34 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:53.34 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:03.34 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:03.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:12.23 | *** part/#asterisk-dev asterisk-Tester (~RAMYT@193.227.170.247) |
| 16:22.53 | wdoekes2 | JunK-Y: "its "probably" the normal behavior, since its the same for OSP_CALLID_SIP too." <-- we were removing assignments that are unused right? res = OSP_FAILED; is unused |
| 16:25.40 | wdoekes2 | JunK-Y: re: "for(i=0;i< (int)" you did add braces, but it could still use some spaces: for (i = 0; i < (int)(yytext - YY_CURRENT_BUFFER_LVALUE->yy_ch_buf); i++) |
| 16:25.54 | wdoekes2 | gone, bbl |
| 17:00.34 | *** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd) |
| 17:20.31 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@38.100.211.103) |
| 17:57.00 | *** join/#asterisk-dev cVsup (~cVsup@189.105.162.148) |
| 18:01.47 | *** join/#asterisk-dev cVsup (~cVsup@189.105.162.148) |
| 18:23.39 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 18:25.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 18:43.23 | *** join/#asterisk-dev Devon_ (~chatzilla@63.214.236.169) |
| 18:51.33 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-rlcsmvmmammsuiui) |
| 19:03.13 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 19:06.22 | luckman212 | mjordan: re: https://issues.asterisk.org/jira/browse/ASTERISK-19173 if Ross is slow to provide pcaps I can provide them as I'm having the exact same issue |
| 19:08.20 | mjordan | luckman212: please do |
| 19:08.32 | luckman212 | Only trouble Is I cannot comment or add anything to that ticket |
| 19:08.47 | mjordan | if that's the case, then file a new one |
| 19:09.02 | mjordan | I'd prefer to figure out what's going on with this before we roll a new rc of 1.8.9 |
| 19:09.03 | luckman212 | Ok, I can do that-- just didn't want to add clutter |
| 19:09.15 | luckman212 | will do. |
| 19:51.07 | wedhorn | JunK-Y: Your cppcheck patch. In the second skinny block you're changing the type from uint32 to char. |
| 19:52.37 | JunK-Y | really? let me verify this |
| 19:56.05 | JunK-Y | as soon as I arrive home, i'll fix this |
| 19:56.24 | wedhorn | okay, thanks |
| 19:56.26 | JunK-Y | all the rest of the patch seems okay to ya? |
| 19:56.52 | wedhorn | really only looked at the skinny stuff |
| 19:57.35 | JunK-Y | ok |
| 20:06.57 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 20:16.10 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 20:44.37 | otherwiseguy | So, can anyone think of a reason why changing the mess that is handle_response() and handle_response_${method_name} in chan_sip should not be cleaned up in such a way that there is a function that looks up and runs the proper handle_response_${method} callback based on the method of the response, with the method-specific functions returning whether or not they handled the response and if they didn't then doing some generic |
| 20:44.37 | otherwiseguy | handling? |
| 20:45.04 | otherwiseguy | Right now it is a horrible mess of nested switch/case statements in handle_response that then also need to be repeated in the individual functions…it is maddening. |
| 20:45.10 | putnopvut | I think there are a bunch of cases where they're going to be the same, independent of the method. |
| 20:45.37 | otherwiseguy | Right, and the generic response function could take care of those. |
| 20:46.05 | putnopvut | Right. IF you look at how I handled PUBLISH support, I saw the response handling code and said "eff this" |
| 20:46.10 | oej | I started doing that years ago, but never completed it. It's a mess, Terry. |
| 20:46.21 | putnopvut | I think I wrote something about "transcending a morass of doodoo" in the comments. |
| 20:46.23 | otherwiseguy | But right now we have if (sipmethod == x) handle_response_x() else if (sipmethod == y) handle_response_y in tons of different case statements. It's driving me nothing. |
| 20:46.29 | otherwiseguy | nutty? |
| 20:46.35 | putnopvut | lol |
| 20:46.36 | otherwiseguy | I have no idea what I was typing there. |
| 20:46.52 | oej | Please, please fix it? :-) |
| 20:47.08 | oej | There's some weird stuff about direction as well... |
| 20:47.13 | Qwell | otherwiseguy: I bet it's like a 2 line regex. |
| 20:47.26 | otherwiseguy | As an example, there is a case 428 in handle_response_invite that never gets called because there isn't a case 428 in handle_resposne. |
| 20:47.32 | otherwiseguy | sillyness. |
| 20:48.23 | mjordan | otherwiseguy: is there anyway to peel that kind of effort off of what you're currently looking at? |
| 20:48.49 | otherwiseguy | And we don't end up keeping the transaction alive for retransmitting ACKs on non-200 INVITE transactions, because all of the unique cases in handle_response_invite set sip_alreadygone instead of sip_scheddestroy, etc. |
| 20:49.09 | otherwiseguy | mjordan: yeah. it's just the more I look at things, the more they tick me off and the more I find to fix. |
| 20:49.16 | otherwiseguy | This issue might end up taking a little longer. |
| 20:49.22 | mjordan | otherwiseguy: that's one of the big things I'd like fixed as well. |
| 20:50.15 | putnopvut | otherwiseguy: You might want to have a look at RFC 3261 to make sure that the non-200 INVITE transaction thing isn't actually correct. I seem to recall the state machine is a bit different for those types of transactions. Although I may be completely wrong. |
| 20:50.23 | mjordan | I figured it would. Refactoring chan_sip to use some other mechanism in handle_response is bound to be a pretty large effort however, and one that injects some risk |
| 20:51.13 | otherwiseguy | putnopvut: Is it sad that I knew to go to section 17.1.1.1 to look up that info? |
| 20:51.33 | putnopvut | not really. Kind of nice to know where to go :) |
| 20:52.01 | mjordan | heh - I didn't know the section, but I knew when to stop when I blurred by it |
| 20:52.20 | mjordan | although I did stop on client non-invite transactions, so I guess I was a bit off :-P |
| 20:52.42 | otherwiseguy | I'm pretty sure that we have keep things going until timer D fires in case we need to retransmit the ACK. |
| 20:53.06 | otherwiseguy | But it is always a good idea to re-read rfc 3261. |
| 20:54.05 | putnopvut | Also, reading RFC 3261 can be a bit unhelpful since we don't have separate transaction and transaction user layers. |
| 20:54.37 | mjordan | ...what...? :-D |
| 20:54.49 | otherwiseguy | Any retransmissions of the final response that are received while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission. |
| 20:55.17 | putnopvut | I'll be back in a bit. |
| 20:55.24 | mjordan | as will I |
| 20:55.55 | otherwiseguy | And getting to the terminated state requires either a 2xx, transport error, or timer d firing. |
| 21:17.18 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 21:39.36 | putnopvut | Back |
| 21:41.25 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 21:42.10 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-ofevsrlzgbthmabf) |
| 21:52.53 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 22:04.32 | otherwiseguy | putnopvut: So am I correct that there is no handle_ok callback defined for any handle_publish stuff? |
| 22:04.43 | otherwiseguy | handle_response_publish, that is. |
| 22:05.35 | putnopvut | checks |
| 22:05.48 | otherwiseguy | my grep skills are sorely lacking otherwise. :-) |
| 22:07.28 | putnopvut | otherwiseguy: I'm pretty sure that's correct. The only event publication agent we have defined so far is for call completion. It doesn't have anything specific it does based on receiving a 200 OK for a PUBLISH. |
| 22:07.50 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.156.88.dsl.dyn.forthnet.gr) |
| 22:07.54 | putnopvut | The callback is designed for agents that do need to do something based on receiving a 200 OK. |
| 22:07.55 | otherwiseguy | ok, that's what I thought. Just wanted to double check that I am not crazy. |
| 22:08.13 | otherwiseguy | (because of this) |
| 22:08.24 | putnopvut | Yeah if you look up cc_epa_static_data, you'll see that it doesn't define a handle_ok callback, and I don't thin there are any other epa_static_data structs defined anywhere. |
| 22:36.21 | *** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd) |
| 22:44.59 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-twrexwxnkzkdnobu) |