| 01:21.14 | *** join/#asterisk-dev alexoc (~alexoc@187.64.254.47) |
| 03:30.35 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:30.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:51.39 | *** join/#asterisk-dev ducdmann (~ducdmann@host81-149-39-60.in-addr.btopenworld.com) |
| 04:09.10 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 04:09.11 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 04:15.57 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 06:51.45 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 06:51.45 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:20.29 | *** join/#asterisk-dev schmidts (~schmidts@213.235.212.196) |
| 07:20.31 | schmidts | good morning |
| 07:49.16 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 08:07.36 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:15.13 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:48.01 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 09:29.08 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:29.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:52.23 | *** join/#asterisk-dev razu (~razu@2001:ad0:1:1:202:b3ff:fe36:921c) |
| 11:53.02 | schmidts | depending to the regression i have brought in with 1.8.9.1 will there be a realease soon which includes r355732? cause in fact 1.8.9 will not work for a lot of people and imho it would be good to have a working version ASAP ;) |
| 12:40.45 | *** join/#asterisk-dev goddva (~glarsen@77.40.154.242) |
| 12:46.12 | schmidts | i am thinking about sipaddheader and the possibility to add certain sip header only for specific outoing channels, for example to set different alert headers for different targets even when they are dialed together like Dial(SIP/phoneA&SIP/phoneB) |
| 12:46.50 | schmidts | what i had in mind was to give sippaddheader also an option for which channel this header should be added which could look like SipAddHeader("x-test: 1234","SIP/phoneA") |
| 12:47.09 | schmidts | do you think this is a good idea or mostly useless? |
| 13:11.29 | opticron | I think there is a better way to do it, possibly by using something like this: https://reviewboard.asterisk.org/r/1229/ but I'm not sure if that will act like I'm thinking |
| 13:17.45 | schmidts | opticron hmmm maybe this could be a way, i will think about this ;) thank you |
| 13:25.27 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 13:26.15 | opticron | good luck :) |
| 13:30.57 | schmidts | the problem i have with this that i would have a lot of logic, maybe including some database stuff, after the dial |
| 13:31.24 | schmidts | and btw imho parsing all channel vars with a strcmp also doesnt sound like a good performing thing ;) |
| 13:31.43 | opticron | probably not |
| 13:32.05 | opticron | neither method of accomplishing what you want is ideal :/ |
| 13:35.04 | schmidts | opticron the problem here is basically the channel -> channel tech structure, cause asterisk couldnt know which types of channels it might use |
| 13:35.30 | schmidts | but i will think about something usefull and a little bit more performant than a strcmp about the whole channel vars list |
| 13:37.40 | opticron | a hash should be a little better in that regard |
| 13:41.53 | schmidts | yes thats for sure, but then i have to alloc a new container for each channel |
| 13:42.04 | opticron | :) |
| 13:42.27 | schmidts | but hey it wouldnt be fun if it would be easy :D |
| 13:48.11 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:48.11 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:51.37 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:51.37 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:05.59 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-qtcbqusphxazwlpw) |
| 14:06.14 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 14:16.11 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:16.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:24.54 | schmidts | opticron a big problem i see when using an after dial setup like in r1229 would be that app_dial calls this one after another so it might happens that one phone start ringing a large time before the next one starts ringing and the locking cause by such things would be really scarry |
| 14:33.11 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-rebkimlyojmzyaic) |
| 14:33.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:54.28 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-grduuzwazfqvevhy) |
| 15:00.45 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:00.45 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:10.56 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-brwwmwjlmirpyvrg) |
| 15:12.40 | kpfleming | schmidts: i haven't looked at that patch, but none of the outgoing channels should actually get 'started' until all the pre-dial work on all of them has been completed |
| 15:16.56 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:16.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:18.46 | schmidts | kpfleming thats not right, the predial stuff happens in the loop where it runs through the device list separeted with & but before the actual call happens for sip this means before the invite is sent |
| 15:19.47 | schmidts | but this predial stuff is done on every new channel, so on the second "device" it do the predial stuff again before doing the call but after the first invite is allready sent out |
| 15:20.26 | kpfleming | that's my point... it should not work that way. |
| 15:20.35 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:20.35 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:24.43 | schmidts | the problem is, this could even happen without the review |
| 15:24.56 | schmidts | the chance for it is likely very small but IMHO its possible |
| 15:25.15 | kpfleming | agreed |
| 15:25.53 | schmidts | it would make much more sense and should be more deadlock safe to create first all channels which are necessary and then start the call callback on each of them |
| 15:27.26 | kpfleming | *after* running any macros/gosubs/etc. that need to be run on the channels |
| 15:28.55 | WIMPy | ... in parallel |
| 15:29.00 | WIMPy | ducks |
| 15:30.22 | schmidts | kpfleming correct ;) |
| 15:31.27 | schmidts | WIMPy there is no need to run it parallel cause even with a forked dial you will end up with only one final channel and the receiver side for each tech allready has its each thread |
| 15:32.39 | WIMPy | So the dialplan called from within the dial is already in parrallel? |
| 15:41.09 | schmidts | WIMPy no |
| 15:41.12 | schmidts | which dialplan? |
| 15:42.16 | schmidts | if you have for example Dial(SIP/123&SIP567) then app_dial creates first a channel for SIP/123 then calls the channel api for call, then generates a sip channel for SIP/567 and again calls the channel api |
| 15:42.52 | WIMPy | That b parameter takes a dialplan location, doesn;t it? |
| 15:43.08 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:44.44 | schmidts | yes ;) |
| 15:45.12 | schmidts | and for this review it would be like above but before the channel api is called it does the dialplan action |
| 15:45.23 | schmidts | that was the problem i have noticed |
| 16:14.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:31.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 16:34.36 | WIMPy | What do you guys think of adding a new channel state for disconnected but not yet released calls? |
| 16:35.29 | WIMPy | Currently they remain in AST_STATE_UP, which after my patch from this morning will allow you to put disconnected calls on hold which doesn't make sense. |
| 16:41.12 | WIMPy | BTW: Inbanddisconnect yes or no doesn't seem to make a difference. Or is that only used for other channeltypes? |
| 17:52.52 | seanbright | [Feb 20 11:51:56] WARNING[17762]: channel.c:4913 ast_write: Codec mismatch on channel IAX2/some-peer-706 setting write format to ulaw from g729 native formats 0x100 (g729) |
| 17:53.01 | seanbright | i'm confused by that message |
| 17:59.04 | *** join/#asterisk-dev elguero_ (41d63835@gateway/web/freenode/ip.65.214.56.53) |
| 18:17.08 | kpfleming | seanbright: my brain is a bit addled, but i suspect that message means that the channel is natively in g729, but someone has attempted to write a ulaw frame on it, so a translation has been setup to allow that to happen |
| 18:17.44 | kpfleming | it could certainly be worded better |
| 18:18.09 | seanbright | it's an incoming dahdi channel (so it's ulaw) and then being sent to a Dial(IAX2/...( |
| 18:18.46 | kpfleming | so the channels should have been made 'compatible' when they were first bridged |
| 18:19.02 | kpfleming | if that didn't happen for some reason, it would happen automatically later when necessary, but will generate a warning |
| 18:19.10 | seanbright | gotcha |
| 18:19.19 | seanbright | ok, so the some reason is what i'm interested in |
| 18:19.23 | seanbright | heh |
| 18:19.25 | kpfleming | yep |
| 18:38.51 | mjordan | seanbright: thanks for re-opening ASTERISK-17541 |
| 18:39.25 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:39.25 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:45.05 | seanbright | mjordan: sure. |
| 18:45.17 | seanbright | it's affecting me, so i have a vested interest :P |
| 19:05.03 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 19:25.17 | seanbright | if i have a machine that has been an IPv4 and an IPv6 address, what is the correct way to specify 'any'? |
| 19:25.31 | seanbright | ast_sockaddr_parse(&addr, "0.0.0.0")? |
| 19:26.49 | kpfleming | yes |
| 19:27.52 | seanbright | if i didn't have a v4 address, would that still be valid? |
| 19:29.43 | kpfleming | probably |
| 19:31.10 | seanbright | alrighty |
| 19:44.02 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 20:57.07 | *** join/#asterisk-dev xavia (~xavia@38.65.32.130) |
| 23:17.41 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-rebkimlyojmzyaic) |
| 23:30.04 | *** join/#asterisk-dev snuff-work (~snuffy@210.9.82.197) |
| 23:30.04 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |