| 01:05.55 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:05.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:19.05 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:19.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:27.43 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:27.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:43.26 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-okwhguogxcqmaznr) |
| 04:23.34 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 05:19.09 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 07:27.24 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:57.10 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:14.38 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:24.13 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 08:51.03 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:51.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:51.13 | oej | MOrning folks! |
| 08:58.52 | *** join/#asterisk-dev michael_work_ (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 11:10.15 | skrusty | does anyone know what came out of the mod_http_cache (for *) discussion a while back? |
| 11:56.29 | *** join/#asterisk-dev oej (~Adium@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 11:56.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:11.29 | file | skrusty, nothing yet afaik - although mjordan might be poking at such a thing in his spare time |
| 12:35.59 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:35.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:39.26 | skrusty | cool |
| 12:44.30 | file | mjordan, YOU! |
| 12:52.08 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 12:58.47 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-brxhvdcqlhyekpmg) |
| 13:03.20 | skrusty | mjordan: file informs me you might be tinkering with some http_mod_cache shenanigans |
| 13:13.06 | skrusty | mod_http_cache even :/ |
| 13:13.31 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 13:17.41 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:52.53 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:52.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.57 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 14:18.19 | *** join/#asterisk-dev spditner (~simon@108.161.115.12) |
| 14:28.24 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-qxtotklrrhiazlrl) |
| 14:34.40 | hurdman | hello |
| 14:34.55 | hurdman | jsmith: around here ? |
| 14:53.57 | jsmith | hurdman: I am now... |
| 14:58.59 | hurdman | o/ |
| 14:59.09 | hurdman | it seems that i have got that problem https://issues.asterisk.org/jira/browse/ASTERISK-16126 |
| 14:59.14 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-zaytioofscilmyxl) |
| 14:59.59 | hurdman | if i call only one sip peer, i see the progress msg 183 forwaded by asterisk , but the rtp isn't forwarded |
| 15:00.30 | hurdman | if i made something like : Dial(SIP/moniteur&SIP/hbs1&SIP/hbs2&SIP/hbs3&SIP/hbs4) |
| 15:00.36 | hurdman | the progress isn't forwarded |
| 15:00.52 | hurdman | i can see there's a https://jira.digium.com/browse/SWP-1526 |
| 15:01.04 | hurdman | but i haven't the access to read it with my jira accound |
| 15:01.06 | hurdman | account* |
| 15:03.48 | hurdman | so, it seems that there's two bug. one to forward rtp and one to forward progress message when there's a multi-call |
| 15:04.50 | file | the code purposely does not forward progress when there's multiple called targets |
| 15:05.43 | hurdman | file: is there a simple patch to do that |
| 15:05.48 | file | no |
| 15:05.56 | hurdman | ouch |
| 15:06.02 | file | you can either lock onto a single audio stream and forward that, or you have to mix them all |
| 15:06.07 | file | nobody has implemented either |
| 15:06.32 | hurdman | i don't mean to forward rtp, i mean to forward 183 SIP progress message |
| 15:07.00 | hurdman | i only need rtp to the last one that have send a 183 |
| 15:07.15 | file | that's still not implemented |
| 15:07.43 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:07.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:07.47 | hurdman | why ? asterisk can't forward a SIP message when there's a multi-call ? |
| 15:08.03 | hurdman | ( no media, only msg ) |
| 15:08.09 | file | it could, if someone wrote it |
| 15:08.22 | hurdman | i have to ^^ |
| 15:09.39 | hurdman | file: but it pass into the same line if i call one or multiple , into handle_response_invite "Receive Progress" of chan_sip.c |
| 15:09.45 | hurdman | where does-it blocked ? |
| 15:09.49 | file | app_dial blocks it. |
| 15:09.54 | hurdman | ok |
| 15:12.31 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-eeqfltwjgbhcemvx) |
| 15:13.20 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:13.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:14.02 | hurdman | so, if i understand, i have to patch asterisk src code to have "multipall process forwarding" and "rtp forwarding before answer" |
| 15:14.57 | file | if you dial one SIP peer it will forward progress if it can, if it isn't then something about your environment is different than others |
| 15:15.16 | file | if you call *multiple* then yes, you have to add some sort of support for doing progress forwarding |
| 15:15.42 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-lqkcufiihzlcgtit) |
| 15:20.42 | hurdman | ok file |
| 15:21.04 | hurdman | and about rtp media, it should be forwarded too after the process ? |
| 15:21.15 | file | for single scenario yes |
| 15:21.19 | file | for multiple then it depends... |
| 15:21.32 | file | like I've said you can either lock on to a specific stream and forward that OR mix all streams and forward that |
| 15:21.36 | file | both have their pros and cons |
| 15:22.10 | oej | Multiple early media streams is a scenario you want to avoid |
| 15:22.30 | jsmith | oej: Right... that sounds... awful |
| 15:22.40 | file | it's messy |
| 15:22.54 | jsmith | oej: I mean... one endpoint could be playing Abba as early media... |
| 15:23.31 | hurdman | i don't mean multiple early media |
| 15:23.33 | hurdman | ... |
| 15:23.36 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-cxzicqoyflyclxrd) |
| 15:23.42 | jsmith | oej: And another could be playing James Taylor.... you certainly wouldn't want to mix them! |
| 15:23.56 | hurdman | [Alice] => call [asterisk] => [ Bob, Charles , James ] |
| 15:24.18 | oej | And who plays early media? |
| 15:24.24 | hurdman | [ Bob ] => progress => [asterisk] => progress => [Alice] |
| 15:24.41 | oej | Which works by default |
| 15:24.45 | oej | Or not? |
| 15:24.46 | hurdman | [Alice] => rtp => [asterisk ] => rtp => [ Bob ] |
| 15:24.47 | jsmith | hurdman: Progress as in a 180 Ringing, or a 183 without SDP, or a 183 with SDP? |
| 15:25.11 | file | oej, only if you call a single target |
| 15:25.34 | hurdman | no, it don't, if alice call only Bob, asterisk forward progress from bob, but not if i call charles and james too |
| 15:25.49 | hurdman | and asterisk forward my rtp only after the answer |
| 15:25.54 | oej | That I should consider a bug. Wasn't aware of that. |
| 15:25.56 | jsmith | I get the idea that hurdman is talking about prgress messages *without* early media, but I"m confused |
| 15:26.15 | oej | jsmith: Hurdman talks about RTP packets... |
| 15:26.31 | jsmith | oej: Right, hence the reason I'm trying to get an answer of what he means by "progress" |
| 15:27.54 | oej | 183 Session Progress is normally what you talk about - it's mapped to ISDN-ish progressish |
| 15:28.09 | oej | 180 with SDP is early media ringtone⦠|
| 15:28.15 | oej | But I can be wrong. |
| 15:28.31 | oej | Anyway, not forwarding one early media stream when call is forked to multiple destinations is bad. |
| 15:28.46 | oej | I will have to test that at some point. |
| 15:28.47 | hurdman | you send a SIP 183 progress message, after, your caller send to you the rtp media |
| 15:29.05 | file | app_dial specifically doesn't do it, I think that behavior even predates me |
| 15:29.08 | oej | The important media is coming from the CALLEE |
| 15:29.20 | oej | wonder if I have been in that code. |
| 15:30.27 | oej | <PROTECTED> |
| 15:30.28 | oej | <PROTECTED> |
| 15:31.17 | oej | What's OPT_RINGBACK |
| 15:31.23 | jsmith | hurdman: Does that 183 contain an SDP section, or not? |
| 15:31.25 | oej | IF that is sent, we forward progress even if the call is forked |
| 15:31.36 | jsmith | oej: Probably the evil 'r' flag to the Dial() application :-p |
| 15:31.52 | oej | Sorry |
| 15:31.56 | hurdman | http://sebsauvage.net/paste/?c51c51a388323771#8T/52Fx6vLJlOMRnKQ9njwU/09lJpnwaGu/XqKo0ORA= |
| 15:32.08 | hurdman | 172.18.5.252 == caller |
| 15:32.13 | oej | Sorry, If that not is set⦠my code seem to fix this problem. |
| 15:32.43 | hurdman | 172.18.5.225 + 192.168.85.176 == asterisk |
| 15:32.52 | hurdman | 192.168.85.102 == callee |
| 15:32.53 | jsmith | hurdman: That 183 has SDP, so it *is* providing early media |
| 15:33.15 | oej | Everyone but jsmith was aware of that ;-) |
| 15:34.10 | hurdman | i never receive the rtp send from 172.18.5.252 |
| 15:34.20 | oej | Ahh. We forward the progress if we're not single (and no -r) otherwise we start an early bridge |
| 15:34.46 | oej | Instead of "single" we should have a counter and only allow one early media brige |
| 15:35.28 | oej | That feels like very, very old code. |
| 15:35.43 | hurdman | the test is with two linphone and one asterisk server with two different network interfaces |
| 15:35.45 | oej | Can't be a lot of work to fix that. |
| 15:37.51 | hurdman | Is my paste enough understandable ? |
| 15:38.11 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:39.52 | oej | Yes. As file said, this is prevented in teh code. A mystery. |
| 15:40.04 | oej | And I said that it can't be hard to fix, but needs a fix. |
| 15:40.14 | hurdman | ok |
| 15:50.54 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:51.32 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zwpykmzwaguvyevp) |
| 15:51.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:53.34 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:50.34 | mjordan | skrusty: yup, I am |
| 16:50.42 | skrusty | cool |
| 16:50.48 | mjordan | although I haven't looked at mod_http_cache, for very obvious reasons |
| 16:50.54 | skrusty | yes |
| 16:51.08 | skrusty | may i ask how far along? something i'd love to see in * |
| 16:51.20 | mjordan | project plan is here: |
| 16:51.20 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Project+-+URI+Media+Playback |
| 16:51.31 | skrusty | ah cool - will take a look :) |
| 16:51.35 | mjordan | I'd say still in its infancy. I have a branch set up, but probably need to commit some changes to it still. |
| 16:51.43 | mjordan | the project plan is more or less accurate :-) |
| 16:51.58 | mjordan | right now, I'm working on Phase 1. |
| 16:52.08 | mjordan | Which is basically just internal APIs that wrap up the res_http_media_cache |
| 16:52.10 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-tttrhzliasyyffub) |
| 16:52.12 | mjordan | plus unit tests for it. |
| 16:52.25 | skrusty | just reading now |
| 17:00.48 | skrusty | so params would be supported as long as the entire Uri was URI encoded? the next bit is confusing me, URIs in a resource can't be supported. what's meant by resource? Sorry. :) |
| 17:02.04 | skrusty | would it not be simpler to use a different delimiter? ; for example? |
| 17:03.03 | mjordan | skrusty: which part are you referring ot? |
| 17:03.05 | mjordan | er, to |
| 17:03.24 | skrusty | playback of a URI (dialplan) |
| 17:03.43 | mjordan | so, there are several issues. |
| 17:03.55 | mjordan | The first is that '&' is already a delimiter when playing back sounds |
| 17:04.07 | mjordan | that is, I can use Playback(tt-monkeys&demo-congrats) |
| 17:04.12 | skrusty | ah, yes |
| 17:04.30 | mjordan | So, a URI that uses '&' has to be URI-encoded *if* you want to support query params - which we agreed that we did (in -dev conversation) |
| 17:04.39 | skrusty | ok |
| 17:04.42 | mjordan | however, that means you can't support both query params and URI encoded '&' in a resource |
| 17:04.56 | mjordan | since un-encoding the URI will un-encode both, and now you have an invalid URI being specified |
| 17:05.04 | mjordan | it's a small issue, but one that has to get written down at least :-) |
| 17:05.11 | skrusty | ok |
| 17:05.42 | skrusty | now i understand |
| 17:05.55 | mjordan | parallel playback (later on) is complex too :-P |
| 17:06.06 | mjordan | or rather, parallel retrieval to support video playback |
| 17:06.12 | skrusty | in your example, i assumed &format=wav was a query param of the url |
| 17:06.26 | mjordan | looks |
| 17:06.28 | Corydon76 | Speaking as the person who shepherded a core delimiter change (from | to ,) back in the 1.6 days, we _never_ want to have to do that ever again. |
| 17:06.39 | skrusty | :) |
| 17:06.40 | mjordan | Corydon76: AMEN |
| 17:07.01 | mjordan | Still have people come up to us at AstriCon griping about it too. New features work around existing delimiters. Period. |
| 17:08.01 | file | I don't think I heard mention of it this year |
| 17:08.03 | Corydon76 | It was the right thing to do, given that we were already translating commas transparently, and that translation was itself causing problems |
| 17:08.05 | mjordan | skrusty: it is a query param of that URL. When you encode it for usage in the dialplan application Playback, that results in the query operator '&' being encoded as %26. The internal guts will de-URI-encode the string so that passing it to cURL works |
| 17:08.13 | mjordan | file: I think we joked about it this year |
| 17:08.18 | file | mjordan, yeah |
| 17:08.32 | mjordan | goes back to deprecating the dialplan |
| 17:09.06 | Corydon76 | Have y'all fixed SIP realtime yet? /me ducks. |
| 17:10.32 | file | what about it? |
| 17:10.36 | mjordan | Corydon76: If by "fixed" you mean "it works as it always did", then yes. |
| 17:10.38 | Corydon76 | Realtime delimiters, if you really get into it, are hopelessly broken. |
| 17:10.43 | file | oh, that |
| 17:10.48 | mjordan | works as intended |
| 17:11.07 | Corydon76 | Works for the general case. ;-) |
| 17:12.04 | Corydon76 | Who needs multiple key/value pairs with the same key to work, anyway? :-) |
| 17:13.08 | hurdman | http://sebsauvage.net/paste/?c2a3682cf5e3fb2b#eWG1vfcm0MutmWiej9pv2o8qsxmjOpRnRoJl/UaUVpg= |
| 17:13.33 | hurdman | after some test, it seems that i pass into early bridging after call the progress |
| 17:14.56 | mjordan | hurdman: is there a question there? I'd expect that Asterisk would early bridge two channels if progress was indicated from the callee |
| 17:24.00 | seanbright | realtime sucks, don't use it |
| 17:24.03 | seanbright | there. fixed. |
| 17:24.25 | seanbright | goes back to lurking |
| 17:27.42 | jsmith | mjordan: I think you missed the earlier conversation |
| 17:28.19 | jsmith | mjordan: hurdman has Alice calling Asterisk, and Asterisk calling Bob & Charles & JAmes |
| 17:28.47 | jsmith | mjordan: So Asterisk isn't bridging the early media, because it's doing a simultaneous dial of several endpoints |
| 17:29.54 | mjordan | ah |
| 17:31.18 | mjordan | yeah... I'm pretty sure that situation is rather undefined. We don't currently have the ability to mix multiple outbound channels media - or to select which participant 'wins' the early media if multiple channels indicated it. IIRC, we just don't do any early bridging to avoid those situations. Or we pick one at random; I can't recall. |
| 17:31.56 | file | we don't do any |
| 17:45.36 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-eajycnfukhmyjryc) |
| 17:53.57 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-sfajlfbfljtdgugh) |
| 18:08.15 | hurdman | file: mjordan yes , nothing is forwarded. I'll work on a patch, i'll send it to you if it works :) |
| 18:12.11 | mjordan | hurdman: well... how are you planning on defining the behavior here? |
| 18:12.37 | mjordan | the problem is you have multiple outbound channels, any of which can indicate Progress. Who do you pick as the 'winner'? How? Do you attempt to mix the media? |
| 18:13.19 | hurdman | mjordan: in my apps, the last that send a sip progress should receive the media |
| 18:14.07 | hurdman | but perhaps it could be nice to create a parameters to choose between multiple behavior |
| 18:14.31 | hurdman | last/first/none |
| 18:14.40 | hurdman | or something like that |
| 18:14.52 | jsmith | hurdman: Just to make sure I understand.... Alice calls Asterisk, Asterisk calls Bob & Charles & James. Bob starts sending early media, so Asterisk forwards that early media on to Alice... Then Charles starts sending early media to Asterisk, so Asterisk forwards that on *instead* of Bob's media? |
| 18:15.32 | hurdman | jsmith: no, bob send a 183 progress so alice starts send her early media |
| 18:15.47 | jsmith | Wait, what? |
| 18:16.00 | jsmith | Early media comes from the person you are call*ing* |
| 18:16.09 | jsmith | So in this case, the early media comes from Bob. |
| 18:16.40 | jsmith | It's typically not possible for Bob to hear Alice's media until Bob answers... |
| 18:17.07 | hurdman | that's how it works with a direct call or with something like a sip proxy (resiprocate for example), you send a progress to request the media from the caller |
| 18:17.09 | jsmith | thought you were trying to figure out whether to send Bob's early media or Charlie's early media |
| 18:17.12 | file | it's possible to do that |
| 18:17.29 | jsmith | Possibly, but typically not done |
| 18:17.41 | hurdman | jsmith: why ? |
| 18:18.06 | jsmith | hurdman: From a billing perspective, you want to be able to charge for the call before the caller can interact with the system. |
| 18:18.36 | hurdman | and you could want to be able to see who calls you before answer |
| 18:18.46 | jsmith | Let's say that I'm a VoIP provider.... and Frank is my client, and Elisa is calling Frank's company |
| 18:19.04 | jsmith | Elisa calls Frank, but I want to start charging Frank before Elisa can interact with Frank. |
| 18:19.16 | jsmith | hurdman: Typically CallerID is used to identify the caller, not early media |
| 18:19.33 | hurdman | :) not in my case |
| 18:19.50 | jsmith | I'm just saying -- in commercial situtations, early media is typically only one-way until the call is answered. |
| 18:20.00 | jsmith | Otherwise, you could make lots of free phone calls :-) |
| 18:20.13 | hurdman | no problem, i understand your example, i'm just in a different situation |
| 18:20.45 | jsmith | And again, I don't think Asterisk handles your situation, and it's going to require code to do that |
| 18:21.13 | hurdman | yes , now, i know that :) I'll program it if i should |
| 18:31.54 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:31.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:01.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:01.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:56.52 | *** join/#asterisk-dev Simon-- (~sim@2606:6a00:0:28:5604:a6ff:fe02:702b) |
| 19:58.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:58.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:04.08 | Simon-- | can anybody provide a positive for chan_iax2.so working at all since 1.8.19 between two boxes with a single peer (or more) configured, qualify enabled? |
| 20:04.16 | Simon-- | in the 1.8 branch |
| 20:04.56 | mjordan | yes. |
| 20:06.15 | Simon-- | it breaks for me since http://svnview.digium.com/svn/asterisk?view=revision&revision=375893 unless I revert the hunk to chan_iax2.c |
| 20:06.49 | Simon-- | and by break I mean that it seems to get stuck and stops calling recv() or read() or whatever to pull from the socket |
| 20:07.53 | mjordan | Simon--: You have a timing source that is failing to acknowledge in that case, or ast_io_wait is failing. Have you investigated why that would be the case? |
| 20:08.18 | [TK]D-Fender | 1.8.32.1 is the latest release in that branch. The world would have exploded if Digium left it non-functional since 1.8.19. |
| 20:08.34 | [TK]D-Fender | And that's 4 branches behind. |
| 20:09.02 | Simon-- | I see no log of "Timer failed acknowledge" so P suspect it's the ast_io_wait() returning <= 0 path, but I suppose I'll try to poke around there |
| 20:09.28 | Simon-- | I would also expect such explosion...yet this is a very basic test setup, and I have to revert that even on top of 1.8.32.1 just to get it to work |
| 20:10.14 | Simon-- | (this came up while trying to bisect a regression in call handling capacity before a VNAK storm occurs) |
| 20:10.19 | [TK]D-Fender | Simon--: My base statistic would be an indication an "it is just you" scenario. |
| 20:10.33 | Simon-- | mhmm.. hence the first question :) |
| 20:10.37 | [TK]D-Fender | Simon--: Glad you've got a thread to follow on it though... |
| 20:11.00 | WIMPy | Well, it's like I can't transfer calls that cam via IAX any more since 11.7.1, but noone else seems to have noticed. |
| 20:11.03 | mjordan | Simon--: arguably, that check on ast_io_wait should have been if (ast_io_wait(...) == -1) |
| 20:11.51 | mjordan | do you have any timing sources loaded? |
| 20:12.02 | Simon-- | nope |
| 20:12.03 | WIMPy | Oh, and what it looks like transfer=mediaonly doesn't work, either. No idea, since when. Didn;t look a t it before. |
| 20:12.08 | mjordan | well, that would explain what is happening. |
| 20:12.15 | mjordan | heh. |
| 20:12.31 | mjordan | Load a timing source and see what happens. That should work around the problem. |
| 20:12.41 | WIMPy | wishes that everythign was that easy. |
| 20:13.20 | mjordan | Simon--: and if it does work, please do open an issue. That return check on ast_io_wait is wrong. It should only bail if ast_io_wait returns -1. |
| 20:13.58 | mjordan | that being said, I don't think changing the return value is going to 'fix' anything. |
| 20:14.42 | mjordan | The thread would just bail prematurely, which - since it doesn't do anything but trigger timing_read, isn't going to change much. |
| 20:14.57 | mjordan | And since timing_read only happens if you have a timer loaded, well... |
| 20:27.56 | mjordan | er |
| 20:28.04 | mjordan | you have an IAX2 trunk |
| 20:28.35 | mjordan | SImon--: you definitely need to have a timing source. As it is, this isn't going to be a bug, since having a timing source is the only way the trunk handling code gets fired. |
| 20:28.44 | mjordan | (Might be a good documentation update to make sure folks know that) |
| 20:29.20 | WIMPy | Might be even better to print a warning. |
| 20:31.36 | mjordan | {quote} |
| 20:31.36 | mjordan | The only functionality that requires internal timing is IAX2 trunking. |
| 20:31.36 | mjordan | {quote} |
| 20:31.40 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces |
| 20:31.59 | mjordan | WARNING would be nice, but I was pretty sure this was even written down somewhere :-P |
| 20:32.34 | WIMPy | Would make more sense to document in the IAX description, however. |
| 20:38.54 | Simon-- | mjordan: I'd say it's a bug that it used to work and now just hangs strangely with no message... |
| 20:39.37 | Simon-- | (once I stop messing with kernels and confirm) this is just a test environment I revived to bisect another issue, hence the lack of timing source.. |
| 20:44.26 | Simon-- | it seems like it just breaks, so I'd rather it refuse to load (or it work without a timing source).. |
| 20:49.06 | mjordan | Other than fixing the return value, I doubt anyone will spend any time fixing something that is documented to require a timing source |
| 20:49.33 | mjordan | if you'd like to provide a patch, that might get some traction - but beyond that, trunking mode needs a timing source. |
| 20:49.50 | Simon-- | ah. trunk=no here |
| 20:50.05 | Simon-- | unless you just mean iax2 |
| 20:50.17 | mjordan | Hm. Did you file ASTERISK-24600? |
| 20:50.22 | mjordan | I mean IAX2 trunking |
| 20:50.57 | Simon-- | nope..haven't filed anything since about 2009 :) |
| 20:51.05 | jsmith | Ah, IAX2 trunking... |
| 20:51.16 | jsmith | looks back with mixed emotions |
| 20:51.42 | mjordan | ah. That's funny. Someone filed an issue similar to yours while you were discussing it. |
| 20:52.04 | mjordan | Simon--: if you don't have IAX2 trunking enabled, then I'm back to not knowing why reverting that patch would change anything in chan_iax2 for you. |
| 20:52.18 | mjordan | jsmith: I think that's everyone's thoughts. |
| 20:52.21 | Simon-- | in my case, nothing is busy looping or anything.. it just sleeps while netstat shows the recvq building |
| 20:52.35 | mjordan | jsmith: funny now that we're all trying to figure out how to get RTP multiplexed onto a single port, huh |
| 20:52.38 | Simon-- | in related news, the testcase I set up worked first time at reproducing vnak stomrs |
| 20:52.44 | file | I pondered doing the RTP equivalent for fun |
| 20:52.46 | jsmith | mjordan: Mine especially, since it was my idea, and I twisted Mark's arm to implement it |
| 20:53.00 | file | mjordan, sorta |
| 20:53.26 | Simon-- | has anything changed since 1.8 that reduces the .. erm.. possibly explosive results of VNAK? :) |
| 20:53.34 | jsmith | mjordan: It has saved a former employer more than $20k a month for the last 13 or more years... |
| 20:53.57 | Simon-- | just packet overhead savings? |
| 20:54.11 | Simon-- | that's a lot of packets... |
| 20:56.40 | jsmith | Simon--: Yep :-) |
| 20:57.02 | jsmith | Every little bit helps :-) |
| 20:58.05 | Simon-- | you could run it over cslip ;) |
| 21:07.53 | WIMPy | Uhh. Someone seems to like to scroll. Maximum line length in chan_iax2.c: 274 |
| 21:20.01 | Simon-- | yeah, it works with res_timing_dahdi.so loaded and a happy "timing test"..otherwise, with that not loaded, it gets stuck as before since that commit, with/without trunk=no |
| 22:13.11 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 23:53.31 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-cxzicqoyflyclxrd) |