| 00:04.53 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 00:38.20 | *** join/#asterisk-dev joshelson (~joshelson@23-31-202-185-static.hfc.comcastbusiness.net) |
| 00:42.51 | *** join/#asterisk-dev joshelson (~joshelson@23-31-202-185-static.hfc.comcastbusiness.net) |
| 01:18.16 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 01:18.16 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:19.10 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:88c5:49d6:1cba:5daf) |
| 01:19.10 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 02:27.33 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 03:07.54 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 03:27.30 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 05:01.25 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 05:48.38 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 06:19.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.37) |
| 06:48.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:52.08 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:52.08 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:57.04 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:57.04 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:02.14 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 07:50.14 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 07:50.23 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 08:41.41 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:11.15 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:11.15 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 09:20.40 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:20.40 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 09:54.08 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:06.47 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:09.00 | jkroon | i'm not sure if this is still an issue with asterisk 13, but for 11.25 i'm looking at a way to allow rtp to bridge natively even if there is a Local/ channel inbetween two rtp enabled technologies. My use-case is a SIP channel that Dial(Local/.../n)s (can't get this out of the way), and that created channel again Dial(SIP/...)s. Other than the Local/ channel there is no reason why RTP can't be delegated. |
| 10:09.19 | jkroon | I've got two possible strategies that could maybe work (without knowing the code). |
| 10:10.07 | jkroon | 1. In chan_local, add code that'll basically just bridge to the other channel's sip_rtp_glue. |
| 10:10.54 | jkroon | sorry, mistype there, rtp_glue_register, and then use rtp_engine's code again to find the correct glue functions to call again whenever local rtp is invoked. |
| 10:11.32 | jkroon | not sure if that's possible, there may be locking issues involved since the bridge does lock both channels, so this may be a lock issue. |
| 10:12.09 | jkroon | 2. in rtp_engine - have special local channel handling that tries to find the actual "external" channel, then rather lock and bridge with that. |
| 10:12.29 | jkroon | since there are two bridges which may get this invoked ... may be a problem too, so i'm not sure whether that'll work. |
| 10:13.00 | jkroon | if there are any other strategies that I could look at I'd appreciate the input. |
| 13:10.43 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-240-195.try.wideopenwest.com) |
| 13:10.44 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 13:12.55 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hmkjxuqafygqmvqq) |
| 13:12.55 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:16.35 | file | falls over |
| 13:31.50 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 13:40.16 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-hjwmjmmpkpsquhfk) |
| 13:40.16 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:40.30 | seanbright | security e-mail character encoding is not on point |
| 13:40.57 | seanbright | ââ¬Åsymmetric_rtpâ⬠|
| 13:41.00 | seanbright | lulz |
| 13:52.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:52.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:55.20 | file | :D |
| 14:04.30 | seanbright | jenkins is exhausting |
| 14:04.43 | seanbright | and i'm not even maintaining it |
| 14:06.48 | file | Jenkins wasn't the problem for those, it was network |
| 14:06.55 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:06.55 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:07.01 | seanbright | well then, i retract my statement |
| 14:07.13 | seanbright | jenkins is a breath of fresh air |
| 14:13.32 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gjfwfrbfbankvvag) |
| 14:13.32 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:29.44 | bford | When we are handling streams of a certain type, we still want to increment the total number of streams of that type even if the media state is removed since streams are never removed, right? |
| 14:33.13 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 14:36.21 | file | bford: in my change I made it so they weren't counted |
| 14:36.38 | file | I had the same ponderance though, and I think active streams would be a better way to state it |
| 14:37.07 | file | a removed stream really has no type, it's just a placeholder |
| 14:37.57 | bford | when you say active streams, are you referring to the type_streams variable that gets incremented? that's what that variable is keeping track of? |
| 14:40.46 | file | I think it's reasonable for it to only keep track of the active streams - those that aren't removed |
| 14:41.31 | bford | gotcha, i think i have a fix for it (making it go through with reinvite was causing a crash elsewhere), i was mostly concerned with what should and shouldn't happen within that loop |
| 14:41.42 | file | nods |
| 14:47.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 14:47.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:48.53 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-xpscqggsqctyunrd) |
| 14:48.53 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:05.49 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-lniianhaoohdzeab) |
| 15:05.50 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 15:07.48 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 15:15.58 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 15:27.28 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 15:47.12 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:47.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:10.29 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-phfclijneeilunxp) |
| 16:10.29 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:22.08 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-itgbfudqespuiwku) |
| 16:22.08 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:43.13 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d003ca5feeae8d97b21.ipv6.abo.wanadoo.fr) |
| 16:55.10 | seanbright | translate.c: no samples for ulawtolin |
| 16:55.19 | seanbright | what would be the most obvious thing to look for when that appears? |
| 16:58.36 | file | I don't really have an answer for that. A frame with no samples... came from... somewhere? |
| 16:59.11 | rmudgett | It may not be a media frame. |
| 17:00.11 | seanbright | the client is bria x, so i assume some kind of bullshit |
| 17:06.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.cablep.bezeqint.net) |
| 17:06.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:10.59 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 17:11.26 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
| 17:28.34 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 17:29.10 | elcontrastador | Building Asterisk 15.0.0rc1 on Ubuntu 16.0.4.3LTS get the following error during make: ./libasteriskssl.so: undefined reference to `CRYPTO_num_locks'. Googling this has been unsuccessful for me... |
| 17:34.06 | seanbright | file / rmudgett: Extended report (RFC 3611) |
| 17:34.07 | seanbright | ? |
| 17:34.20 | file | what aboot XR? |
| 17:34.33 | seanbright | could that be my "no samples for..." jazz? |
| 17:34.43 | seanbright | looks like the only weird packet in my capture |
| 17:34.52 | file | I don't think so |
| 17:37.41 | seanbright | which field in the packet defines the number of samples? |
| 17:40.09 | file | there is no field for it, it's calculated |
| 17:40.25 | file | as it's ulaw it would be the data length of the payload |
| 17:40.31 | file | and the timestamp would go up by it |
| 17:40.35 | seanbright | got it |
| 17:49.34 | elcontrastador | https://gist.github.com/elcontrastador/a9053a3eddda52a18d4c2bd4216524c1 |
| 17:50.46 | elcontrastador | i'm sorry..got this figured out... |
| 18:02.39 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 18:15.00 | kharwell | file: I need to be reminded again why in simple bridge once two channels join we need to do a topo request change making the two channels have the same topology? |
| 18:15.39 | file | kharwell: for a better experience, to try to elevate things to more simultaneous streams |
| 18:15.56 | kharwell | shouldn't those things each have their own streams and topology and the bridge mapping takes care of streams and frames exchanging? |
| 18:16.18 | file | they may be different topologies |
| 18:16.24 | file | one might have 1 audio 1 video, the other 2 audio 2 video |
| 18:16.37 | file | trying to add the missing streams doesn't hurt things (they'll reject or decline the streams) |
| 18:17.47 | kharwell | it seems to be causing problems when two endpoints negotiate two different codecs, but can translate. Once the second joins the request change goes out. A reinvite is sent to the other endpoint with the new codec info, but the endpoint returns 500 negotiate failure since it can't handle that codec then things hang up |
| 18:18.22 | file | was the codec negotiated already? |
| 18:18.33 | file | or did it try to add the codec after initial |
| 18:19.04 | file | if it's after initial you'll need to check the SDP RFC to see if that's allowed or not, and we may want to restrict this stuff to non-default streams if that's causing a problem with endpoints |
| 18:19.12 | file | und dog walk time |
| 18:21.59 | seanbright | potentially dumb question... |
| 18:22.00 | seanbright | https://github.com/asterisk/asterisk/blob/master/main/frame.c#L641-L650 |
| 18:22.10 | seanbright | why are we returning in those cases? |
| 18:35.49 | kharwell | seanbright: I'm not sure (even looked through the log to see if there was a reason). Seems like they should be printed? My guess is someone may have felt things might be too verbose? Thus the comment maybe |
| 18:36.01 | rmudgett | I'd say for the VOICE and VIDEO frames so we don't spam the log. The RTCP frames less so, but they happen on a regular basis. |
| 18:47.31 | file | omg so humid |
| 18:52.17 | seanbright | ok, so it's not just a general purpose frame dump |
| 18:52.34 | seanbright | will modify locally |
| 19:00.03 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:00.03 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:19.27 | kharwell | file: it happens after both sides negotiate (well waiting on the final ack from the originator, but reinvite gets delayed due to transaction still going). |
| 19:24.56 | kharwell | also it wasn't trying to add a codec in the reinvite, but was a whole new singular codec being offered. It was the codec from the other side |
| 19:24.57 | *** join/#asterisk-dev joshelson (~joshelson@206.205.80.228) |
| 19:25.17 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 19:25.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:28.10 | kharwell | for instance endpoint A (g722 only) calls endpoint B (ulaw only). Both sides negotiate correctly, translation gets setup, but then for instance when B enters the bridge the topology on A changes to B's and a refresh reinvite gets sent to A with ulaw in it. Which A rejects as it doesn't support it, so call ends |
| 19:33.24 | file | in a meeting, will respond soon |
| 19:36.22 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:36.22 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:38.37 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:38.37 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:41.17 | file | kharwell: what is the endpoint config for A? |
| 19:41.21 | file | g722 and ulaw? |
| 19:45.20 | kharwell | both endpoints are: allow=!all,g722,ulaw; |
| 19:45.40 | file | interesting |
| 19:46.07 | file | kharwell: so check the RFC for what should happen in a subsequent offer/answer for codecs :D |
| 19:47.53 | kharwell | file: I just did - Request File Comment! |
| 19:48.00 | kharwell | ugh which I guess you technically did too |
| 19:48.20 | file | :D |
| 20:21.51 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 20:21.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:30.54 | seanbright | do we accept ws only patches? |
| 20:31.19 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01cb0583d31d003ca5feeae8d97b21.ipv6.abo.wanadoo.fr) |
| 20:32.21 | file | seanbright: do you want to? |
| 20:34.52 | seanbright | i mean... i don |
| 20:34.59 | seanbright | 't want to turn off a potential contributor |
| 20:35.15 | seanbright | but at the same time, are we really going to cherry pick that to release branches? |
| 20:35.26 | seanbright | i'll let him down easy |
| 20:50.31 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 20:50.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:55.04 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.cablep.bezeqint.net) |
| 20:55.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:38.13 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-240-195.try.wideopenwest.com) |
| 21:38.13 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 22:25.40 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 22:27.36 | joshelson | Does there currently exist an ARI-driven way to send a SIP NOTIFY to an endpoint ... equivalent to AMI PJSIPNotify? |
| 22:28.02 | file | no |
| 22:30.54 | cresl1n | sends file a SIP NOTIFY |
| 22:31.02 | file | notifies cresl1n to go home |
| 22:33.25 | kharwell | but who notifies the notifier |
| 22:33.53 | cresl1n | notifies file to watch Youtube |
| 22:34.10 | cresl1n | kharwell: don't start that again |
| 22:36.28 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:e12a:22e:4a51:ab60) |
| 22:36.29 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:37.17 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:e12a:22e:4a51:ab60) |
| 22:37.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:38.09 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:e12a:22e:4a51:ab60) |
| 22:38.09 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:04.40 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-gjfwfrbfbankvvag) |
| 23:22.14 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@wsip-98-179-138-226.ri.ri.cox.net) |
| 23:22.14 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 23:31.22 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 23:43.06 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:43.06 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |