| 00:07.15 | *** join/#asterisk-dev luckman212_ (~irc@2001:470:8abb:0:18dd:b7aa:e728:5098) |
| 00:08.51 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 00:09.31 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 01:04.11 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:04.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:44.33 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:44.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:54.49 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:54.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:57.29 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:57.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:57.47 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:12.15 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 05:21.28 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 05:21.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:05.50 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 06:05.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:15.34 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1003) |
| 07:15.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:16.06 | oej | Morning folks |
| 07:34.23 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f401:ff2c:c395:e00e) |
| 08:09.29 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:09.29 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:25.23 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 09:39.09 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 09:39.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:27.26 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 11:00.13 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 11:00.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:27.03 | *** join/#asterisk-dev F|shie (~chatzilla@182.177.33.56) |
| 11:46.55 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 11:58.36 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 13:14.49 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hrgpuzyzskruhwrp) |
| 13:14.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:22.43 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 13:45.56 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-mpokjaarhoeaflbn) |
| 13:56.08 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 13:57.53 | mjordan | oej: ping :-) |
| 13:58.33 | mjordan | so... without manipulating the RTP layer's current handling of dropping DTMF packets, there are certain streams of out of order DTMF that will get dropped on the floor completely |
| 13:58.59 | mjordan | something has to re-order that information |
| 14:03.07 | mjordan | For example, if you got an END (3), END (4), BEGIN (1), END (2), the current RTP layer will ignore the digit completely |
| 14:03.33 | opticron | the 1 digit? |
| 14:03.39 | mjordan | heh |
| 14:03.48 | mjordan | sorry, the (X) is the order they should have arrived int |
| 14:03.49 | mjordan | in |
| 14:03.57 | opticron | ah |
| 14:13.11 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-bgrsicybyjewutmf) |
| 14:16.28 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 14:16.41 | oej | Pong |
| 14:17.09 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 14:17.18 | oej | But between BEGIN and END you have continue packets right? |
| 14:18.16 | mjordan | oej: only if a DTMF jitter buffer has been placed on the channel. In that case, the RTP layer creates ast_frames for whatever it receives |
| 14:20.55 | oej | Let's discuss the problem and not your solution. |
| 14:20.58 | oej | :-) |
| 14:21.04 | mjordan | oej: sure |
| 14:21.13 | oej | So when sending DTMF you have BEGIN, continue, continue, END. |
| 14:21.28 | mjordan | not sending, receiving :-) |
| 14:21.30 | oej | If the BEGIN is misordered we still have continue and can react upon them and start playing out. |
| 14:21.40 | oej | If we only get END we have a duration and can playout |
| 14:21.52 | oej | If we get END before continue we still get the duration right. |
| 14:21.57 | oej | So what's the issue you see? |
| 14:22.18 | mjordan | the current issue that occurs in two parts |
| 14:22.54 | mjordan | first, if we get an END before a BEGIN, we treat it as two separate digits. This is most likely due to the bridging layer attempting to handle DTMF issues in non-RFC2833 situations, where a BEGIN may not get created at all due to interference in the audio |
| 14:22.56 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:22.57 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:23.12 | mjordan | or, rather, END before BEGIN or continuation |
| 14:23.35 | mjordan | as such, changes were made in the RTP layer to prevent that from occurring - which is needed to preserve the behavior in the bridging layer |
| 14:23.53 | mjordan | so if we get BEGIN or continuation packets when we don't expect them, they get discarded |
| 14:24.20 | oej | So we need to store the latest timestamp and ignore that begin. |
| 14:24.37 | mjordan | that is what happens |
| 14:24.52 | oej | We should just ignore that BEGIN, since we already ahve an END with a duration. |
| 14:24.58 | oej | No need to reorder or do anything else |
| 14:25.19 | oej | Just save the last timestamp for DTMF. If we get another BEGIN for a current DTMF we're handling, ignore that BEGIN. |
| 14:25.39 | oej | We have really huge issues with DTMF delays in production networks. |
| 14:25.45 | oej | A jitter buffer will cause harm. |
| 14:26.12 | oej | The standard is written in a way so that we should be able to capture everything in the END packet, which is sent multiple times. |
| 14:26.31 | oej | If we capture the BEGIN we have a better chance of playing out in good time |
| 14:27.10 | mjordan | hm |
| 14:27.20 | oej | I don't think I have fixed that particular situation in my code, but it should be easy to add. |
| 14:27.21 | mjordan | the current RTP layer does discard END packets if they arrive before BEGIN |
| 14:27.32 | oej | That's wrong too. |
| 14:27.44 | mjordan | maybe :-) I'm not prepared to make that assumption |
| 14:27.45 | oej | The begin doesn't have the information we get in the END |
| 14:27.56 | oej | so if anything should be discarded, it's the BEGIN |
| 14:28.03 | oej | continue and END have durations |
| 14:28.16 | mjordan | the problem is, if we don't discard the END before the BEGIN, the current bridging layer will emulate the BEGIN and start the DTMF (which is okay) - but a subsequent BEGIN will trigger a second DTMF digit |
| 14:29.37 | mjordan | the problem is, changing the bridging layer's handling of DTMF will affect non RFC-2833 DTMF capable devices in ways that may be difficult to predict |
| 14:30.24 | oej | A subsequent BEGIN with the same timestamp or another DTMF completely? |
| 14:30.40 | oej | Adding a continue frame did not hurt in our tests. |
| 14:30.47 | oej | Have you looked at all at my branch? |
| 14:31.10 | mjordan | oej: yes, but since the changes to the bridging layer are ... extensive? ... I haven't fully consumed it all yet :-) |
| 14:32.02 | mjordan | A subsequent BEGIN with the same packet timestamp will trigger a new DTMF digit if an END with the same timestamp is passed to the bridging layer first |
| 14:34.43 | mjordan | as far as jitter buffers being harmful: (1) its optional, and you don't have to put it in the mix unless you have serious network problems delaying arrival of packets; (2) if you are in that situation you already have delays, and a properly configured jitter buffer won't affect that significantly |
| 14:35.12 | oej | mjordan: The changes to the rtp briding are big, but that's what we need to fix the issues we have. I noticed even more bad issues recently with the DTMF emulation. It's really bad. If we get SIP INFO with 250 ms it can easily emulate 3 seconds of DTMF. |
| 14:35.22 | oej | We have to do something substantial here. |
| 14:35.52 | oej | I'm trying to tell you that the jitter buffer is NOT needed, as we have all the data. |
| 14:36.13 | oej | If you receive END, save the timestamp and then receive a BEGIN with the same timestamp, just drop it. Problem solved without jitter buffers. |
| 14:36.51 | mjordan | oej: I'm not addressing other problems with DTMF :-) |
| 14:36.58 | mjordan | oej: But I agree there are lots of other problems |
| 14:37.02 | oej | You are adding complexity and delay where it is not needed. The protocol handles it if parsed correctly. |
| 14:37.21 | oej | We should really address all the issues with DTMF? But I agree that is another issue. |
| 14:37.33 | mjordan | oej: I'll explore what happens if the RTP layer is tweaked to change its passing of END packets - but I have a sneaky suspicion that was tried previously |
| 14:37.34 | oej | I'm just trying to get you to understand and look into what I've already done. |
| 14:37.39 | mjordan | I'll comment on the review with what I find |
| 14:37.53 | mjordan | oej: no worries, I've been looking - its quite extensive :-) |
| 14:37.58 | oej | Thanks for taking time to discuss this. Looking forward to your results. |
| 14:38.02 | mjordan | np :-D |
| 14:38.33 | oej | There are reasons why it's extensive. There where so many issues. It was bigger, but twilson committed parts of it (the feature.c parts) already as we could isolate that from the rest. |
| 14:38.43 | oej | ping otherwiseguy |
| 14:39.13 | oej | I guess Kansas is off line ;-) |
| 14:39.31 | otherwiseguy | oej:howdy |
| 14:39.46 | oej | Howdy. Just talked about you. But more about DTMF. |
| 14:46.41 | otherwiseguy | I just assume that DTMF will always be subtly broken somewhere. :) I can't count the number of times little tweaks have been done to rfc2833 DTMF. |
| 14:55.57 | oej | I've done a massive tweak :-) |
| 14:56.09 | oej | The most important part was to add DTMF_CONTINUE frames |
| 14:56.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:56.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:57.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:57.04 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:02.47 | oej | I think I'm done with PRACK for now. |
| 15:03.57 | mjordan | oej: you have someone in #asterisk who might be willing to test it some more for you |
| 15:04.20 | mjordan | if you're looking for more testers |
| 15:06.46 | oej | They can test it freely, it's open source :-) |
| 15:06.54 | oej | We passed the certification today. |
| 16:07.47 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:29.57 | *** join/#asterisk-dev oej_ (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 16:29.57 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 16:49.01 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:51.02 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:10.52 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 18:04.26 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 18:35.38 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:35.38 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:39.04 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.40.134) |
| 18:39.05 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:19.47 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 19:19.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:28.54 | jsmith | oej: Congrats on getting the PRACK stuff certified... that sounds awesome... |
| 19:30.19 | oej | Thanks! |
| 20:18.34 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 20:18.34 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 20:23.57 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 21:00.41 | *** join/#asterisk-dev jgowdy (jgowdy@jgowdy.net) |
| 21:01.29 | jgowdy | I'm working on a patch to differentiate error conditions from empty list conditions and I'm trying to figure out what would be the preferred way to handle that as far as Asterisk development style goes |
| 21:02.13 | jgowdy | If a function returns a struct pointer, and it currently returns NULL in case of error or empty list, would it be acceptable to use struct pointer -1 to represent failure? |
| 21:03.35 | mjordan | jgowdy: or you could have the function return 0 on success, positive on failure, and take a double pointer to the struct that it initializes |
| 21:04.20 | mjordan | that way you don't have a ternary return (< 0 failure, 0 empty list, >0 allocated struct) |
| 21:04.37 | jgowdy | Is that the way it's done elsewhere in Asterisk? I mean I can obviously make something that works, but I've been trying to make my patches "fit in" ;) |
| 21:05.24 | jgowdy | I guess that's as good a solution as any |
| 21:05.27 | mjordan | it is done that way in some places, but its pretty rare for a consumer to view a NULL return pointer as anything other than failure |
| 21:06.05 | jgowdy | I mean I like the style of returning the thing you're "producing", but to pull that off you usually need exceptions |
| 21:06.08 | jgowdy | hehe |
| 21:06.29 | jgowdy | in this instance, I'm talking about get_agi_cmd |
| 21:06.48 | jgowdy | which returns NULL, causing a wait on the channel, rather than being recognized as an error |
| 21:07.07 | jgowdy | ends up taking a 30 second timeout overall for everything to "notice" what happened and clean up |
| 21:07.47 | mjordan | hm. |
| 21:07.55 | jgowdy | I'll make a patch the double pointer way |
| 21:08.17 | mjordan | jgowdy: you could approach it another way as well |
| 21:08.22 | jgowdy | It doesn't solve the issue in question, obviously that can still take place, but like my last patch it's better that we fail and fail quickly |
| 21:08.33 | mjordan | jgowdy: agreed |
| 21:09.29 | mjordan | jgowdy: when the list is empty, does it occur after some number of successful executions, or does it happen usually in off nominal situations only? |
| 21:10.09 | jgowdy | I believe it's very common that it returns NULL because the work list is empty, and very uncommon for the error condition to happen |
| 21:10.18 | jgowdy | I mean the error message starts with "Huh?" |
| 21:11.31 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@66-232-81-197.ctcweb.net) |
| 21:11.33 | mjordan | you could check to see if the list is empty before even attempting to enter into the get_agi_cmd loop |
| 21:11.44 | mjordan | er crap |
| 21:11.45 | mjordan | nm |
| 21:11.54 | mjordan | not so much, given that the list is a channel datastore |
| 21:12.11 | jgowdy | yeah, in the end, it's the same operation |
| 21:12.17 | jgowdy | I'll just do the double ptr to the struct way |
| 21:12.22 | mjordan | kk |
| 21:12.27 | jgowdy | not great, but least change for a smooth over fix |
| 21:13.24 | jgowdy | This hacking on Asterisk has been fun, I haven't debugged this much C in years, probably since college |
| 21:13.39 | jgowdy | It does make me wish for exceptions though |
| 21:17.47 | mjordan | jgowdy: yeah - functions shouldn't return something that can be interpreted in multiple ways |
| 21:20.59 | jgowdy | mjordan: do you know Bill Miller? |
| 21:21.22 | mjordan | jgowdy: I don't think so :-) |
| 21:21.46 | jgowdy | Oh, he used to be a VP or Product Manager or something at Digium. He just consulted with us. Just curious. |
| 21:22.16 | mjordan | that's quite possible, I haven't been with Digium for a super long time :-) |
| 21:22.18 | leifmadsen | I think Bill Miller was before mjordan days |
| 21:22.34 | jgowdy | ahh |
| 21:22.37 | malcolmd | he was |
| 21:27.46 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hrgpuzyzskruhwrp) |
| 22:05.35 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:05.35 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:21.11 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 23:17.28 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |