| 00:15.36 | *** join/#asterisk-dev JonathanRose (~Jon@207.98.203.74) |
| 00:23.53 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 00:23.53 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 00:32.36 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:32.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:30.27 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:47.18 | *** join/#asterisk-dev ChrisInSydney (~Chris@60-241-179-142.static.tpgi.com.au) |
| 03:03.57 | *** join/#asterisk-dev bklang (~bklang@173-102-51-149.pools.spcsdns.net) |
| 03:11.05 | *** join/#asterisk-dev bklang_ (~bklang@173.102.51.149) |
| 04:57.19 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 05:03.38 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 05:14.11 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 05:14.11 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 05:14.11 | *** join/#asterisk-dev bob_kelso (~john@nat/digium/x-ayzokhsubknddzcx) |
| 05:14.11 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 05:16.20 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:789a:8f3:16c8:f700) |
| 05:16.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:18.15 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:04.48 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 06:04.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:37.28 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:38.05 | schmidts | good morning |
| 06:43.53 | oej | Morning folks |
| 07:03.52 | irroot | morning |
| 07:05.27 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:4c81:be6:d57a:5e73) |
| 07:06.41 | schmidts | morning irroot |
| 07:13.49 | irroot | ok chan_lcr works on asterisk 10 |
| 07:16.21 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 07:28.52 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:07.47 | schmidts | i have traced the problem with blond transfer to the update statement and the 404 response from my proxy, or atleast i think its from my proxy |
| 08:28.51 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:43.50 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:43.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:44.16 | oej | Hello there folks |
| 08:46.36 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:46.36 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:48.05 | schmidts | welcome back oej |
| 08:49.24 | *** join/#asterisk-dev ChrisInSydney (~Chris@CPE-58-173-104-6.nwqt1.ken.bigpond.net.au) |
| 08:49.33 | irroot | anyone here use chan_lcr ?? |
| 09:25.54 | oej | chan_lcr - what's that? |
| 09:30.01 | irroot | oej replacement for chan_misdn |
| 09:30.14 | oej | Aha. |
| 09:30.24 | oej | Gotta go. See you later! |
| 09:30.36 | irroot | chan_misdn is mISDN v1 < linux 2.6.27 chan_lcr is v2 |
| 09:30.43 | irroot | cheers have good one |
| 10:17.45 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 10:17.45 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 10:19.00 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 11:20.34 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:20.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:24.30 | schmidts | morning kpfleming |
| 11:25.20 | kpfleming | yes. morning. it was supposed to rain last night but it did not. |
| 11:25.24 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:25.24 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:26.01 | schmidts | i have figured out my problem with blond transfer behind proxy ;) its because the missing route information in the UPDATE message which happens when connected line update is done with the AST_CONTROL_READ_ACTION frame |
| 11:27.49 | kpfleming | interesting |
| 11:41.01 | schmidts | ok i think i have found the problem, when setting the AST_CONTROL_READ_ACTION frame there is a route information on the channel, but after this frame is captured and the ast_CONTROL_CONNECTED_LINE frame is set the route information is empy on the same channel, it looks like this information got lost during the this control frame handling |
| 11:43.00 | schmidts | sorry my fault its a different channel |
| 11:44.37 | kpfleming | i suspect the problem is in the construction of the UPDATE message.. for some reason it's just not including the route-set information that's stored in the sip private structure, even though it is there |
| 11:44.58 | kpfleming | can you try forcing it to use re-INVITE instead of UPDATE to see if the route-set is included in the message? |
| 11:45.06 | schmidts | i will try |
| 11:46.11 | schmidts | its the same for re-invite |
| 11:46.42 | schmidts | i guess the route information is just not there cause it might not be stored from the 180 response, remember there is no final response to the invite when this happens |
| 11:46.59 | kpfleming | i don't think that should matter |
| 11:47.22 | kpfleming | wait... this is a call *to* the phone? |
| 11:47.42 | schmidts | yes the target channel of the blond transfer |
| 11:48.07 | kpfleming | so asterisk is configured to use an outbound proxy then |
| 11:48.22 | schmidts | no an outbound proxy |
| 11:48.37 | schmidts | all peers are directly configured with host=proxyip |
| 11:48.41 | *** join/#asterisk-dev d1j0n (~Adium@75-150-66-252-NewEngland.hfc.comcastbusiness.net) |
| 11:48.51 | kpfleming | hmm |
| 11:49.39 | schmidts | but i think i have found it, the build_route is only called after a 200 response |
| 11:49.48 | schmidts | thats why the channel dont even know the route header |
| 11:49.59 | kpfleming | that does seem like it would be the cause, yes |
| 11:50.07 | *** join/#asterisk-dev oej (~olle@83.145.33.27) |
| 11:50.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:50.12 | kpfleming | so now we need to know whether we should be collecting the route-set from non-final responses or not |
| 11:50.20 | kpfleming | and just as i type that, oej shows up :-) |
| 11:50.29 | schmidts | perfect timing :D |
| 11:52.01 | schmidts | kpfleming AFAIK a route header should allways be used even with a non-final response |
| 11:53.16 | kpfleming | that's not an area i have a lot of knowledge in... but the fact that the dialog hasn't been confirmed yet makes me wonder how exactly it should be handled |
| 11:53.23 | schmidts | and btw once again, when you allready have the solution its much easier to find better information: https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-September/027664.html |
| 11:54.16 | kpfleming | well, i wouldn't necessarily consider that response to be authoritative, but it seems reasonable |
| 11:54.24 | kpfleming | it should be easy enough to test |
| 11:55.49 | schmidts | i am allready trying it ;) |
| 11:58.01 | kpfleming | i've often wondered what the value of having an 'outboundproxy' setting in the config is when you could just set the peers directly to the proxy's hostname/IP/etc. |
| 11:58.19 | kpfleming | i guess it is useful for cases when you are sending requests to a non-predefined peer |
| 11:59.45 | schmidts | the problem with an outbound proxy is that it normally dont have to stay in the signaling path, for both the uas and the uac there is not really a difference if an outbond proxy is between or not, but if you want to do some load balancing or failover, the proxy has to stay in the singaling path |
| 12:15.29 | schmidts | i have tried it with just build_route on 180 but thats not enough, asterisk also have to parse the contact header, then it is working fine |
| 12:16.52 | kpfleming | that makes sense |
| 12:17.55 | schmidts | i am thinking now if parsing the contact header could cause other problems but normally they will be parsed again when a 200 response comes in, so i guess its ok |
| 12:19.03 | kpfleming | right |
| 12:19.21 | kpfleming | where it could cause problems is if the proxy forks the INVITE, but asterisk already has difficulty handling that anyway |
| 12:19.34 | kpfleming | although david vossel did some work to improve the situation there |
| 12:21.16 | schmidts | i guess its time to dig into the rfcs again to see if its an good idea to save the route header even with a non-final response like 180 but i guess its not very clear defined there ;) |
| 12:28.23 | kpfleming | we could ask again on sip-implementors, but if nobody else responded to that message you posted with a correction, it's probably safe to do so |
| 12:30.28 | *** join/#asterisk-dev ChrisInSydney (~Chris@60-242-81-231.tpgi.com.au) |
| 12:32.42 | schmidts | ok i will put it on reviewboard |
| 12:46.39 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 12:50.41 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-juafqjvbxxppsohq) |
| 12:50.41 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:57.11 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-juafqjvbxxppsohq) |
| 12:57.22 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-juafqjvbxxppsohq) |
| 12:57.23 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:07.14 | kpfleming | schmidts: your patch should probably do the same thing for all 1xx responses except for 100 |
| 13:09.55 | schmidts | kpfleming i thought about the same ;) |
| 13:26.34 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 13:29.46 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:43.05 | irroot | ASTERISK-18675 schmidts related ?? |
| 13:43.18 | irroot | https://issues.asterisk.org/jira/browse/ASTERISK-18675 |
| 13:44.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-frxgmylhlbhfqmay) |
| 13:45.34 | merbzt | what is wrong if the read() function on a channel isn't being called when echo() is executed ? |
| 13:48.35 | merbzt | playback works fine, but read() seems to not work |
| 13:51.25 | schmidts | irroot i will take a look |
| 13:53.26 | schmidts | irroot i dont think so, cause there is no route header involved |
| 13:53.47 | irroot | np thx |
| 13:59.57 | kpfleming | merbzt: read() won't get called unless the channel driver has indicated it has at least one frame to be read, by providing a file descriptor and having it marked as 'ready to read' |
| 14:00.33 | kpfleming | are you saying that read() doesn't get called *only* when you are using Echo, or is the use of Echo unrelated? |
| 14:00.57 | merbzt | the use of echo is unrelated |
| 14:01.17 | merbzt | how do I indicate that it has frames to be read ? |
| 14:02.23 | kpfleming | that depends on how your channel driver works. does it use some sort of socket for every channel that has a file descriptor associated with it? |
| 14:02.50 | merbzt | I based it on the chan_phone() |
| 14:02.59 | merbzt | they are similar |
| 14:03.25 | kpfleming | i don't know how chan_phone works |
| 14:03.48 | tzanger | morning |
| 14:04.15 | kpfleming | but there are two options: either your channel driver places a file descriptor into the chan->fds[] array which is used to indicate when frames are ready to be read, or your channel driver calls ast_queue_frame() to place frames directly on the channel |
| 14:06.29 | merbzt | ok, thnx |
| 14:24.36 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 14:24.36 | *** join/#asterisk-dev bob_kelso (~john@nat/digium/x-ayzokhsubknddzcx) |
| 14:24.36 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 14:32.25 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:32.25 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:32.58 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 14:34.34 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:34.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:41.02 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 14:43.30 | *** join/#asterisk-dev oej (~olle@90-230-229-82-no46.business.telia.com) |
| 14:43.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:48.30 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:48.30 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:52.31 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 14:52.54 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 14:54.47 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:54.47 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:59.40 | *** join/#asterisk-dev zerohalo (~zerohalo@173-13-92-27-NewEngland.hfc.comcastbusiness.net) |
| 15:00.32 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 15:04.08 | otherwiseguy | wdoekes2: did you have any opinions on my patch to review 1395? |
| 15:05.55 | pabelanger | Has anybody looked at SIPconnect v.1.1 ? |
| 15:10.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:10.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:14.06 | wdoekes2 | otherwiseguy: sorry, been a bit busy. I have the opinion that we're changing opinions.. I suppose the LIKE query would work.. although sipregs should still be deprecated. the problem I have with it is that we're adding queries while not removing the need for ipaddr in sippeer. |
| 15:14.34 | wdoekes2 | but we could fix that by removing the broken sippeer query in the trunk version |
| 15:15.14 | wdoekes2 | I'll make some time today or tomorrow to update the patch |
| 15:16.33 | otherwiseguy | wdoekes2: right, I would still love to get rid of sipregs in trunk (after some discussion on the asterisk-dev mailing list). I just figured if it was possible to fix the bug in 1.8/10 without making things worse (even more queries, etc.) we might as well. |
| 15:17.02 | otherwiseguy | glares at sipregs |
| 15:17.05 | wdoekes2 | well.. there is +1 query for those using sipregs.. and a LIKE at that |
| 15:18.01 | otherwiseguy | There doesn't have to be, though. We would have to do a name lookup anyway. Since we already have the variables from sippeers, we could modify my function to just duplicate those variables instead of doing the extra name lookup. |
| 15:18.40 | otherwiseguy | I just didn't think to do that until I had posted the review. :-) |
| 15:19.18 | wdoekes2 | I don't immediately see what you mean.. have to run now though |
| 15:20.21 | otherwiseguy | When we set varregs, we have to do a lookup by name on sippeers to set var. Since we are setting varregs and adding the LIKE query to sippeers, we can just replace the lookup by name for var by what was already returned as part of the LIKE query. |
| 15:57.45 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:00.31 | otherwiseguy | wdoekes2: I'm also looking at your ASTERISK-18446 |
| 18:10.23 | *** join/#asterisk-dev JD411 (~JD411@nat/digium/x-feyhqwngjkoujhiu) |
| 18:45.25 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 18:57.23 | *** join/#asterisk-dev otherwiseguy_ (~otherwise@69.76.221.79) |
| 19:59.43 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:59.43 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:15.27 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:15.27 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:16.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:16.05 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:41.35 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-juafqjvbxxppsohq) |
| 21:57.49 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 21:57.49 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:34.47 | snuff-work | wedhorn: i had issue other day with one of my sccp phones |
| 22:35.18 | snuff-work | asterisk 'thought' a phone had already registered a line so wouldn't let it re-reg (though it had been reset) |
| 22:36.22 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |