| 00:23.28 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 00:55.32 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 01:10.14 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 01:10.14 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:39.05 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 02:47.18 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 02:47.18 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 02:53.44 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 05:26.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 05:26.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:57.57 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 06:11.06 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 06:11.06 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:38.19 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 06:54.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.39) |
| 07:50.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.44.137.202) |
| 07:53.59 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@195.239.220.131) |
| 07:57.04 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:31dd:fe3d:eb48:35e9) |
| 09:08.46 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:08.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:15.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 12:20.03 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 12:26.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 12:51.21 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 13:28.38 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:39.25 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 13:39.40 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ovaxqjerqlcpadrs) |
| 13:39.40 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:44.09 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:44.09 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:45.10 | file | putnopvut, I did it. |
| 13:45.20 | file | re-invite deferral |
| 13:47.30 | *** join/#asterisk-dev italoros_ (~italoross@187.61.168.117) |
| 14:10.30 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-izycjfjsbgtjzcug) |
| 14:26.03 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 14:27.42 | file | offers everyone an audio stream and image stream in the same SDP |
| 14:28.16 | putnopvut | file: I'll be interested in seeing how you managed to do it. |
| 14:28.39 | file | putnopvut, pjsip module that implements on_rx_request and is invoked before the UA layer |
| 14:29.13 | file | it stops processing right there, and once it should be resumed calls pjsip_endpt_process_rx_data |
| 14:29.40 | putnopvut | How does it get told to resume? |
| 14:29.43 | file | and since it doesn't pass in a module it starts back at the beginning, as if the re-invite had just arrived |
| 14:29.58 | putnopvut | Does the transaction layer see it as a retransmission? |
| 14:30.00 | file | SDP handler that told it to be deferred calls a function to resume |
| 14:30.07 | file | it never gets to the transaction layer |
| 14:30.16 | putnopvut | ah, so it's below even the transaction layer |
| 14:30.17 | file | (in the first place) |
| 14:30.20 | file | yup |
| 14:30.34 | putnopvut | yeah, when you said "before the UA layer" I thought you meant like just before it. |
| 14:30.41 | *** join/#asterisk-dev eZz (~ez@194.28.91.17) |
| 14:30.49 | file | before everything basically |
| 14:30.55 | eZz | hello |
| 14:31.04 | putnopvut | But yeah since the distributor gets the dialog way early, you can detect that it's a reinvite. Neat. |
| 14:31.09 | file | except the distributor |
| 14:31.15 | eZz | is there a way to prevent channel hangup after execution context in ast_async_goto ? |
| 14:31.53 | eZz | meaning extension in context |
| 14:32.54 | putnopvut | eZz: Potentially by clearing the softhangup flags on the channel. ast_channel_softhangup_internal_flag_clear(chan, AST_FLAG_ALL); |
| 14:33.20 | putnopvut | Assuming you're using Asterisk 11. |
| 14:33.25 | eZz | putnopvut: does it will affect to a channel behavior after execution of dialplan ? |
| 14:33.29 | eZz | no, it's 1.8 |
| 14:33.31 | putnopvut | If you're using something before that, you can just clear the flags directly |
| 14:33.52 | eZz | so, probably i have to store flags, then exec goto, then restore ? |
| 14:34.42 | putnopvut | Potentially. I'm not guaranteeing what I'm saying will actually work, btw. It's just a guess :) |
| 14:34.50 | eZz | :-) |
| 14:35.04 | eZz | anyways, thanks, will figure out of this |
| 14:38.51 | eZz | looks like it is ast_channel_clear_softhangup in 1.8 |
| 14:38.59 | putnopvut | ah, okay |
| 14:55.06 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 14:55.58 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ovaxqjerqlcpadrs) |
| 15:07.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.52) |
| 15:09.19 | eZz | putnopvut: well, ast_channel_clear_softhangup doesn't helps though. |
| 15:09.32 | eZz | putnopvut: I rewrote it using ast_app_run_macro(NULL, chan, macro, macro_args); |
| 15:09.42 | eZz | it's works now, thank you for help |
| 15:39.45 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-184-183-148-253.ph.ph.cox.net) |
| 16:13.29 | *** join/#asterisk-dev igcewieling (~igcewieli@ip98-183-25-31.pn.at.cox.net) |
| 16:15.29 | igcewieling | Does anyone have any ideas why an ast_debug would show in the CLI even when debug is set off in asterisk? this stupid codec_sangoma is spewing debug info regardless of the debug level. |
| 16:15.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.30) |
| 16:18.14 | file | it may not use the normal debugging system. |
| 16:20.24 | igcewieling | file: that is what I thought but, ast_log(LOG_DEBUG, "Creating Asterisk RTP with IP %d.%d.%d.%d\n", SNGTC_NIPV4(host_ip)); |
| 16:21.06 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@nat.canmos.ru) |
| 16:21.20 | igcewieling | it looks like the ast_debug()s in Asterisk itself |
| 16:23.34 | Qwell | igcewieling: So it's logging whether debug is enabled or not. |
| 16:25.20 | igcewieling | Qwell: correct. |
| 16:25.31 | Qwell | Which is what the code is written to do. |
| 16:25.51 | igcewieling | Qwell: I don't understand. |
| 16:26.22 | igcewieling | how might it be changed to only log debug messages when debug is enabled? |
| 16:26.23 | Qwell | ast_debug != ast_log |
| 16:26.40 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 16:26.51 | igcewieling | Qwell: ah, so if I change the ast_logs to ast_debug I should be good? |
| 16:28.38 | igcewieling | I'll comment them out and not worry about it. |
| 16:35.33 | eZz | igcewieling: what is codec_sangoma? meaning from what part of sangoma? wanpipe/netborder/etc else? |
| 16:36.28 | igcewieling | eZz: Sangoma transcoder cards |
| 16:37.09 | eZz | ahh, ok, thanks |
| 17:10.01 | *** join/#asterisk-dev juggie (~Juggie@unaffiliated/juggie) |
| 17:10.01 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 17:10.01 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |