| 00:25.23 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 00:35.28 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:c4e9:9f37:6ba1:5e78) |
| 00:35.28 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 00:40.23 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 00:44.33 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:1186:a422:beaf:7ecc) |
| 00:44.33 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:27.18 | *** join/#asterisk-dev joshelson (~joshelson@23-31-202-185-static.hfc.comcastbusiness.net) |
| 02:05.57 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 02:05.57 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 02:09.51 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:1443:536e:fbd8:ffd0) |
| 02:09.52 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 02:21.51 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 02:21.52 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 02:36.37 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:37.42 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:9013:b6f9:57c7:2c58) |
| 02:37.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 02:41.02 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 02:41.02 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 04:33.41 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 04:38.07 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:b813:ba30:d026:575a) |
| 04:38.08 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:02.32 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 05:13.19 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 05:37.32 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 05:57.00 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 06:12.06 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 06:41.35 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 06:48.07 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:50.47 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:50.47 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:59.43 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:59.44 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:19.39 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:47.00 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:07.59 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:07.59 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:50.05 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-133-140.dialup.adsl.anteldata.net.uy) |
| 09:00.17 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 09:11.33 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 10:12.04 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 10:46.14 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 11:56.31 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-133-140.dialup.adsl.anteldata.net.uy) |
| 12:08.47 | tsearle | is the asterisk bugtracker down? I'm hanging on the login screen |
| 12:09.46 | file | the authentication system is unhappy, I've nudged IT |
| 12:10.45 | tsearle | anyhow I'm still digging to find out why, but the changes in 13.17 to asymetric codings broke our transcoding tests |
| 12:11.19 | tsearle | our tests indicate that if the called party sends a codec different from the preferred codec they mentioned in the 200 OK |
| 12:11.37 | tsearle | asterisk no longer switches to that codec, (resulting in asymetric codecs) |
| 12:12.07 | tsearle | reverting 996a4791ff123e80d71d44cb0fd13bb201d197b1 makes our tests happy |
| 12:14.10 | file | ok |
| 12:15.19 | tsearle | do you have an idea why would that be? my best guess so far is that you only put 1 format into caps, thus it can't switch because it doesn't know of the other formats |
| 12:15.52 | tsearle | but I can do more digging if you don't have an idea offhand |
| 12:16.05 | file | I don't, but your explanation wasn't detailed enough |
| 12:16.44 | file | that is: if an RTP packet of ulaw is received on channel A while sending g722 on channel A, sending is not switched to ulaw? |
| 12:16.58 | tsearle | ok, in my specific case A calls asterisk, which in turn calls B |
| 12:17.37 | file | or if you are referring to ulaw comes in channel A, gets passed to channel B, channel B negotiated g722 and ulaw (but is currently sending g722) it doesn't switch/send ulaw |
| 12:18.46 | tsearle | A part sends 18 8 0 101 in his invite & sends g729 (18) |
| 12:19.13 | tsearle | b party also sends 18 8 0 101 in 200 ok |
| 12:19.21 | tsearle | but sends A-law |
| 12:19.49 | tsearle | expected behaviour is that native bridge shuts down and asterisk transcode |
| 12:20.00 | tsearle | so that B leg is A-law both directions |
| 12:20.07 | tsearle | and A leg is 729 both directions |
| 12:20.45 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:ddde:10dc:b0be:e8e3) |
| 12:20.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:20.54 | tsearle | make sense? |
| 12:20.57 | file | yes |
| 12:21.37 | tsearle | in 13.17 I think the native bridge isn't getting shut down and the codecs remain in async |
| 12:21.56 | file | the code is there that should update things appropriately, on reading of RTP |
| 12:22.25 | tsearle | <PROTECTED> |
| 12:22.33 | tsearle | that line never appears in the log |
| 12:22.56 | file | then you'd need to look at the formats of things to see why |
| 12:23.14 | tsearle | allright, I'll dig more |
| 12:23.45 | tsearle | the codec code of ast really drives me insane to follow though, heh |
| 12:23.46 | file | for example the code directly above that may be dropping the frame |
| 12:24.50 | tsearle | the frames aren't getting dropped, I know that I am getting packets (received rtp being validated by rtpdump) |
| 12:53.51 | file | seanbright: your change replaces dan_j's right? |
| 12:56.20 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-wylfwqomwbtvoosb) |
| 12:56.20 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:58.20 | gtjoseph | seanbright: and is dan_j's testsuite test still applicable to your versions? |
| 13:02.45 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:08.37 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-lttpjmhofapmdsnn) |
| 13:08.37 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:15.07 | file | buildy build |
| 13:16.13 | jamesp_ | Hey @gtjoseph, @seanbright - i promised i'd let you know the issues. It's quite complex, but essentially we run consul and consul was interfering with asterisk and corosync, such that when asterisk restarted it kicked corosync to update config. This is why it didn't load automatically but did with a load module. We also found we need 13.17.0 otherwise asterisk crashed on a corosync show members (were on 13.15.1 before). Thanks |
| 13:16.18 | jamesp_ | me in the right direction :-) |
| 13:16.44 | gtjoseph | good to know, thanks for the update! |
| 13:18.20 | *** join/#asterisk-dev joshelson (~joshelson@50-206-51-2-static.hfc.comcastbusiness.net) |
| 13:27.31 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:27.31 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:30.41 | file | cresl1n: well, well, well |
| 13:30.49 | tsearle | waves! |
| 13:48.40 | *** join/#asterisk-dev joshelson (~joshelson@204.237.221.84) |
| 14:03.25 | file | SIPp, YOU WON'T BREAK ME! |
| 14:04.31 | gtjoseph | it breaks everyone eventually |
| 14:07.21 | seanbright | file: yes |
| 14:07.31 | seanbright | gtjoseph: no, i am working on testsuite changes today |
| 14:07.36 | gtjoseph | kk |
| 14:08.47 | file | seanbright: cool |
| 14:10.44 | seanbright | turns out to not be much different than his patch |
| 14:14.42 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:14.42 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:17.09 | tsearle | [Jul 27 14:13:03] DEBUG[14039][C-00000000] bridge_native_rtp.c: Bridge '04885256-4b48-49b5-a4ba-8394d594e7ab': Packetization differs between RTP streams (0 != 20 or 20 != 0). Cannot native bridge in RTP |
| 14:17.34 | tsearle | ok, I think that native bridge never did the right thing, but was never used |
| 14:17.42 | tsearle | ast_format_cap_append(caps, best, ast_format_cap_get_framing(joint)); |
| 14:17.48 | tsearle | was added in the patch |
| 14:18.09 | tsearle | so now that you got the framing properly set, native bridge started to happen |
| 14:19.56 | tsearle | I'm thinking that bridge_p2p_rtp_write should check to see if the packet matches the nativeformat, and if not bail |
| 14:21.28 | tsearle | no, that wouldn't be enough I guess, break the bridge if rawread != rawwrite? |
| 14:22.16 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:25.59 | file | if the formats aren't compatible then the bridge shouldn't happen in the first place |
| 14:26.11 | tsearle | they are compatible |
| 14:26.14 | tsearle | just asymmetric |
| 14:26.39 | file | they can't be compatible then, because it's exchanging RTP packets without transcoding |
| 14:27.09 | *** join/#asterisk-dev darkunderlord (~travis@oscarwinski.wintek.com) |
| 14:28.22 | tsearle | well if I negotiate 3 codecs in the sdp, then all 3 are considered compatible |
| 14:29.16 | tsearle | but when want to force codecs to be symmetric, you really want to delete the other caps once you get that first rtp packet |
| 14:31.02 | file | nativeformats should already contain a single format when asymmetric is not enabled, and if it changes on ingress that should trigger a re-check of the underlying bridge technology in use |
| 14:31.15 | file | but because P2P is enabled, that's not getting triggered |
| 14:31.39 | file | if that frame is allowed to go through normally non P2P then it'll fix itself |
| 14:32.31 | tsearle | yes, but but the p2p bridge needs to bail first |
| 14:32.55 | tsearle | we setup the p2p bridge thinking everybody will go 729 |
| 14:33.15 | file | the frame needs to not go through p2p |
| 14:33.22 | tsearle | yes |
| 14:33.24 | file | you don't have to bail p2p yourself |
| 14:33.35 | file | it'll bubble up, nativeformats will change on the channel, the bridging core is notified |
| 14:33.40 | file | re-evaluation is done, new bridge technology chosen |
| 14:33.46 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-98-87.dialup.adsl.anteldata.net.uy) |
| 14:34.02 | tsearle | but if the p2p bridge returns null (it happily forwarded it) |
| 14:34.09 | tsearle | then the check's and update never happen |
| 14:34.15 | file | I know, that's what I said earlier |
| 14:34.57 | tsearle | so p2p_rtp_bridge_write needs to detect this and return -1 right? |
| 14:35.44 | tsearle | so that the frame can get fed to the core and re-calculation to happen |
| 14:36.18 | file | probably |
| 14:38.53 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-llndqmaqqhxhdhog) |
| 14:38.53 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:42.14 | file | seanbright: I want to set the verify_* tests on fire |
| 14:42.40 | file | yappcap crams my style |
| 14:43.49 | tsearle | ah well, I'll try to find a way to test for that tomorrow |
| 14:43.54 | tsearle | g'day all! |
| 14:48.43 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 15:35.32 | *** join/#asterisk-dev leedm777 (~textual@63.92.231.41) |
| 15:35.32 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 15:43.15 | seanbright | how does one run 'pjsip set logger on' in a testsuite test? |
| 15:43.49 | file | you can turn it on explicitly in the pjsip.conf file |
| 15:44.02 | file | using a global section with type=global and debug=yes |
| 15:45.20 | seanbright | thanks |
| 16:12.55 | file | seanbright: thanks! |
| 16:16.47 | seanbright | no... thank YOU |
| 16:20.04 | *** join/#asterisk-dev dakudos (~dakudos@c-73-243-248-133.hsd1.co.comcast.net) |
| 16:21.30 | *** join/#asterisk-dev leedm777 (~textual@73.106.77.36) |
| 16:21.30 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:48.10 | tm1000 | file: ok I got a real core dump for you |
| 16:48.11 | tm1000 | http://pastebin.freepbx.org/view/6d2ad0f4 |
| 16:48.54 | tm1000 | gtjoseph: seems like its dpma again |
| 16:48.55 | file | you changed the max pkt length in your PJSIP build, and DPMA doesn't currently like that |
| 16:49.03 | tm1000 | file: ugh... |
| 16:49.12 | tm1000 | ok we talked about changing that recently do you remember file ? |
| 16:49.15 | file | an issue was just opened against DPMA for that |
| 16:49.17 | tm1000 | so now I need to reset that |
| 16:49.19 | tm1000 | ahh |
| 16:49.24 | tm1000 | file: can you send me the issue |
| 16:49.31 | file | no, it's an internal one |
| 16:49.35 | tm1000 | booo |
| 16:49.42 | file | it has to be resolved before the next release, as the packet size was bumped up |
| 16:49.45 | tm1000 | file: so advice? reset the packet length for now |
| 16:49.53 | file | that's pretty much all you can do |
| 16:49.53 | gtjoseph | well, hold on |
| 16:50.08 | tm1000 | ok holding. |
| 16:50.09 | gtjoseph | it works with 13.17 and 14.6 |
| 16:50.19 | tm1000 | gtjoseph: what works? |
| 16:50.36 | file | gtjoseph: they have their own PJSIP build |
| 16:50.43 | tm1000 | file: what did you set the packet size in the next build to |
| 16:50.48 | gtjoseph | i thought they were using bundled |
| 16:50.53 | tm1000 | gtjoseph: we are |
| 16:51.00 | tm1000 | but we needed to increase the SDP packet size |
| 16:51.09 | tm1000 | and file said go edit the pjsip site_config.h |
| 16:51.15 | tm1000 | so we did... and now we are here :-) |
| 16:51.23 | tm1000 | just curious what the size is going to be in the next release |
| 16:51.27 | gtjoseph | 32000 |
| 16:51.39 | gtjoseph | ok, i get it now |
| 16:51.56 | gtjoseph | you changed third-party/pjproject/patches/config_site.h? |
| 16:52.12 | tm1000 | gtjoseph: nice! we went to 16000, so 32 is even better |
| 16:52.16 | tm1000 | and yes we did :-( |
| 16:52.21 | gtjoseph | ok, that mnakes sensenow |
| 16:52.22 | tm1000 | didnt know dpma would be so bitchy about it |
| 16:52.41 | gtjoseph | well, unfortunately, that's a hard-code in pjproject |
| 16:52.48 | gtjoseph | not much dpma could have done about it |
| 16:53.32 | tm1000 | so basically you guys increased the size internally and now you are having dpma issues. So basically the next release of Asterisk will also have dpma fixes for this |
| 16:53.35 | tm1000 | gtjoseph: ? |
| 16:53.44 | gtjoseph | yes |
| 16:53.47 | gtjoseph | looking at it now |
| 16:55.25 | tm1000 | Well im going to go remove the patch unless you know of a better way but you and file are the smartest kids in the asterisk block so its probably my only choice and thats ok.. |
| 16:58.46 | tm1000 | gtjoseph: does dpma have to be licensed for this crash to occur? |
| 16:58.54 | tm1000 | or can it occur if loaded but not licensed |
| 16:58.56 | gtjoseph | iirc yes |
| 16:59.05 | gtjoseph | it happens when a phone tries to get its config |
| 17:00.17 | tm1000 | should I open an external issue or just keep it with you guys internally (i dont care either way... unless someone else has this same issue eventually?) |
| 17:00.44 | tm1000 | gtjoseph: the fix has to happen in dpma though right so even if you fix it right now I have to wait for the compiled object :-) |
| 17:00.52 | gtjoseph | correct |
| 17:01.05 | gtjoseph | and we have to make it work forst :) |
| 17:17.51 | rmudgett | s/forst/forrest/ :) |
| 17:20.08 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-araqbmutmakjxgyc) |
| 17:20.09 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:26.09 | tm1000 | ok I am going to ask a question you are going to hate whats the ETA on 13.18 and 14.7.... file gtjoseph |
| 17:26.25 | file | not for weeks? |
| 17:26.27 | gtjoseph | points to cresl1n |
| 17:26.45 | file | 3+ I'd personally say |
| 17:27.21 | tm1000 | <3 |
| 17:39.39 | jameswf | #blamematt |
| 17:55.53 | cresl1n | I see what you did there |
| 18:01.02 | tm1000 | jameswf: #whichmattho |
| 18:01.59 | jameswf | #bothmattsfault #blameanyonenamedmatt |
| 18:02.56 | jameswf | They are the reason we still have chan_sip and the dialplan..... take risks kill em both :) |
| 18:03.19 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |
| 18:03.21 | cresl1n | I'm gonna back slowly away from this discussion... |
| 18:03.29 | cresl1n | runs |
| 18:03.32 | jameswf | *chan_sip and the dialplan... don't kill the matts |
| 18:18.29 | cresl1n | jameswf: it's probably gonna be 3 or more weeks (as per file's estimate) |
| 18:29.24 | file | knows all |
| 18:42.48 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.162) |
| 18:47.46 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:47.46 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 19:27.57 | tm1000 | cresl1n: whats that you say? 3 more weeks until you deprecate the dialplan? or until you delete chan_sip? Can you clarify? |
| 19:29.43 | tm1000 | (also joking.... or... am I?????????) |
| 19:33.22 | rmudgett | Even with this new-fangled thing called ARI we cannot get rid of the dialplan. |
| 19:47.56 | cresl1n | tm1000: troublemaker :-P |
| 19:49.45 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:03.28 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 20:11.06 | jameswf | I am going to write ARI scripts to do everything you can do on your phone like weather, time etc but you have to dial a number on your pbx. |
| 20:14.13 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:14.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:23.31 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-103-115.dialup.adsl.anteldata.net.uy) |
| 20:50.57 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 22:41.39 | *** join/#asterisk-dev opticron_ (~opticron@75.76.59.35) |
| 22:41.39 | *** mode/#asterisk-dev [+o opticron_] by ChanServ |
| 22:42.42 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 22:42.42 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 22:45.13 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LFbn-1-5197-25.w90-105.abo.wanadoo.fr) |