| 00:31.48 | kpfleming | egonzalez_ergio: this channel is for development questions. please head over to #asterisk, and you'll need to describe your configuration before people will be able to help you. |
| 00:32.01 | *** part/#asterisk-dev egonzalez_ergio (~egonzalez@186.137.1.3) |
| 00:49.34 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:49.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:25.32 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:27.03 | WIMPy | Todays version is bad. any sip call immediately segfaults. |
| 01:33.30 | WIMPy | process_sdp |
| 01:39.26 | *** join/#asterisk-dev tzanger (tzanger@wallace.mixdown.ca) |
| 01:46.04 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 01:46.05 | *** mode/#asterisk-dev [+o seanbright] by verne.freenode.net |
| 02:46.49 | *** join/#asterisk-dev luckman212 (~irc@2001:470:8abb:0:3839:fb97:cb77:8968) |
| 05:07.18 | *** join/#asterisk-dev irroot (~gregory@41.54.217.84) |
| 05:12.21 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 05:12.21 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 06:22.41 | *** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 07:05.39 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:05.41 | schmidts | good morning |
| 07:18.39 | *** join/#asterisk-dev irroot (~gregory@2002:294f:dde2:1:1cbc:1a4e:4c4f:c969) |
| 07:27.24 | *** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 07:43.17 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:1d7c:bfe6:b089:9e5e) |
| 07:53.06 | *** join/#asterisk-dev dwayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 08:37.40 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 08:44.59 | *** join/#asterisk-dev F|shie (~chatzilla@182.177.3.153) |
| 10:25.19 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 10:25.19 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:15.08 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 11:19.41 | leifmadsen | schmidts: morning |
| 11:28.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:28.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:59.08 | file | that stack usage change is an interim fix for those who are curious... I have an alternate idea that will be going up for code review |
| 12:03.06 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 12:03.06 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 12:34.30 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:34.30 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 12:36.16 | wdoekes | @file: convention is to skip the if(newtextrtp) around ast_free |
| 12:38.17 | file | that'll go away soon, oh yes |
| 12:40.43 | wdoekes | and shouldn't "excess" be "uninitialized"? |
| 12:42.22 | file | I don't understand what you mean |
| 12:49.02 | wdoekes | correct me if I'm wrong, but the only thing looking different in r370171, is that the three vars are now not ast_rtp_codecs_payloads_clear()'d, but memset(0)'d (through calloc). in that case a {0,}-initializer and a removal of the ast_rtp_codecs_payloads_clear()'s would've sufficed. |
| 12:51.42 | file | no, it was stack allocated but is now heap allocated... that's quite different |
| 12:55.27 | wdoekes | that's not what I meant ;) |
| 12:56.23 | wdoekes | that's different obviously, but does it change anything? (except put more burden on the heap, which is more expensive than the stack) |
| 12:56.46 | file | yes, it stops it from crashing ^_^ |
| 12:57.06 | file | the media attributes were increased in size and due to the way that structure is currently implemented the stack usage went up, a lot |
| 12:57.42 | file | I moved it to the heap to stop that as an interim fix while I change it to use an ao2 container internally which will reduce memory consumption *a lot* for it |
| 12:58.11 | file | it should actually use less memory than before I even touched the media attributes for most cases |
| 12:59.05 | kpfleming | what ifit uses negative memory? |
| 12:59.32 | file | kpfleming, the world will explode :( |
| 13:00.04 | wdoekes | I believe it stops crashing because you removed the ast_rtp_codecs_payloads_clear()'s and replaced it with an implicit memset |
| 13:01.33 | wdoekes | besides, on bsd I have 500MB of stack to use.. so I'm good |
| 13:03.21 | file | think of the children! |
| 13:03.33 | file | they might not use BSD! |
| 13:06.20 | kpfleming | wdoekes: the asterisk code sets the maximum thread stack size to 256KB on all platforms |
| 13:06.23 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mfqtrestfvtbweiw) |
| 13:06.23 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:14.13 | wdoekes | ok. that makes the switch justifiable. not initializing newaudiortp and friends was nevertheless bad in the first place. |
| 13:14.42 | file | clear zeroes it |
| 13:14.53 | file | well, by setting each individual part to zero |
| 13:15.58 | wdoekes | ugh |
| 13:16.08 | wdoekes | you're right, and I'm reading it wrong |
| 13:16.26 | wdoekes | I stand corrected |
| 13:16.48 | file | you can stand normally |
| 13:30.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-utchdrpoqkafndra) |
| 13:37.00 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:37.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:58.26 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 14:12.26 | *** join/#asterisk-dev Corydon76-home (four@c-69-137-80-31.hsd1.tn.comcast.net) |
| 14:12.26 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 14:26.36 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:26.36 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:00.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:00.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:08.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:08.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:29.20 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 15:29.20 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:46.38 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:47.27 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:03.23 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:03.41 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:16.03 | WIMPy | kpfleming: Not having res_http_websocket doesn't only prevent chan_sip from loading, it prevents Asterisk from starting. |
| 16:18.07 | file | notning in the core uses it... |
| 16:18.25 | Qwell | file: It may return AST_MODULE_FAILURE |
| 16:19.11 | file | it doesn't |
| 16:19.35 | Qwell | I mean down in loader.c |
| 16:19.57 | Qwell | it shouldn't, and I can't imagine it doing so, but.. |
| 16:20.17 | file | unless you mean not having res_http_websocket loaded and then trying to load chan_sip causes Asterisk to not start which is possible due to symbol resolution |
| 16:21.16 | WIMPy | Yes, trying to load chan_sip ends the show. |
| 16:22.31 | mjordan | file: sounds like its going to end up being either weak symbols, or yet another virtual table |
| 16:24.39 | WIMPy | Or not make chan_sip use it if res_http_websocket isn't built in the first place? |
| 16:28.37 | file | meh |
| 16:29.01 | mjordan | file: heh |
| 16:29.52 | file | it is actually possible to use dlsym for this case |
| 16:30.44 | mjordan | yay! |
| 16:30.46 | file | WELL, unless the symbol resolution is completely done immediately... |
| 16:46.46 | file | yeah, that would work |
| 17:23.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:27.45 | kpfleming | and bam!... code up for review |
| 19:15.53 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 19:17.14 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 19:27.38 | *** join/#asterisk-dev Corydon76-work (eight@c-69-137-80-31.hsd1.tn.comcast.net) |
| 19:27.38 | *** mode/#asterisk-dev [+o Corydon76-work] by ChanServ |
| 19:40.27 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:40.28 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:40.30 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:40.30 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:41.30 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qghgnnnenfuvieku) |
| 19:41.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:41.39 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-vlxxhiatooacmqbc) |
| 19:41.48 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ihenvrrifblqqkfm) |
| 19:42.26 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ehgitohckrwkamtu) |
| 20:01.01 | kpfleming | russellb: my compiler does awesome testing all by itself :_) |
| 20:01.27 | russellb | yes yes, of course! |
| 20:02.29 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 20:33.24 | putnopvut | opticron: So you're seeing Asterisk retransmitting INVITEs even though you get a 100 Trying? Are you using UDP for transport or something else? |
| 20:33.38 | opticron | run of the mill UDP |
| 20:34.07 | opticron | I worked around it by setting pendinginvite = 0 on 1xx responses in handle_response_invite |
| 20:34.13 | opticron | call works properly now |
| 20:34.18 | putnopvut | What Asterisk version? |
| 20:34.29 | opticron | the remote endpoint is just really slow about sending the 2xx |
| 20:34.31 | opticron | 1.8.5 |
| 20:35.19 | putnopvut | Ah, okay, let me switch over to that. I was looking at trunk and it appears in handle_response(), that a 100-199 response will get a sip_semi_ack if the method was INVITE. That appears to stop retransmissions. |
| 20:35.32 | kpfleming | opticron: 1.8.5 is rather old |
| 20:35.46 | putnopvut | Same in 1.8.5 too. Odd |
| 20:36.15 | putnopvut | Are you sure that Asterisk is matching the incoming 100 Trying to the outbound INVITE? |
| 20:36.37 | opticron | well, reported on 1.8.5 anyway, the code I was looking at was 1.8 branch |
| 20:36.55 | putnopvut | mkay |
| 20:37.24 | opticron | and yes, the 100 seems to be matched properly |
| 20:38.50 | putnopvut | Weird. You could add some debugging statements into __sip_semi_ack() to make sure that the retransmission is actually being canceled. |
| 20:43.06 | opticron | it is being canceled, but setting pendinginvite=0 is proooobably the wrong thing to do |
| 21:34.05 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 21:55.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ukflrbapqutoszwm) |
| 22:10.21 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-ahzltbrhjafnbkfo) |
| 22:41.06 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-qghgnnnenfuvieku) |
| 22:52.46 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 23:05.17 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 23:09.51 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 23:17.34 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 23:50.18 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |