| 00:22.21 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:22.21 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.14.0 (2017/02/13), 11.25.1 (2016/12/08), Standard: 14.3.0 (2017/02/13); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 00:34.33 | *** join/#asterisk nix8n82 (~AndChat58@2601:283:8302:2f0d:4c69:5d1e:acae:b67a) |
| 00:35.21 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 01:16.47 | *** join/#asterisk jathan (~jathan@201.99.106.102) |
| 01:21.45 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-xaimdnzsghuljaci) |
| 01:32.32 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 01:32.38 | *** join/#asterisk matrix1233 (~matrix123@41.230.26.59) |
| 01:33.19 | *** join/#asterisk scgm11 (~textual@r186-52-137-91.dialup.adsl.anteldata.net.uy) |
| 01:33.57 | scgm11 | anyone having issues with latest version of ast 13 app_queue with members getting calls even if they are in pause? |
| 01:36.08 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 01:43.11 | igcewieling | jfindley: my Dial line, in case it helps: Dial("SIP/nextone-000006cd", "SIP/igv0496/19733443100,360,gb(sm_pre_dial^s^1)U(sm_answer)F(stub_sm_intercept^s^1) |
| 01:43.21 | igcewieling | *sigh* |
| 01:43.44 | igcewieling | Dial(SIP/igv0496/1973344xxxx,360,gb(sm_pre_dial^s^1)U(sm_answer)F(stub_sm_intercept^s^1) |
| 01:43.47 | igcewieling | 8-| |
| 01:44.56 | igcewieling | [sm_answer] has an exten => s,1,Whatever |
| 01:45.12 | *** join/#asterisk Guest70 (~textual@r186-52-137-91.dialup.adsl.anteldata.net.uy) |
| 01:47.52 | *** join/#asterisk ganbold (~ganbold@173.244.215.173) |
| 01:56.43 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:b028:efff:f4f1:6b84) |
| 02:48.14 | *** join/#asterisk nix8n82 (~AndChat58@c-67-161-152-243.hsd1.co.comcast.net) |
| 03:06.36 | *** join/#asterisk Guest70 (~textual@r186-52-137-91.dialup.adsl.anteldata.net.uy) |
| 03:21.37 | *** join/#asterisk mulvane (~mulvane@freebsd/user/mulvane) |
| 03:23.52 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
| 04:12.13 | *** join/#asterisk Guest70 (~textual@186.52.137.91) |
| 04:24.39 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:26.26 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
| 05:56.40 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 05:57.06 | *** join/#asterisk thiagoc_ (~thiagoc@unaffiliated/thiagoc) |
| 05:58.26 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 06:19.01 | *** join/#asterisk jkroon (~jkroon@165.16.204.44) |
| 06:27.11 | *** join/#asterisk Y04NN (~y04nn@nayon.fr) |
| 06:32.37 | *** join/#asterisk ganbold (~ganbold@173.244.215.173) |
| 07:04.19 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 07:20.04 | *** join/#asterisk pchero_work (~pchero@2a00:c80:1072::379) |
| 07:37.34 | *** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 07:38.47 | *** join/#asterisk Y04NN (~y04nn@178.18.54.206) |
| 07:42.44 | *** join/#asterisk matrix1233 (~matrix123@41.230.26.59) |
| 08:00.16 | *** join/#asterisk sekil (~sekil@cable-89-216-227-230.dynamic.sbb.rs) |
| 08:02.39 | *** join/#asterisk skywayskase (~skywayska@c-24-16-157-129.hsd1.wa.comcast.net) |
| 08:15.06 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 08:28.37 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 08:52.14 | *** join/#asterisk matrix1233 (~matrix123@41.227.121.245) |
| 08:56.20 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
| 09:13.04 | *** join/#asterisk wasanzy (~wasanzy@41.242.137.170) |
| 09:18.30 | *** join/#asterisk Kaian (~kaian@6.62-99-78.static.clientes.euskaltel.es) |
| 09:26.12 | *** join/#asterisk matrix1233 (~matrix123@41.227.121.245) |
| 09:36.45 | *** join/#asterisk matrix1233 (~matrix123@41.227.121.245) |
| 09:46.19 | *** join/#asterisk matrix1233 (~matrix123@41.227.121.245) |
| 09:46.27 | *** join/#asterisk Yorch (~textual@88.red-83-61-9.staticip.rima-tde.net) |
| 09:46.31 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 09:47.07 | Yorch | hi there, hope anyone could give me a hand with monitoring asterisk on zabbix, right now i'm stuck in showing any sip information |
| 09:49.05 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 09:53.29 | Samael28 | Yorch: Hi! What kind of info you want to monitor? You can do it all with UserScripts |
| 09:54.12 | Yorch | well, i'm trying to integrate it on zabbix following this: https://github.com/alkali147/asterisk-zabbix |
| 09:55.33 | Yorch | but i have some troubles, for example with the "screen_app_asterisk_service.xml" file (i can't add as a template, and i don't know what to do with it... same with "userparams_app_asterisk_service.conf" |
| 09:57.34 | Samael28 | I'd read this all files carefully. Mainly cause of it's for 2.0 version |
| 09:57.49 | Samael28 | But you can make your own based on this scripts |
| 10:02.20 | Yorch | Samael28 not sure what do you mean |
| 10:02.31 | Yorch | to integrate it with zabbix you mean?? |
| 10:02.46 | Samael28 | Means I'm not sure you can blindly import files somewhere from internet ) |
| 10:02.46 | Yorch | any guide or link i can follow? |
| 10:03.21 | Yorch | well my point is to monitor asterisk on zabbix |
| 10:04.25 | Yorch | that's my objecitve, and i have googled and nothing clear except that |
| 10:07.31 | Samael28 | Quite clear scripts ) You can make your own template manually and put there as a data source results of these scripts |
| 10:13.54 | *** join/#asterisk matrix1233 (~matrix123@41.227.121.245) |
| 10:25.26 | *** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 10:31.23 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 10:34.02 | *** join/#asterisk wasanzy (~wasanzy@41.66.254.58) |
| 10:34.32 | wasanzy | sip log from my simbox. https://paste.linux.community/view/20993a62 |
| 10:34.40 | wasanzy | still call is not getting to asterisk |
| 10:40.57 | *** join/#asterisk phrearch (~spindle@34.tbb.spindle.osso.nl) |
| 10:41.01 | phrearch | hello |
| 10:42.29 | phrearch | i ran webrtc clients on asterisk 13 using chan_sip. which works great for audio. i only got one-way video though, so i figured that updating to asterisk 14 might solve that, but now i get 488/Not available sip returns again. it's probably some dtls/srtp issue, but i don't know how to debug this properly |
| 10:53.00 | phrearch | browser also indicates: called with SDP without ice-ufrag and ice-pwd. |
| 10:56.26 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 10:56.57 | wasanzy | phrearch: you may consider installing all dependencies |
| 10:59.06 | wasanzy | sh contrib/scripts/install_prereq install and see |
| 11:01.12 | phrearch | wasanzy: just reinstalled asterisk 13 again. webrtc call works again. what kind of dependencies? |
| 11:01.53 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 11:02.37 | wasanzy | before you run ./configure for version 14, run the two commands sh contrib/scripts/install_prereq install and sh contrib/scripts/install-unpackaged |
| 11:03.04 | wasanzy | then run the ./configure compile and install. |
| 11:03.19 | wasanzy | the command will install required packages |
| 11:03.44 | phrearch | ok thanks. will give that a try |
| 11:06.39 | *** join/#asterisk dexta_ (~D3XTA@host86-167-218-0.range86-167.btcentralplus.com) |
| 11:18.50 | phrearch | argh, pjproject fails to build, libpjmedia.so: undefined reference to `pjmedia_get_video_format_info' |
| 11:24.22 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 11:31.22 | *** join/#asterisk Guest70 (~textual@r186-49-65-146.dialup.adsl.anteldata.net.uy) |
| 11:41.45 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
| 11:42.49 | *** join/#asterisk chendy (~alexc@183.14.30.135) |
| 11:47.00 | *** join/#asterisk Y04NN (~y04nn@178.18.54.206) |
| 11:48.27 | *** join/#asterisk Y04NN_ (~y04nn@178.18.54.206) |
| 12:05.26 | *** join/#asterisk Rasputin3711 (~Rasputin3@87.255.254.66) |
| 12:07.07 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 12:28.22 | *** join/#asterisk Guest70 (~textual@186.49.65.146) |
| 12:29.57 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 12:42.34 | *** join/#asterisk newtonr (~newtonr@173-17-133-211.client.mchsi.com) |
| 12:42.34 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 12:48.32 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 12:48.32 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 12:50.51 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:55.09 | *** join/#asterisk tuxian_ (~tuxian@194.12.3.78) |
| 13:00.19 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:00.37 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 13:03.11 | *** join/#asterisk tuxian (~tuxian@igilmour.plus.com) |
| 13:11.47 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-mbdztusxeubicobp) |
| 13:21.51 | *** join/#asterisk Guest70 (~textual@r186-49-65-146.dialup.adsl.anteldata.net.uy) |
| 13:21.52 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 13:22.53 | *** join/#asterisk StucKman (~mdione@195.200.189.206) |
| 13:26.21 | StucKman | I have weird logs and behaviour, where spies are launched without user intervention: http://linkode.org/LjwMlqE7KlQuNKFzw3qX03 (sorry the french). as you can see, there is a couple of spies lauched by the user ('> Launching ChanSpy(SIP/e2yvvx,bds) on SIP/t7f84x-0005b914') but a lot others not initiated by the user, and then the user can still hear the other users' conversations in his calls |
| 13:26.45 | *** join/#asterisk chendy (~alexc@183.14.30.135) |
| 13:28.46 | *** join/#asterisk stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 13:42.33 | *** join/#asterisk malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:42.33 | *** mode/#asterisk [+o malcolmd] by ChanServ |
| 13:46.43 | *** join/#asterisk canthus13 (~canthus13@shellium/member/canthus13) |
| 13:49.18 | *** join/#asterisk bounceman (~bounceman@185.32.9.250) |
| 13:50.38 | bounceman | Hi, what would be the most efficient way to disable early media, if possible? Sometimes we receive early media from upstream providers with 20 seconds long messages "blablabla" and then a 480 for an example. Is this setting solely upstream related or can I in my end say "I do not accept early media from you, just send me the god damn reason code"? |
| 13:53.09 | Samot | A playback of a recorded message like "The call cannot be completed as dialed" is not early media. |
| 13:53.28 | bounceman | For clarity, I want the 480 sent directly in my face without long messages. |
| 13:53.43 | Samot | What exactly happens? |
| 13:53.51 | bounceman | Maybe it is not defined as early media, it is sent as RTP after the Session in Progress |
| 13:53.53 | Samot | And don't "yadda yadda yadda" the message. |
| 13:54.00 | Samot | What are you exactly getting back? |
| 13:57.28 | bounceman | Samot: directly after the TRYING from the upstream it also starts sending RTP packages basically. It's before the session in progress even |
| 13:57.53 | Samot | Show a call with a full sip debug |
| 13:58.00 | bounceman | Once the RTP stream is sent, approx 1000 packages, it sends a 480 |
| 14:00.22 | bounceman | I dont think that will answer my question, I asked if I can turn this off in the asterisk |
| 14:00.29 | *** join/#asterisk igcewieling (~ewieling@ip98-170-215-112.pn.at.cox.net) |
| 14:00.34 | Samot | I don't know. |
| 14:00.39 | Samot | Are they sending back a 183? |
| 14:01.15 | Samot | Session in Progress? |
| 14:02.51 | *** join/#asterisk putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:02.51 | *** mode/#asterisk [+o putnopvut] by ChanServ |
| 14:03.15 | bounceman | Yeah, my pcap fouled me. Yes, it starts with a Session in progress then bombs away the RTP/Message |
| 14:03.22 | bounceman | for 20 seconds, then comes the 480 |
| 14:05.46 | bounceman | The Session in progress from providers 183 contain SDP as well |
| 14:05.55 | bounceman | My fingers are drunk |
| 14:07.03 | Samot | Right, a 183 Session in Progress should return SDP |
| 14:07.14 | Samot | That's early media. |
| 14:07.27 | Samot | So you're sending a call to the provider.. |
| 14:07.40 | Samot | The provider is sending back 100, probably a 180 and then a 183 |
| 14:07.47 | Samot | Followed by the recording and a 480 |
| 14:08.53 | bounceman | Pretty much yeah, and it is a waste of resources to sit waiting for 20 seconds before handling a 480, if you ask me |
| 14:09.18 | Samot | So a 480 is Temporary Unavailable... |
| 14:09.35 | Samot | Which means the callee is not available for some reason. |
| 14:09.55 | bounceman | Well it does the same for 404s as well |
| 14:09.58 | bounceman | the message is just different |
| 14:10.03 | Samot | OK |
| 14:10.06 | Samot | 404 Not Found |
| 14:10.08 | bounceman | "The number you have dialed is not in use" |
| 14:10.16 | Samot | So far these are client based errors. |
| 14:10.32 | bounceman | Oh we had operators sending early media on 5XX as well. |
| 14:10.36 | bounceman | So it does happen |
| 14:10.43 | Samot | 5XX is a server level error |
| 14:10.49 | bounceman | Yes |
| 14:10.49 | Samot | They are different. |
| 14:13.11 | Samot | Early media is basically your upstream sending back media while trying to setup the call... |
| 14:13.47 | Samot | Error recordings like that are just part of it. 5XX generally means your _provider_ is stopping the call... |
| 14:14.06 | bounceman | Yeah I get that for dial tones. But in case of 404, 480 etc just send me the code and let me inform my customers what have happened |
| 14:14.12 | Samot | 4XX means that the call was stopped at the "user" level. Generally from the other provider about the state of the user. |
| 14:14.30 | Samot | You can ask them not to do that |
| 14:14.43 | StucKman | with the protocol? |
| 14:14.44 | Samot | Or you might need a sip proxy between the two of you. |
| 14:15.11 | Samot | So you can handle their replies and do what you want before they get to Asterisk. |
| 14:15.51 | StucKman | Samot: I think what bounceman wants is a way to tell th other end not to send these audios because there's noone listening and please send the error code immediately |
| 14:16.10 | Samot | What is said was "I don't want the message, I just want the 480" |
| 14:16.24 | Samot | He has no control over the message. |
| 14:16.32 | Samot | Or what his provider is sending to him. |
| 14:16.44 | Samot | He can ask his provider NOT to send early media. |
| 14:16.48 | StucKman | ok, so there's no header to say such a thing |
| 14:16.50 | Samot | 100, 180, 480. |
| 14:16.53 | Samot | Boom, done. |
| 14:17.04 | Samot | I didn't say there was. |
| 14:17.14 | Samot | I said he needed to ask his provider to NOT send early media. |
| 14:17.19 | Samot | If they say no, we can't.. |
| 14:17.31 | bounceman | I have asked them, I am waiting for reply. If I can just send a header that would be great |
| 14:17.35 | Samot | He will most likely need a SIP router/proxy in between... |
| 14:17.55 | bounceman | we already have kamailio's on our front end towards the upstreams |
| 14:17.57 | Samot | so he can look at the messages and handle them how he wants before it gets to Asterisk... |
| 14:18.06 | Samot | Then that's where you would deal with this. |
| 14:18.26 | StucKman | Samot: that would filter/fix the message part, but not waiting the 20s while the message is sent? |
| 14:18.59 | Samot | I get that.. |
| 14:19.11 | Samot | However... |
| 14:19.18 | Samot | There can be ways to handle that. |
| 14:19.38 | *** join/#asterisk Guest70 (~textual@r186-50-210-40.dialup.adsl.anteldata.net.uy) |
| 14:21.05 | StucKman | reasking after 1h: I have weird logs and behaviour, where spies are launched without user intervention: http://linkode.org/LjwMlqE7KlQuNKFzw3qX03 (sorry the french). as you can see, there is a couple of spies lauched by the user ('> Launching ChanSpy(SIP/e2yvvx,bds) on SIP/t7f84x-0005b914') but a lot others not initiated by the user, and then the user can still hear the other users' conversations in |
| 14:21.11 | StucKman | his calls |
| 14:23.23 | Samot | These mean nothing. |
| 14:23.36 | Samot | Show an actual call with this happening... |
| 14:24.30 | StucKman | Samot: hmm, ok |
| 14:24.42 | Guest70 | anyone having issues with latest version of ast 13 app_queue with members getting calls even if they are in pause? |
| 14:25.24 | bounceman | scgm11: been around for far longer then asterisk 13 |
| 14:25.32 | bounceman | Digium seems unable to fix it |
| 14:26.06 | bounceman | We have seen it in asterisk 11 in high load sites |
| 14:26.09 | scgm11 | I have one that works fine but not with the latest changes |
| 14:26.15 | *** join/#asterisk kharwell (kharwell@nat/digium/x-baidwnclwgovlscg) |
| 14:26.15 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:26.17 | scgm11 | this is not high loead |
| 14:26.24 | scgm11 | load |
| 14:26.32 | bounceman | Then perhaps it is different scenarios |
| 14:26.48 | bounceman | Have you managed to catch the agent queue status when this has happened? |
| 14:27.08 | bounceman | Are you using Asterisk Realtime? |
| 14:27.23 | scgm11 | not, I havent been able to reproduce out of production |
| 14:27.35 | scgm11 | I m using realtime now but tested also using from files |
| 14:27.38 | StucKman | Samot: that's the most weird hing, I get those kind of lines even without a call in progress |
| 14:27.56 | bounceman | scgm11: so it is rare occurance? |
| 14:28.26 | scgm11 | if you have just a bit of load happens, but I mean not more than 10 callers waiting |
| 14:28.39 | Samot | StucKman: I don't know what that means. |
| 14:28.41 | scgm11 | the issue is that I had to downgrade |
| 14:28.48 | Samot | StucKman: Clarify. |
| 14:29.24 | scgm11 | because was impossible to work that way |
| 14:29.32 | scgm11 | Im monitoring now |
| 14:29.42 | scgm11 | so now I have realtime with a previous version |
| 14:29.47 | bounceman | scgm11: are you using an after call feature? |
| 14:30.13 | scgm11 | I have some custom code on app_queue that is merged on master but I have it also on 13 |
| 14:30.59 | scgm11 | just an h exten |
| 14:31.21 | scgm11 | I havent filled and issue because Im trying to reproduce on a test environment |
| 14:33.35 | bounceman | Well you cant do shit I believe without a proper debug file |
| 14:34.36 | scgm11 | yes I will try to reproduce and fill an issue |
| 14:34.43 | StucKman | Samot: those lines, Spying/Attaching/Done Spying, I get these even when the user is not using the system |
| 14:35.34 | Samot | StucKMan: Show a call where this is happening so we can see what is going on outside of those ChanSpy lines.. |
| 14:35.48 | Samot | You're just show results, you're not showing how the call got to those results. |
| 14:39.53 | bounceman | So my upstream said no, they will not remove early media. |
| 14:41.34 | Samot | Who is your upstream? Are they a LEC or an ITSP? |
| 14:41.48 | StucKman | Samot: parsing the lines |
| 14:42.41 | bounceman | Both Id say |
| 14:43.45 | Samot | LECs do things more old school. |
| 14:44.13 | Samot | Try to keep it in a way their digital circuits handle the call.. |
| 14:44.24 | Samot | Pure ITSP's will do things differently. |
| 14:44.43 | bounceman | well I am going to force them to fix this. |
| 14:44.56 | Samot | Good luck. |
| 14:45.02 | Samot | You will be considered an ICB. |
| 14:45.12 | bounceman | My scenario is that we have huuuuuge automatic dialer corps. You can imagine the waste if a 404 generates a 20 second audio playback |
| 14:45.16 | Samot | And be approached as such, most likely. |
| 14:45.31 | Samot | Then they probably aren't the carrier for you. |
| 14:45.45 | Samot | I have an alerts provider that does this. |
| 14:46.22 | bounceman | They are cheap because they are large, and their services are gold when it comes to stability and uptime. |
| 14:46.38 | Samot | Being large has nothing to do with cheap. |
| 14:47.05 | wasanzy | still getting check_auth: username mismatch, have <dwg>, digest has <zenith> |
| 14:47.09 | bounceman | Larger volumes usually indicate lower interconnect prices, atleast in this area |
| 14:47.42 | Samot | Having low interconnect pricing does not equal your end users have low pricing. |
| 14:47.59 | Samot | It all depends on what they consider a good profit margin. |
| 14:48.02 | wasanzy | log from simbox https://paste.linux.community/view/a057651a |
| 14:48.22 | Samot | I worked in a LEC |
| 14:48.34 | Samot | We charged $0.02/minute for outbound.. |
| 14:48.41 | Samot | That was a 60 point margin. |
| 14:48.45 | wasanzy | zenith/zenith 192.168.10.91 D No No 5060 OK (8 ms) |
| 14:48.54 | Samot | After costs. |
| 14:49.05 | wasanzy | I don't know why sip show peers is showing zenith/zenith |
| 14:49.10 | bounceman | Samot: that is expensive though |
| 14:49.23 | Samot | Why? Because margins had to be between 60 to 75 points. |
| 14:49.27 | Samot | Right. |
| 14:49.37 | Samot | That was 3 years ago. |
| 14:49.39 | bounceman | Most of our customers wouldn't accept 0.02 per minute. |
| 14:49.40 | Samot | My point.. |
| 14:49.48 | Samot | It didn't cost us that |
| 14:49.58 | *** join/#asterisk chendy (~alexc@183.14.30.135) |
| 14:49.59 | Samot | It was most like $0.0035 |
| 14:50.11 | Samot | However, business costs are added.. |
| 14:50.28 | bounceman | But 0.02$ was your cost for the customer? |
| 14:50.29 | Samot | Profit margins are added... |
| 14:50.32 | Samot | Yes. |
| 14:50.36 | Samot | Because we were a LEC |
| 14:50.46 | Samot | And that was standard pricing for LEC's in Michigan |
| 14:50.51 | Samot | In some cases it was better. |
| 14:51.03 | Samot | If the client had high volume, we would drop the price. |
| 14:51.08 | Samot | But there was a line. |
| 14:51.15 | Samot | you cannot drop below X on pricing.. |
| 14:51.24 | Samot | Or it destroys profit margins. |
| 14:51.34 | Samot | The margins _they_ wanted |
| 14:51.36 | bounceman | I think we do 0.0098$ or something towards our customers, we have an overall 90% profit margin anyway, except for some customers we had to push down the price at |
| 14:51.55 | Samot | Well it depends on how you handle your margin factors. |
| 14:52.09 | Samot | They accounted for a wide variety of things in their models. |
| 14:52.17 | Samot | My point is simple... |
| 14:52.37 | Samot | Just because I pay $0.0035/min doesn't mean I'm not going to charge what is considered "standard" |
| 14:55.04 | bounceman | Well, it is all about prices. We cannot just switch operators here and there. The price has to be right. |
| 14:55.22 | Samot | Well, you are providing services to other end users.. |
| 14:55.35 | Samot | Your upstream is interjecting media into your calls.. |
| 14:55.42 | Samot | That you don't want your end users to hear. |
| 14:56.20 | Samot | Some LEC's aren't designed to handle "wholesalers" |
| 14:58.13 | StucKman | Samot: with or without the dial plan? |
| 14:59.39 | Samot | asterisk -rvvvvvvv |
| 14:59.44 | Samot | sip set debug on |
| 14:59.50 | Samot | OR pjsip set logger on |
| 14:59.54 | Samot | depending on your tech |
| 15:01.22 | StucKman | it's almost 500 lines long |
| 15:02.39 | StucKman | the spy lines are around line 366: https://paste.debian.net/924959/ |
| 15:03.17 | StucKman | even a beep is played to the user |
| 15:05.07 | Samot | How is ChanSpy being called on? |
| 15:05.14 | Samot | In one of these many AGI scripts? |
| 15:05.27 | StucKman | Samot: I have no idea, that's what I'm asking |
| 15:05.29 | Samot | I don't see any feature codes being used to enable or disable ChanSpy... |
| 15:05.42 | StucKman | Samot: neither do I |
| 15:05.52 | Samot | ChanSpy just doesn't happen. |
| 15:05.56 | Samot | You have to tell it to happen. |
| 15:06.00 | Samot | In the dialplan.. |
| 15:06.17 | StucKman | Samot: I'm pretty sure we're not |
| 15:06.32 | Samot | You need to look at your dialplan and your code.. |
| 15:06.35 | StucKman | this started happening for only one user in 160 two days ago |
| 15:06.42 | Samot | Users can't just turn on ChanSpy.. |
| 15:07.09 | Samot | ChanSpy needs to know what channel to spy on.. |
| 15:07.15 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 15:07.15 | StucKman | the py is normally initiated with another server that controls the asterisk (we're using a formerly open solution called XiVO) |
| 15:07.37 | StucKman | Samot: theres are lines the user Spyed on days ago |
| 15:07.44 | *** join/#asterisk netman (~netman@185.94.249.77) |
| 15:07.44 | Samot | OK |
| 15:08.05 | StucKman | it's like something remembers that and keeps openeing and closing them, at it's own will |
| 15:08.07 | Samot | How do they DO IT? |
| 15:08.15 | StucKman | even when the user is not using the system |
| 15:08.27 | Samot | How did they activate ChanSpy?! |
| 15:09.02 | StucKman | Samot: I don't really know, I can't get to the code now, they renamed the company and removed everything from github |
| 15:09.16 | Samot | What? |
| 15:09.29 | Samot | You have the code. |
| 15:09.34 | Samot | Internally don't you? |
| 15:09.37 | StucKman | the dial plan? yes |
| 15:09.51 | StucKman | the other server's code? nope |
| 15:09.58 | Samot | What other server? |
| 15:10.06 | Samot | There's a third party server involved in this? |
| 15:10.09 | StucKman | (they put a whole solution besides asterisk to handle call centers) |
| 15:10.14 | Samot | That controls/interjects into the call? |
| 15:10.15 | StucKman | yeap |
| 15:10.19 | Samot | OK |
| 15:10.23 | Samot | Then you need to look there. |
| 15:10.27 | StucKman | controls some pasects of the asterisk |
| 15:10.34 | StucKman | aspects* |
| 15:10.34 | Samot | Like ChanSpy?! |
| 15:10.42 | StucKman | yes |
| 15:10.43 | StucKman | but |
| 15:10.46 | Samot | But? |
| 15:10.56 | Samot | So you have a third party application controlling Asterisk.. |
| 15:11.01 | StucKman | when the user initiates the Spy, I get these lines: |
| 15:11.08 | StucKman | [Mar 29 14:53:20] VERBOSE[31373] pbx.c: [Mar 29 14:53:20] > Launching ChanSpy(SIP/2slkl1,bds) on SIP/t7f84x-0005b921 |
| 15:11.09 | Samot | That keeps trying to ChanSpy agents that were set days ago... |
| 15:11.11 | StucKman | [Mar 29 14:53:22] VERBOSE[31373] app_chanspy.c: [Mar 29 14:53:22] == Spying on channel SIP/2slkl1-0005b0c9 |
| 15:11.14 | StucKman | [Mar 29 14:53:22] NOTICE[31373] app_chanspy.c: Attaching SIP/t7f84x-0005b921 to SIP/2slkl1-0005b90c |
| 15:11.19 | Samot | HOW? |
| 15:11.22 | StucKman | [when not, only the last two, at random |
| 15:11.23 | Samot | HOW DOES THE USER DO IT? |
| 15:11.42 | StucKman | well, it interacts with the third party server |
| 15:11.46 | igcewieling | Samot: they press buttons, of course! |
| 15:11.48 | Samot | Someone had to tell this user how to use ChanSpy... |
| 15:11.55 | StucKman | it has a web frontend, yadda yadda |
| 15:11.58 | Samot | WTF do they do to activate it? |
| 15:12.02 | Samot | Oh FFS. |
| 15:12.11 | StucKman | Samot: it's the functionality |
| 15:12.12 | Samot | So you have a third party application doing shit to your calls. |
| 15:12.18 | Samot | That you can't access. |
| 15:12.23 | Samot | You don't understand what they are doing.. |
| 15:12.54 | Samot | And apparently was bought by someone else and the code you use has been removed from the public.. |
| 15:13.01 | StucKman | no, wait |
| 15:13.01 | Samot | You need to talk to them |
| 15:13.08 | Samot | Find out what they are doing with these calls.. |
| 15:13.22 | StucKman | wait a second, don go ballistic |
| 15:13.43 | StucKman | the call center solution allows supervisors to spy on agents, that's fine for us |
| 15:13.51 | igcewieling | It's like a slow car accident, I just can't look away and I can't watch. |
| 15:13.57 | StucKman | that works as spected |
| 15:14.01 | Samot | Except.. |
| 15:14.17 | Samot | You are getting ChanSpys on agents that the sups spied on DAYS AGO |
| 15:14.33 | Samot | Which means that third party app is still trying to do SHIT |
| 15:14.44 | Samot | It may not have cleared itself.. |
| 15:14.51 | StucKman | Samot: well, it's weird that the logs are different |
| 15:14.55 | Samot | Or it could have those agents on a permanent ChanSpy. |
| 15:15.05 | Samot | The Channel IDs will always be different. |
| 15:15.16 | StucKman | Samot: not relly permanent, they come and go for second at a time |
| 15:15.24 | Samot | OK |
| 15:15.26 | Samot | Listen.. |
| 15:15.32 | StucKman | the channel yes, but not the users |
| 15:15.35 | Samot | You have another application that does shit to your Asterisk box.. |
| 15:15.41 | Samot | ChanSpy spies on the AGENTS |
| 15:15.53 | StucKman | Samot: yes |
| 15:15.58 | StucKman | to both |
| 15:15.59 | Samot | So it can find the CHANNEL they are on. |
| 15:16.14 | StucKman | well, I gess spy does that, yes |
| 15:16.31 | Samot | If your third party app somehow has Agent 105 on permanent spy.... |
| 15:16.41 | Samot | Each time 105 has a call, it will be SPIED on. |
| 15:17.00 | StucKman | yes, but it's not a permanent spy |
| 15:17.05 | Samot | Do you know that? |
| 15:17.12 | Samot | Do you know what the third party app is actually doing?! |
| 15:17.17 | StucKman | see the first logs I sent, they last seconds, |
| 15:17.33 | Samot | OK, I'm done. |
| 15:17.41 | Samot | You're completely missing the point. |
| 15:18.03 | StucKman | well, I'm no master of asterisk, explain to me |
| 15:18.14 | Samot | This has nothing to do with Asterisk at this point. |
| 15:18.29 | Samot | This has to do with the fact a THIRD PARTY has control OVER YOUR CALLS |
| 15:18.34 | StucKman | Samot: that's what I'm trying to figure out |
| 15:18.52 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
| 15:18.57 | Samot | A third part that you can't get access into to see HOW they are controlling your alls. |
| 15:19.03 | Samot | You can't look at what they are doing.. |
| 15:19.16 | Samot | Therefore, WE can't know what they are doing. |
| 15:19.25 | StucKman | Samot: not even from the logs? |
| 15:19.40 | Samot | This is a third party app that allows your supervisors to spy on agents. |
| 15:19.59 | Samot | You have an issue with agents being spied on when they aren't actually being spied on.. |
| 15:20.04 | Samot | But they were spied on days ago.. |
| 15:20.13 | Samot | DID THE APP CLEAR THAT SHIT OUT? |
| 15:20.14 | StucKman | in the logs I see Sup A entering and exiting Spy mode on agents X, Y, Z, at random |
| 15:20.35 | Samot | Go talk to the people you have doing shit to your calls. |
| 15:20.37 | igcewieling | StucKman: you won't find more than that on the Asterisk logs. |
| 15:21.12 | StucKman | igcewieling: except the fact that user initiated spyings have some logs and the random ones have another |
| 15:21.33 | igcewieling | StucKman: you don't have user initiatated spying. |
| 15:21.47 | StucKman | I mean, those that the sup are requesting |
| 15:21.54 | StucKman | it says this: > Launching ChanSpy(SIP/2slkl1,bds) on SIP/t7f84x-0005b921 |
| 15:22.02 | StucKman | the random ones don't have that line |
| 15:22.09 | igcewieling | StucKman: Notice it doesn't say WHO launched it. |
| 15:22.31 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-myiqixsarzkjfbzm) |
| 15:22.31 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:22.31 | [TK]D-Fender | AMI <- |
| 15:22.31 | StucKman | well, t7f84x is the supervisor |
| 15:22.34 | [TK]D-Fender | there is no "who" |
| 15:22.51 | StucKman | and I'm right besides hiom when he does that |
| 15:22.57 | igcewieling | I'll let [TK]D-Fender and Samot fight it out. |
| 15:23.09 | igcewieling | good luck. |
| 15:23.27 | Samot | Naw, I'm done. |
| 15:23.35 | Samot | I waited over 40 minutes for a debug |
| 15:23.35 | StucKman | what I'm asking is: why do I get different log lines? |
| 15:23.50 | Samot | Then we find out there's some third party app being used. |
| 15:23.55 | StucKman | Samot: you mean those logs are not enough? |
| 15:24.04 | Samot | NO |
| 15:24.12 | StucKman | ok, but don't shout |
| 15:24.13 | Samot | We DO NOT KNOW what this APP is DOING |
| 15:24.24 | StucKman | calm down, go for a walk |
| 15:24.27 | Samot | I've said this multiple times. |
| 15:24.40 | StucKman | yes, I know, but I'm asking the questions I want answers to |
| 15:24.43 | Samot | You do not have full control of your calls. |
| 15:25.04 | Samot | Therefore, we cannot help troubleshoot this without knowing what is happening with your calls.. |
| 15:25.09 | Samot | From all sources.. |
| 15:25.15 | StucKman | if you say: no, that doesn't make a difference, I will believe you and wait for the provider's answer |
| 15:25.41 | Samot | What provider? |
| 15:25.42 | StucKman | I'm just trying to gain some time |
| 15:25.48 | StucKman | Samot: the thir party |
| 15:25.59 | *** part/#asterisk igcewieling (~ewieling@ip98-170-215-112.pn.at.cox.net) |
| 15:26.04 | StucKman | (sorry, translating from french here) |
| 15:26.23 | StucKman | (and spanish) |
| 15:28.31 | StucKman | 17:22 < igcewieling> StucKman: Notice it doesn't say WHO launched it. |
| 15:28.39 | StucKman | beh, he left |
| 15:28.41 | [TK]D-Fender | AMI <- |
| 15:28.46 | StucKman | what does he mean with that? |
| 15:29.01 | [TK]D-Fender | He's expecting a FEATURE CODE to have been dialed from the channel itself |
| 15:29.04 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 15:29.14 | StucKman | like *98 ? |
| 15:29.17 | [TK]D-Fender | yes |
| 15:29.20 | StucKman | aha |
| 15:29.33 | Samot | But if they are using a web GUI to do this.. |
| 15:29.37 | [TK]D-Fender | You're web app uses AMI to trigger it |
| 15:29.43 | Samot | Then they are probably using AMI to trigger it |
| 15:29.56 | StucKman | sorry, but.. AMI? |
| 15:30.02 | [TK]D-Fender | s/probably/positively |
| 15:30.06 | Samot | Asterisk Manager Interface. |
| 15:30.13 | StucKman | ok |
| 15:30.38 | StucKman | ok, Ill try to debug this when the call center people go away |
| 15:30.43 | Samot | Which interjects to do things to the call. |
| 15:33.02 | Samot | So how does XiVO play into this again? |
| 15:36.13 | wasanzy | any help? |
| 15:37.20 | Samot | wasanzy: Show the attempts that aren't working right. |
| 15:46.00 | wasanzy | Samot: in an attempt to solve the problem, I added insecure=invite to two sip accounts. now the calls seems to be coming from only one sip account even though the a particular number I called shld have been trigerd from the other sip account |
| 15:48.33 | Samot | 11:37:23 AMÂ <Samot>Â wasanzy: Show the attempts that aren't working right. |
| 15:49.42 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 15:51.30 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 15:51.39 | wasanzy | https://paste.linux.community/view/d9742f14 |
| 15:52.07 | wasanzy | this call shouldn't have come from the peer dwg |
| 15:52.18 | wasanzy | that is why it is not finding the extension |
| 15:52.26 | *** join/#asterisk vince1 (~vince@ip72-202-187-29.ok.ok.cox.net) |
| 15:52.27 | Samot | [Mar 29 15:50:45] NOTICE[3409][C-00000010]: chan_sip.c:26321 handle_request_invite: Call from 'dwg' (192.168.10.91:5060) to extension 'start' rejected because extension not found in context 'from-PSTN'. |
| 15:52.51 | Samot | Or the fact you don't have anything in your dialplan context to handle that call.. |
| 15:53.24 | wasanzy | https://paste.linux.community/view/429a21c7 ---> sip conf |
| 15:53.25 | Samot | INVITE sip:start@192.168.10.39:5060 SIP/2.0 <--- That |
| 15:53.42 | Samot | Why you are you showing me the sip peer details |
| 15:53.50 | Samot | That has nothing to do with dialplan contexts. |
| 15:54.45 | wasanzy | Samot: there is two sip account. the zenith is supposed to handle that call. it has extension start defined for it under it's context. |
| 15:54.53 | Samot | INVITE sip:start@192.168.10.39:5060 SIP/2.0 <--- That |
| 15:54.58 | wasanzy | maybe am not explaining the problem ell |
| 15:55.02 | Samot | Why is your GSM gateway sending calls like that.. |
| 15:55.26 | Samot | The call is being accepted. |
| 15:55.31 | Samot | It has no dialplan to execute. |
| 15:55.47 | Samot | Or can't be found in the dialplan context that is being used. |
| 15:56.14 | Samot | dialplan show start |
| 15:56.21 | Samot | ^^ Show the output for that |
| 15:56.25 | Samot | er not that |
| 15:56.36 | wasanzy | Samot: the problem is not dialplan. as I said, the invite is auto choosing the sip account that is why |
| 15:56.38 | Samot | dialplan show from-PSTN |
| 15:57.19 | Samot | Do you have a trunk for each of them? |
| 15:57.21 | wasanzy | from-PSTN is a context with "s" extension. the call is not supposed to go there. |
| 15:58.15 | Samot | host=dynamic <-- What is this? |
| 15:58.17 | Samot | Why? |
| 15:58.30 | Samot | Why are your peers to your GSM gateway listed with a host=dynamic? |
| 15:58.31 | wasanzy | this is causing the call to go to the wrong context insecure=invite |
| 15:58.46 | Samot | Are you registering the GSM gateway TO asterisk? |
| 15:59.20 | Samot | Are these phones or trunk peers to the GSM gateway? |
| 16:01.04 | Samot | So far what you have shown from your sip.conf looks like two peers that are expecting devices to register TO Asterisk.. |
| 16:03.01 | [TK]D-Fender | <wasanzy> this is causing the call to go to the wrong context insecure=invite <- of course it is. It doesn't even bother to check the auth |
| 16:03.48 | wasanzy | Samot: I think that should not be there. |
| 16:03.50 | Samot | I'm more concerned with this: host=dynamic <-- For peers for the GSM gateway.. |
| 16:04.08 | Samot | Which is basically saying "I don't know what the IP of the GSM gateway is" |
| 16:04.24 | Samot | These looks like device peers not trunk peers. |
| 16:05.28 | Samot | wasanzy: Is this where you are trying to have a peer for each GSM port? |
| 16:05.41 | *** join/#asterisk Guest70 (~textual@r186-50-210-40.dialup.adsl.anteldata.net.uy) |
| 16:06.31 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:06.34 | wasanzy | Samot: I have changed the host to the right host pointing to the GSM gateway |
| 16:07.03 | wasanzy | Samot: yes I have two peers configured on the gsm gateway |
| 16:07.35 | wasanzy | should I use insecure=port instead? |
| 16:07.52 | Samot | That just doesn't look at the port. |
| 16:08.15 | Samot | That just means "Match peer on IP but don't match the port" |
| 16:08.36 | [TK]D-Fender | <wasanzy> should I use insecure=port instead? <-no, ***It doesn't even bother to check the auth*** |
| 16:09.14 | Samot | Your GSM gateway is sending calls from the same IP |
| 16:09.22 | Samot | No matter what GSM port the call comes from. |
| 16:10.03 | *** join/#asterisk cryptic (~cryptic@67-8-35-31.res.bhn.net) |
| 16:11.00 | Samot | insecure=port will match the peer by IP and still want auth |
| 16:11.05 | Samot | But ignore the port |
| 16:11.12 | Samot | insecure=invite will not auth invites. |
| 16:11.27 | Samot | insecure=port,invite will match by IP, ignore the port and not auth. |
| 16:12.14 | wasanzy | I took out the insecure now I am getting this again: https://paste.linux.community/view/022db5b5 |
| 16:12.26 | wasanzy | that was the problem I tried solving when I put insecure |
| 16:13.27 | Samot | Contact: <sip:zenith@192.168.10.91> |
| 16:13.47 | Samot | Found peer 'dwg' for '0278145292' from 192.168.10.91:5060 |
| 16:13.56 | Samot | I will say this again... |
| 16:14.11 | Samot | You are sending calls from the GSM gateway from the same IP and port. |
| 16:14.25 | Samot | dwg is MATCHING the IP and PORT |
| 16:14.36 | Samot | So it's going to challenge the INVITE |
| 16:14.37 | wasanzy | should I use random port instead? |
| 16:15.15 | Samot | Why do you need different trunks for each GSM port? |
| 16:15.41 | wasanzy | the gateway doesn't have a way to configure more than one IPs but can make use of random port |
| 16:16.08 | Samot | Why do you need multiple peers to the gateway? |
| 16:17.24 | wasanzy | Samot: I need multiple peers because the gateway has 8 sim cards, now I want to be able to send calls from two of the numbers to a specific context |
| 16:17.49 | Samot | Uhm.. |
| 16:17.59 | wasanzy | the rest 6 numbers to the default... |
| 16:18.00 | Samot | Why don't you just jump them to another context in the dialplan |
| 16:18.15 | Samot | Oh hey, NXXNXXXXXX is a number I want to go to X |
| 16:18.29 | Samot | I guess if there's a match I'll do a GoTo statement |
| 16:18.42 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:18.42 | *** join/#asterisk craigify (~craigify@162.216.46.76) |
| 16:18.52 | wasanzy | Samot: I asked about that here but it seems there was no way |
| 16:18.59 | Samot | The rest of the numbers can execute the context normally. |
| 16:19.01 | Samot | Yes. |
| 16:19.02 | Samot | Yes there is |
| 16:19.22 | Samot | [Mar 29 15:50:45] NOTICE[3409][C-00000010]: chan_sip.c:26321 handle_request_invite: Call from 'dwg' (192.168.10.91:5060) to extension 'start' rejected because extension not found in context 'from-PSTN'. |
| 16:19.28 | Samot | First off, you're NOT sending a DID |
| 16:19.38 | Samot | You're sending "start" |
| 16:19.49 | Samot | So in from-PSTN |
| 16:19.59 | Samot | start => 1,n,GoTo(place) |
| 16:20.14 | Samot | So first, you need to send a proper DID |
| 16:20.21 | Samot | From the gateway to Asterisk |
| 16:20.27 | Samot | Then you can match that DID |
| 16:20.30 | Samot | And go to town. |
| 16:20.45 | Samot | Basics. |
| 16:20.58 | wasanzy | Samot: how do I send that DID? |
| 16:20.59 | Samot | The way you explained it last time.. |
| 16:21.06 | Samot | Look at your gateway |
| 16:21.30 | Samot | But you're last explaination of this made it sound like you wanted to handle all the trunks differently. |
| 16:21.46 | Samot | s/explaination/explanation/ |
| 16:22.00 | Samot | You don't. You want to handle two DIDs differently. |
| 16:22.04 | Samot | Match them, handle them. |
| 16:22.10 | wasanzy | To VOIP Hotline : start |
| 16:22.27 | Samot | I can't help configure your GSM gateway |
| 16:22.58 | wasanzy | am a little confused |
| 16:23.07 | Samot | OK |
| 16:23.11 | Samot | I have a carrier.. |
| 16:23.16 | Samot | They send me calls.. |
| 16:23.25 | Samot | I don't need a trunk for each DID |
| 16:23.35 | Samot | I have a trunk for each GATEWAY |
| 16:23.42 | Samot | I send those calls to a context.. |
| 16:23.47 | Samot | That context MATCHES the DIDs |
| 16:24.04 | Samot | I tell it what to do from there.. |
| 16:24.34 | Samot | I don't care if 13135551212 comes from Gateway 1 or Gateway 2 |
| 16:24.46 | Samot | I have a peer for both that send all calls to the same context. |
| 16:25.02 | Samot | In that context, I match 13135551212 and deal with it. |
| 16:25.43 | wasanzy | right I get the point. let me just send you a correct call log. |
| 16:25.50 | wasanzy | with the right DID |
| 16:26.30 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
| 16:27.24 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 16:32.48 | *** join/#asterisk saltsa (~joonas@dsl-hkibrasgw1-58c018-65.dhcp.inet.fi) |
| 16:35.20 | wasanzy | this is a call. I want to send this call to a different context using GoTo https://paste.linux.community/view/d690bf07 |
| 16:35.48 | Samot | INVITE sip:s@192.168.10.39:5060 SIP/2.0 <--- really? |
| 16:37.06 | Samot | To: <sip:s@192.168.10.39:5060> <-- not going to work |
| 16:37.14 | Samot | You are not even sending the DID |
| 16:37.44 | wasanzy | hmm, wondering if the gateway has DID configuration |
| 16:37.54 | Samot | It's your gateway |
| 16:38.08 | Samot | Something that probably should have been looked at before buying it. |
| 16:38.34 | wasanzy | Samot: I didn't buy it actually. was bought by my boss |
| 16:38.45 | Samot | Doesn't matter who bought it |
| 16:38.52 | Samot | If it doesn't do what you need... |
| 16:39.30 | Samot | If the person who bought it didn't know what was needed, then how could they make an informed purchase? |
| 16:40.21 | *** join/#asterisk zaf (~zaf@104.254.192.70) |
| 16:40.29 | wasanzy | well I have another idea. I will define separate extension and act on that |
| 16:40.54 | Samot | So basically you're going to treat the GSM port like a device. |
| 16:41.13 | wasanzy | Samot: yes |
| 16:41.26 | Samot | That's not really the right way to do it.. |
| 16:41.59 | wasanzy | but since there is no other option |
| 16:43.19 | Samot | you could go read the gateway documents |
| 16:43.25 | Samot | Actually see what you can do with it |
| 16:43.44 | Samot | "No other options" at this point sounds like "I don't want to learn my gateway" |
| 16:45.20 | wasanzy | well they seem to have DID: https://paste.linux.community/view/43db86cf |
| 16:45.58 | Samot | I guess. |
| 16:46.04 | Samot | I don't know. |
| 16:47.21 | wasanzy | hmm I did what they mentioned int the doc. they put "s" as the "To VOIP Hotline" |
| 16:48.18 | Samot | I don't know what a "VoIP Hotline" is in regards to this gateway. |
| 16:48.25 | Samot | It's a pointless term. |
| 16:51.40 | *** join/#asterisk libardi (~libardi@187.64.228.189) |
| 17:06.13 | *** join/#asterisk Y04NN (~y04nn@2a01:e34:ef37:5870:f15b:7ba5:b01c:6528) |
| 17:16.12 | *** join/#asterisk jameswf (uid27319@gateway/web/irccloud.com/x-mgxvxjodzmckfdaq) |
| 17:23.01 | *** join/#asterisk miralin (~Thunderbi@194.8.128.54) |
| 17:24.48 | *** join/#asterisk sekil (~sekil@cable-89-216-227-230.dynamic.sbb.rs) |
| 17:30.21 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 17:40.18 | *** join/#asterisk fblackburn (~fblackbur@qubcpq0957w-lp130-02-70-53-160-248.dsl.bell.ca) |
| 17:42.46 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 17:43.19 | *** part/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 17:43.21 | *** join/#asterisk miralin1 (~Thunderbi@194.8.128.121) |
| 17:45.03 | *** join/#asterisk phrearch (~spindle@5ED432EC.cm-7-5a.dynamic.ziggo.nl) |
| 17:45.53 | phrearch | ok, that 488 Not accepted here issue was resolved by rebuilding the dependencies. Thanks wasanzy! |
| 17:45.58 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
| 17:55.17 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 17:55.59 | phrearch | isnt vp8 just passed through to the peer without modification? sip show channels show (ulaw|vp8) formats and chrome://webrtc-internals shows that data is flowing on the video channel, but it's not outputting any video at all |
| 17:58.38 | *** join/#asterisk Guest70 (~textual@r186-50-210-40.dialup.adsl.anteldata.net.uy) |
| 18:01.43 | phrearch | is there a difference for things like video support between chan_sip and chan_pjsip? |
| 18:03.42 | Samot | codecs are codecs. |
| 18:07.26 | Samot | Do both sides support video? |
| 18:14.38 | phrearch | Samot: yeah, they are the same Chromium browser actually |
| 18:16.03 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 18:16.27 | phrearch | tested on an android tablet and a browser. same issue. weird thing was that with asterisk 13 i had like one-way video working |
| 18:16.34 | phrearch | (using the same settings) |
| 18:22.36 | Samot | Show a call with a debug. |
| 18:22.43 | Samot | so we can see the SDP/media details. |
| 18:23.24 | *** join/#asterisk adeel (~adeel@fw1.ridgeway.scc-zip.net) |
| 18:29.36 | *** join/#asterisk igcewieling (~ewieling@ip98-170-215-112.pn.at.cox.net) |
| 18:35.09 | phrearch | http://paste.ubuntu.com/24276125/ |
| 18:53.46 | Samot | Oh, didn't even hang around. |
| 19:04.48 | Guest70 | anyone is having crashing on dtls rtp timeout? |
| 19:04.49 | Guest70 | <PROTECTED> |
| 19:04.53 | Guest70 | I have an issue filled |
| 19:05.04 | Guest70 | with backtrace full |
| 19:05.11 | Guest70 | with dont optimize and all |
| 19:05.33 | *** join/#asterisk miralin (~Thunderbi@194.8.128.121) |
| 19:05.54 | Guest70 | Im trying to track down the issue but if anyone can point to an idea where could this be crashing |
| 19:08.03 | Guest70 | this is chan_sip |
| 19:08.21 | Samot | What do you mean by "crashing" |
| 19:08.44 | Guest70 | <PROTECTED> |
| 19:09.18 | Samot | And you already opened a bug report? |
| 19:09.27 | Guest70 | yes let me show you one sec |
| 19:10.15 | Guest70 | https://issues.asterisk.org/jira/browse/ASTERISK-26692?filter=11340 |
| 19:12.16 | Samot | Have you tried 13.14? |
| 19:12.45 | Samot | There was a release since you opened that ticket. |
| 19:12.55 | Samot | Have you tried it to see if your issue goes away? |
| 19:13.17 | *** join/#asterisk Y04NN (~y04nn@2a01:e34:ef37:5870:2053:3c0b:952:dbc2) |
| 19:17.55 | *** join/#asterisk tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 19:20.33 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 19:21.24 | Guest70 | 13.15-RC1 too |
| 19:21.32 | Guest70 | today crashed on 13.15 |
| 19:21.38 | Samot | OK |
| 19:21.56 | Samot | Try not using a "test" release. |
| 19:22.01 | Samot | I said, 13.14 |
| 19:22.08 | Samot | The stable release. |
| 19:22.35 | Guest70 | yes too I´ve tested them all |
| 19:22.41 | Samot | OK |
| 19:22.47 | Samot | And you opened a ticket. |
| 19:22.55 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 19:22.56 | Samot | You should comment on your ticket and supply these debugs. |
| 19:23.10 | Samot | Pointing out you tried an 13.14 and in 13.15.0-rc1 |
| 19:23.13 | Guest70 | I did put the logs |
| 19:23.24 | Samot | For 13.14 and 13.15.-rc1? |
| 19:24.20 | Guest70 | if I do full debug then the system wont work ok |
| 19:24.41 | Guest70 | only for the previosu version but the stack trace is the same |
| 19:25.14 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 19:28.28 | Samot | well there appears to be two tickets open for this issue. |
| 19:28.40 | igcewieling | It's people like you, Guest70 which make me not feel so bad about giving up in TLS/SRTP on Asterisk. 8-) |
| 19:29.12 | igcewieling | Its tough to configure and nearly impossible to troubleshoot. |
| 19:29.18 | Samot | Except this is WebRTC |
| 19:29.25 | Guest70 | Im doing webrtc |
| 19:29.28 | Samot | So it's WSS/DTLS |
| 19:29.51 | Guest70 | so this crash is not tls/srtp has to do with wss/dtls |
| 19:30.02 | Guest70 | https://issues.asterisk.org/jira/browse/ASTERISK-26692?filter=11340 |
| 19:30.06 | Guest70 | sorry |
| 19:30.23 | Samot | Guest70: There are two tickets about your issue |
| 19:30.28 | Samot | One by you and one by someone else. |
| 19:30.48 | Samot | It would seem in both cases more information has been requested.. |
| 19:30.56 | Samot | If there isn't an update on your ticket, request one. |
| 19:31.27 | seanbright | if there was an update on the ticket, it would be there |
| 19:31.50 | scgm11 | I've lerned to not ask for updates :) |
| 19:32.02 | seanbright | there is currently a patch up for review that addresses rtp crashiness - https://gerrit.asterisk.org/#/c/5341 |
| 19:32.17 | seanbright | it may accidentally fix your issue |
| 19:32.28 | scgm11 | my last ticket I'v fixed myself that is why I wanted some guidance |
| 19:32.36 | scgm11 | ok i will try that |
| 19:40.24 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 19:42.22 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 19:43.07 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 20:05.05 | *** join/#asterisk matrix1233 (~matrix123@197.0.36.136) |
| 20:08.51 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 20:15.15 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 20:39.38 | igcewieling | I tried this on Asterisk 11 and have tried it on Asterisk 13.latest. I'm having an issue with HANGUPCAUSE_KEYS(). The dialplan Dial()s a peer (the "g" Dial option is used), if Dial() gets back a busy, the dialplan tries the Dial again. Nothing special about that, many dialplans do the same. I'm using HANGUPCAUSE_KEYS to get the hangupcause information for each of the dial attempts. In this example it would contain 2 items, the c |
| 20:41.39 | igcewieling | i.e. "dial, busy, dial again, answer" would hand back two channel names. every other time those names are swapped. |
| 20:42.17 | igcewieling | Has anyone used HANGUPCAUSE_KEYS enough to have seen this? |
| 20:43.48 | file | it's stored in a hash table so the order is not guaranteed |
| 20:47.37 | igcewieling | ah. Thanks, file. I'll keep track of the channel names in a consistent order in my dialplan code for each dial attempt. shouldn't be too tough. |
| 20:48.43 | adeel | does asterisk support mp3 as a valid voicemail recording format? |
| 20:54.50 | cresl1n | adeel: afaik no |
| 20:54.59 | cresl1n | you can use it as a music on hold format |
| 20:55.19 | adeel | yep, i know about the MOH |
| 21:05.10 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 21:20.59 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:27.27 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 21:45.09 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 22:01.12 | *** join/#asterisk nfsnobody (~nfsnobody@unaffiliated/nfsnobody) |
| 22:26.22 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 23:00.30 | *** part/#asterisk kharwell (kharwell@nat/digium/x-baidwnclwgovlscg) |
| 23:02.25 | *** join/#asterisk karelk (~karel@31.10.157.180) |
| 23:04.55 | *** join/#asterisk Samael28 (~Samael28@79.110.128.128) |
| 23:38.33 | *** join/#asterisk dunderproto (~dunderpro@125-230-68-162.dynamic.hinet.net) |
| 23:54.22 | nfsnobody | hey all. I'm using a custom MOH application for all of my customers based on their customer ID with a definition like application=/usr/bin/ruby /path/to/script 123, under [customer-123] as the class - 123 being an example customer ID. I've got about 400 customers on there, and it appears that asterisk is attempting to load 400 copies of the ruby script at once, one for each class definition. Is there a way I can have these MOH classes be |
| 23:54.22 | nfsnobody | <PROTECTED> |