| 00:02.15 | *** join/#asterisk jrabe (irc@janikrabe.com) |
| 00:20.50 | *** part/#asterisk kharwell (kharwell@nat/digium/x-isiumxcmtxqgovjh) |
| 00:22.08 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 00:56.44 | *** join/#asterisk Yiota (~textual@2607:fea8:56df:fa6d:1d21:b077:2367:df0f) |
| 01:10.33 | *** join/#asterisk Yiota (~textual@2607:fea8:56df:fa6d:1d21:b077:2367:df0f) |
| 01:25.21 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 02:45.36 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:50.46 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 03:05.26 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 03:08.51 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 03:16.08 | *** join/#asterisk evil_gordita (robert@ip70-188-41-127.rn.hr.cox.net) |
| 03:25.27 | *** join/#asterisk Typhon (~Typhon@dslb-088-068-197-213.088.068.pools.vodafone-ip.de) |
| 03:37.42 | *** join/#asterisk Yiota (~textual@2607:fea8:56df:fa6d:f86e:9d1b:5d91:6a19) |
| 03:44.19 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 04:08.08 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 04:26.36 | *** join/#asterisk Maliuta_ (maliutamat@gateway/shell/matrix.org/x-aqoljdznzafrpqdj) |
| 04:51.02 | *** join/#asterisk gerhard7_ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:04.10 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 05:34.45 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 05:45.41 | *** join/#asterisk opmrcl (~Thunderbi@46.11.87.77) |
| 05:52.02 | *** join/#asterisk mutin-s (~s-mutin@85.234.114.134) |
| 06:05.53 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 06:08.44 | *** join/#asterisk kamalpanhwar (~kamalpanh@137.59.227.9) |
| 06:09.01 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 06:13.46 | *** join/#asterisk boris_t (~boris_t@95.183.44.106) |
| 06:26.24 | *** join/#asterisk Demon_VoIP (~demon@eoks.ivanovo.ru) |
| 06:32.44 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 06:40.39 | *** join/#asterisk opmrcl1 (~Thunderbi@46.11.87.77) |
| 06:52.09 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 07:06.08 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 07:29.00 | *** join/#asterisk kamalpanhwar (~kamalpanh@137.59.226.51) |
| 07:29.45 | *** join/#asterisk DanB (~DanB@clt-195.192.204.89.ip-anschluss.net) |
| 07:46.37 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 07:49.14 | *** join/#asterisk jkroon_ (~jkroon@165.16.204.164) |
| 07:58.55 | *** join/#asterisk opmrcl (~Thunderbi@46.11.87.77) |
| 08:15.15 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 08:17.55 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 08:26.31 | *** join/#asterisk opmrcl (~Thunderbi@46.11.87.77) |
| 08:36.56 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 09:04.23 | *** join/#asterisk SunTsu (miyamoto@unaffiliated/suntsu) |
| 09:18.41 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 09:19.58 | *** join/#asterisk gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 09:19.58 | *** mode/#asterisk [+o gtjoseph] by ChanServ |
| 09:32.38 | *** join/#asterisk miralin (~Thunderbi@91.237.94.13) |
| 10:15.02 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 10:21.35 | *** join/#asterisk [[thufir]] (~thufir@192.157.119.2) |
| 11:01.29 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 11:21.15 | *** join/#asterisk miralin (~Thunderbi@91.237.94.13) |
| 11:28.03 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
| 11:39.02 | *** join/#asterisk kamalpanhwar (~kamalpanh@137.59.227.9) |
| 11:56.31 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 12:31.51 | *** join/#asterisk gerhard7_ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:04.18 | *** join/#asterisk kamalpanhwar_ (~kamalpanh@137.59.226.51) |
| 13:14.42 | *** join/#asterisk gerhard7__ (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:18.23 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:49.16 | *** join/#asterisk jkroon__ (~jkroon@165.16.204.162) |
| 13:49.47 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 13:55.47 | sibiria | anyone good with RTP QoS values? |
| 13:56.48 | sibiria | in regards to outgoing calls, i wonder about the lp/rlp values. does the remote lp (rlp) indicate packet loss between the remote trunk and the destination? |
| 13:57.49 | sibiria | lp being the first part of the leg, ie. us and the trunk we call via |
| 13:57.51 | sibiria | ? |
| 13:57.59 | Samot | RTP stats have different names based on the device/system using them |
| 13:58.16 | sibiria | we're using asterisk's rtpqos output |
| 13:58.20 | Samot | Also, it's Asterisk. |
| 13:58.30 | Samot | So the call is technically two channels. |
| 13:58.37 | Samot | Which RTP stats are you looking at? |
| 13:58.45 | Samot | Device to Asterisk or Asterisk to Trunk? |
| 13:59.07 | Samot | Because in once case, the device is the remote and in the other the trunk is the remote. |
| 13:59.40 | sibiria | asterisk (us) to trunk, rtpqos from chan_sip |
| 14:00.26 | sibiria | the rtpqos/audio channel variable, that is |
| 14:00.56 | Samot | And what does it output? |
| 14:01.17 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 14:01.56 | sibiria | ssrc=12345;themssrc=54321;lp=0;rxjitter=0.000000;rxcount=1052;txjitter=0.000886;txcount=374;rlp=0;rtt=0.129334 |
| 14:02.13 | sibiria | jitter and lp (packet loss) are what we're interested in |
| 14:02.28 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 14:02.46 | sibiria | rlp in particular, the "remote" packet loss |
| 14:02.59 | Samot | So this is the bridged info. |
| 14:03.11 | Samot | So in this case that is the stats of both channels |
| 14:03.28 | Samot | With the lp being the Device/Asterisk channel and the rlp being the Asterisk/Trunk channel |
| 14:04.03 | sibiria | lp is the leg between remote trunk and receiver of phonecall? not us (asterisk) to trunk? |
| 14:04.57 | sibiria | we're confused because we keep seeing *zero* packet loss reported even when the audio quality is rubbish |
| 14:05.15 | Samot | I don't know, what direction is the call? |
| 14:05.27 | Samot | If it's device to PSTN then what I said stands. |
| 14:05.33 | Samot | If it's PSTN to device, flip it. |
| 14:05.48 | sibiria | all calls are outgoing from asterisk (our side) to trunk -> PSTN/mobile |
| 14:05.53 | Samot | OK |
| 14:06.04 | Samot | How do the calls start from Asterisk? |
| 14:06.10 | Samot | How is Asterisk making those calls? |
| 14:06.22 | sibiria | callfile, auto-dialler, not via local context |
| 14:06.26 | Samot | OK |
| 14:06.37 | Samot | So then your bridged channels are a local channel on Asterisk |
| 14:06.40 | Samot | And the trunk channel |
| 14:06.43 | Samot | Same thing. |
| 14:06.55 | Samot | The "Device" is just Asterisk. |
| 14:07.03 | Samot | It's using a Local channel to start the call. |
| 14:07.35 | Samot | What codec are you using? |
| 14:08.28 | sibiria | alaw |
| 14:08.58 | sibiria | so the lp/rlp we're seeing is only between our asterisk setup and the SIP trunk? |
| 14:09.01 | Samot | What is the Internet connection speed? |
| 14:09.09 | Samot | Of course. |
| 14:09.10 | sibiria | gbit. it's not a bandwidth issue |
| 14:09.22 | sibiria | and the trunk is "right around the corner", network-wise |
| 14:09.24 | Samot | It will be Asterisk/Local and Asterisk/Trunk bridged together. |
| 14:09.35 | Samot | Thats what the stats show. |
| 14:09.42 | Samot | Well you need to do some MOS tests |
| 14:09.44 | Samot | Or some other tests. |
| 14:10.00 | Samot | alaw is pretty good at correcting itself. |
| 14:10.09 | sibiria | ok. i was under the assumption that "lp" was the first leg (asterisk -> trunk) and rlp was what the trunk reported between them and their next hop towards the destination |
| 14:10.11 | Samot | Plus you have jitter in your transfer |
| 14:10.14 | Samot | From you to them. |
| 14:10.28 | Samot | Stop focusing on the packet loss. |
| 14:10.35 | Samot | There are other issues that can impact this. |
| 14:11.11 | Samot | txjitter=0.000886 <-- You have jitter in your transfer to them |
| 14:11.19 | Samot | Low but it could impact you. |
| 14:11.24 | Samot | You need to run better tests. |
| 14:11.33 | Samot | The QoS reports are not really rule of law. |
| 14:11.41 | Samot | They give you an idea. |
| 14:11.59 | Samot | Go run a MOS test of some sort. |
| 14:12.52 | sibiria | yes the jitter could be a cause, but not to the extent we're hearing. packet loss on "their end" is more likely since we've established they shuttle traffic over huge distances in the case of these calls |
| 14:14.01 | Samot | Go run a MOS test of some sort. |
| 14:14.58 | Samot | I've seen people with 100Mbps connections with shitty VoIP because their own network was garbage. |
| 14:15.07 | Samot | Not all of this is on the Internet. |
| 14:15.20 | Samot | But again, this is between you and the provider. |
| 14:15.23 | Samot | Not you and the end user. |
| 14:15.32 | Samot | And you have jitter in your TRANSFER |
| 14:15.41 | Samot | From *you* to *them* |
| 14:17.00 | Samot | You can have 0 packet loss but still have Jitter |
| 14:17.13 | Samot | You can have 0 packet loss but still have Out of Order Packets. |
| 14:17.29 | Samot | Those two things require the other side to fix it |
| 14:17.34 | Samot | Or they can cause issues. |
| 14:18.10 | Samot | Go run a MOS test of some sort. |
| 14:18.39 | Samot | ^^ Those are specifically designed to test the VoIP abilities of a connection. |
| 14:19.24 | Samot | I've seen people run those and have low results and then they've bypassed their network the results improve. |
| 14:25.27 | sibiria | yeah, uh, we have consistently very low latency and out-of-order problems with this trunk |
| 14:27.43 | sibiria | hence the question about RLP, if there's some way that the remote trunk can share with us data about its connections |
| 14:28.30 | sibiria | would the rtpqos data refer to different parts of the transmission if the outgoing call was placed in a different way? |
| 14:32.38 | sibiria | we're having absolutely *zero* concerns with the opinion scoring of this trunk when it comes to most destinations in this part of the world, but for some rather remote distances this is a recurring problem and it's really never between us and them but rather between them and the receiving party |
| 14:33.07 | sibiria | and we cannot seem to find a good way of catching the problem as it happens so that we can switch trunks mid-problem rather than after the fact |
| 14:38.35 | Samot | Stop. |
| 14:38.36 | Samot | Please. |
| 14:38.45 | Samot | First your calls only go to your PROVIDER. |
| 14:39.03 | Samot | If you're calling across the world, the call from Asterisk is between you and your Provider. |
| 14:39.04 | Samot | That's it. |
| 14:39.19 | Samot | You have no control over anything after that. |
| 14:39.33 | Samot | Your Internet connection has no impact on the data that leaves the provider network |
| 14:39.56 | Samot | Stop equating distance. |
| 14:39.59 | voipmonk | has Globalcrossing flashbacks |
| 14:40.00 | Samot | With your call. |
| 14:40.16 | sibiria | why do you explain this as if no one knew how basic networking happens? we don't wish for control over their network, we are curious about feedback from it |
| 14:40.29 | Samot | Then you have to ask them for it |
| 14:40.48 | Samot | If the stats that Asterisk is returning are not enough for you |
| 14:40.54 | Samot | Not in-depth enough |
| 14:40.59 | Samot | Or whatever, get a program that does more |
| 14:41.14 | Samot | Or if you're concerned about the audio quality, work with your provider to improve it. |
| 14:41.36 | Samot | Does your provider control the media? |
| 14:42.04 | Samot | Or do they pass it through to their upstreams? |
| 14:43.17 | sibiria | they control most of their media, depending on the destination. and for this discussion to take place we actually need something to point them to. this is why i was wondering about if chan_sip's rtpqos report only about the leg between us and the trunk, or if it's "remote" part would happen to refer to the trunk saying something to us about the leg on their end |
| 14:43.44 | Samot | OK.. |
| 14:43.56 | Samot | The "remote" stuff is based on the data it gets back from the provider. |
| 14:44.17 | Samot | If the provider is showing clean but you have audio issues it could be the ROUTE THEY USED |
| 14:44.35 | Samot | The loss could be between THEM and the DESTINATION |
| 14:44.39 | Samot | You'll never see that |
| 14:44.40 | Samot | At all |
| 14:44.42 | Samot | Period. |
| 14:45.06 | Samot | Pick up the phone and call your provider. |
| 14:45.21 | Samot | They are the ones that you need to work with to solve your audio issues with certain destinations. |
| 14:45.24 | sibiria | so effectively, everything in the rtpqos report in this case refers to nothing but the leg between us and trunk, despite being split into a remote part and a "local" part |
| 14:45.39 | Samot | Local is the Asterisk/Local trunk channel |
| 14:45.48 | Samot | Remote is the Asterisk/Trunk channel |
| 14:45.54 | Samot | They are bridged. |
| 14:45.57 | Samot | So yes. |
| 14:46.32 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 14:46.38 | Samot | There are two channels involved in this on Asterisk side. |
| 14:46.54 | Samot | Local = Asterisk origination |
| 14:46.59 | Samot | Remote = Provider trunk |
| 14:49.51 | sibiria | is there some sort of alternative setup (for outgoing calls from asterisk) where the local and remote parts would be extended so that local refers to the asterisk->trunk leg, and remote beyond that? |
| 14:49.59 | Samot | No |
| 14:50.00 | Samot | FFS |
| 14:50.01 | Samot | Stop. |
| 14:50.06 | Samot | That's just not possible. |
| 14:50.11 | Samot | CALL YOUR PROVIDER |
| 14:50.23 | sibiria | i don't know why you think we're not in touch with them :P |
| 14:50.24 | Samot | You need to figure this out with them. |
| 14:50.30 | Samot | Because you're on here. |
| 14:50.35 | Samot | What have they told you? |
| 14:50.47 | Samot | Are they sending those calls to different routes than ones that don't have issues? |
| 14:51.03 | Samot | Are they proxying the media in those cases? |
| 14:51.10 | Samot | Are they handling the media in those cases? |
| 14:51.31 | sibiria | it's obvious that they have different routes depending on the destination, or we'd be seeing this problem consistently with every destination |
| 14:51.37 | Samot | Right. |
| 14:51.43 | Samot | So what is the difference? |
| 14:51.53 | Samot | Have you requested them to modify your routes? |
| 14:53.18 | sibiria | very remote destinations is the difference where this problem pops up (almost) consistently. the request from them is for us to provide them with obvious cases when it's GOING ON, but it's clear that there is no way for us to recieve QoS of what things look like between them and the destination |
| 14:53.31 | Samot | No. |
| 14:53.40 | Samot | There is no way for you to get details about their network. |
| 14:53.47 | Samot | And the traffic on it. |
| 14:54.14 | Samot | No but you can send them a call time |
| 14:54.28 | sibiria | we feed them call ids every damned day. |
| 14:54.38 | Samot | Do you feed them timestamps? |
| 14:54.42 | Samot | Do you feed them PCAPs? |
| 14:55.32 | sibiria | none needed/requested. all they need for the event is the call id. they know, and we know, that there are no problems between us and them. this has never been the case nor the concert. top opinion scoring since always, since before dinosaurs died etc. |
| 14:55.43 | sibiria | concern* |
| 14:55.57 | Samot | OK. |
| 14:56.06 | Samot | So you know it's not between you and them |
| 14:56.14 | Samot | So the only people that can fix this is them. |
| 14:56.30 | Samot | No you cannot get details from their network. |
| 14:56.49 | Samot | Have you made the simple request to change routes? |
| 14:56.54 | voipmonk | or take "them" out of your route and pick another one when you detect these issues, on the fly - |
| 14:56.56 | Samot | To see if a new route solves the issue? |
| 14:57.00 | voipmonk | right ^^ |
| 14:57.07 | Samot | What I've said a few times now |
| 14:57.11 | sibiria | yeah they've been trying new routes left and right |
| 14:57.25 | Samot | Perhaps you should try a new provider. |
| 14:57.29 | sibiria | voipmonk: there's no apparent way for us to see this problem AS IT HAPPENS |
| 14:57.29 | voipmonk | ... no - you take this provider out of your route and move on to another |
| 14:57.41 | Samot | You never will |
| 14:57.50 | Samot | The issue isn't between you and them. |
| 14:57.50 | sibiria | we don't know this is happening until our customer tells us "the dude who received the call said it sounded all shitty" |
| 14:57.53 | Samot | It's them. |
| 14:57.54 | voipmonk | what? |
| 14:57.57 | Samot | It's their shitty routes. |
| 14:58.16 | sibiria | voipmonk: this is where my question about "what is the *remote* part of the QoS about" originates |
| 14:58.30 | Samot | Asked and answered. |
| 14:58.33 | Samot | Multiple times. |
| 14:58.49 | voipmonk | do the mos scores change when you have this issue? |
| 14:58.55 | sibiria | oddly, no |
| 14:59.00 | voipmonk | i dont believe you |
| 14:59.02 | Samot | Because it's not YOU |
| 14:59.02 | voipmonk | can you show me? |
| 14:59.03 | Samot | FFS |
| 14:59.06 | Samot | It's not them. |
| 14:59.07 | sibiria | voipmonk: ... |
| 14:59.12 | Samot | It's not his network |
| 14:59.19 | Samot | It's not his connection to the provider. |
| 14:59.24 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 14:59.25 | Samot | It's the provider's shitty routes |
| 14:59.31 | Samot | Nothing can be done on his side. |
| 14:59.36 | Samot | The provider has to fix this |
| 14:59.45 | Samot | And according to what has been said, they've tried new routes |
| 14:59.53 | sibiria | or so they say... |
| 14:59.53 | Samot | So it's time to try a new provider it seems. |
| 15:00.06 | Samot | They either are not fixing it |
| 15:00.08 | Samot | Or they can't |
| 15:00.18 | Samot | That means another option is needed. |
| 15:03.19 | *** join/#asterisk Da-Geek (~Da-Geek@88.98.221.152) |
| 15:05.58 | *** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 15:06.13 | voipmonk | Recqual |
| 15:06.59 | voipmonk | im showing my age - but i think that might work for you in this instance. |
| 15:07.16 | voipmonk | if you can find it... |
| 15:08.07 | voipmonk | http://blog.krisk.org/2008/12/introducing-recqual.html |
| 15:08.38 | sibiria | how is it able to gauge anything between trunk and destination? |
| 15:08.49 | Samot | You don't |
| 15:08.52 | Samot | You can't |
| 15:08.53 | sibiria | exactly |
| 15:08.57 | Samot | You don't control it. |
| 15:09.06 | Samot | So you'll have to find a provider that does |
| 15:09.18 | Samot | That can give you proper routes. |
| 15:09.33 | sibiria | voipmonk: we're already monitoring our local and immediate network to spot eventual issues between us and trunk |
| 15:10.45 | *** join/#asterisk Da-Geek (~Da-Geek@88.98.221.152) |
| 15:11.30 | voipmonk | ok I'll run the SpoonFeed 2.0 |
| 15:11.31 | voipmonk | https://sourceforge.net/p/recqual/code/HEAD/tree/trunk/ |
| 15:11.44 | voipmonk | go down to the Readme section |
| 15:12.10 | voipmonk | im afraid, you're still going to have to read |
| 15:14.01 | sibiria | thanks but we're already screening the audio feed coming back to us to detect transmission problems |
| 15:14.02 | voipmonk | Its ok to have more than one provider, you can VoIP around. |
| 15:15.50 | *** join/#asterisk kharwell (kharwell@nat/digium/x-hbtdspvybzfblpfg) |
| 15:15.50 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:30.33 | *** join/#asterisk kamalpanhwar (~kamalpanh@111.88.123.240) |
| 15:39.08 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:39.09 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:39.12 | *** join/#asterisk UOL (~king@39.46.168.114) |
| 15:39.34 | UOL | hi... how to configure call transfer like agent transfer in asterisknow? |
| 15:40.59 | [TK]D-Fender | <PROTECTED> |
| 15:41.10 | [TK]D-Fender | please rephrase your request |
| 15:42.51 | *** join/#asterisk MarkS- (~mark@unaffiliated/mark21) |
| 15:46.05 | UOL | i mean.. if someone call on my extension 1001. i received the call and after sometime i want to transfer that call to extension 1002.. how is this possible? you got my point? |
| 15:48.59 | MarkS- | What could be the reason you get lines like listed in https://p.6core.net/p/zBiALHVJJMA6NAVR5wrj50GB ? (when that happens the system seems to stop forwarding calls, I'm running Asterisk 15.1.2 on Debian) |
| 15:52.07 | [TK]D-Fender | UOL, Depends on your phone. Any decent SIP phone has a TRANSFER button on it which has nothing to do with your PBX. It does it all by itself |
| 15:52.34 | [TK]D-Fender | UOL, Most standard ATA's also have call transfer built in as a feature. |
| 15:52.45 | [TK]D-Fender | UOL, So you should be be getting very specific about what you're using. |
| 15:53.21 | [TK]D-Fender | MarkS-, those are just session timeouts and not indicitive of any actual problem |
| 15:55.53 | MarkS- | [TK]D-Fender: there is a problem and we see that many times and not really a good indication of a specific other problem. However calls are failing or sound is missing. |
| 15:56.13 | [TK]D-Fender | Well that message has nothing to do with anything |
| 15:56.24 | [TK]D-Fender | and we aren't looking at debug for one of those failures |
| 15:56.27 | [TK]D-Fender | Go get it |
| 15:58.46 | MarkS- | I'll see if I can find some problems listed in the logs, but at this time I'm also considering to replace the server with a new one and starting from 0 regarding the configuration (at least to think about everything) |
| 15:59.17 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-iqgrimkyefgmanwz) |
| 15:59.17 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 16:03.20 | [TK]D-Fender | Audio problems are almost never "complicated" in any way, so that isn't a reason to trash a system |
| 16:04.08 | [TK]D-Fender | If you want to do that for other reason, then by all means. But if you do that before looking at your previous problem you'll likely either just end up replicating the same settings that caused it, or do it properly and never see where you screwed up. |
| 16:04.23 | [TK]D-Fender | Your choice |
| 16:07.37 | UOL | [TK]D-Fender i test on a cisco phone but it didn't work.. more i want it on a smart phone like zoiper or x-lite... |
| 16:07.53 | [TK]D-Fender | Cisco phones have a normal transfer button |
| 16:08.11 | [TK]D-Fender | And you just mentioned a BRAND and not the MODEL. |
| 16:08.25 | Samot | If it's any Cisco but the SPA series the transfer button won't work. |
| 16:08.37 | Samot | Because of how it sends the transfer to the UCM. |
| 16:08.37 | [TK]D-Fender | That's news to me... |
| 16:08.42 | Samot | Does it? |
| 16:08.47 | Samot | Does it send a REFER? |
| 16:09.25 | [TK]D-Fender | I don't recall from my limited testing, but larger, from anyone ever talking about them in any of these channels ever. |
| 16:09.30 | UOL | ok.. whats about x-lite or zoiper ¿ |
| 16:09.45 | Samot | UOL: How are you trying to transfer? |
| 16:09.51 | Samot | On the Cisco? |
| 16:09.59 | Samot | Are you using the Transfer button? |
| 16:10.52 | UOL | Samot no.. am asking for smart phone now.. like x-lite or zoiper ¿ |
| 16:11.03 | Samot | OK |
| 16:11.06 | Samot | I know what you are asking |
| 16:11.13 | Samot | You said you tested on the Cisco and it didnt work.. |
| 16:11.16 | Samot | How did you test? |
| 16:11.35 | UOL | yeah.. i also test on a cisco phone too.. |
| 16:11.39 | Samot | How did you test? |
| 16:11.51 | Samot | How did you transfer the call on the Cisco phone? |
| 16:12.28 | Samot | Did you use the "Transfer" button on the phone? |
| 16:12.30 | UOL | like i make a trunk with UCM in my asterisk... i call an UCM extension from asterisk server and then try to transfer it to other UCM extension by transfer button on cisco phone.. |
| 16:12.38 | Samot | Thank you. |
| 16:12.46 | Samot | So there is a UCM in all this. |
| 16:12.51 | Samot | That's very important to know. |
| 16:13.09 | [TK]D-Fender | you also don't transfer to a "UCM extension" |
| 16:13.10 | Samot | Because now there is something in between Asterisk and the devices. |
| 16:13.27 | Samot | He has a UCM trunked to Asterisk. |
| 16:13.38 | [TK]D-Fender | if that phone if registered to ASTERISK, and not the UCM, then all comms are between it and Asterisk |
| 16:13.41 | Samot | Sounds like he's trying to transfer between Asterisk and the UCM. |
| 16:13.43 | MarkS- | Now first getting the log for 1 start-stop period of asterisk to see if I can find the problem in it |
| 16:14.07 | UOL | Samot yes... exactly... |
| 16:14.12 | [TK]D-Fender | And saying "it didn't work" doesn't tell me that the phone's transfer function is the faulty link in this chain |
| 16:14.18 | Samot | So that has nothing really to do with the device. |
| 16:14.21 | [TK]D-Fender | Show it <- |
| 16:15.18 | UOL | well Samot and [TK]D-Fender leave the cisco for a while.. and comes to x-lite or zoiper.. how can we do this ¿ |
| 16:15.27 | Samot | No. |
| 16:15.33 | Samot | You're not understanding... |
| 16:15.35 | [TK]D-Fender | UOL, this is NOT a phone issue from what we can tell |
| 16:15.38 | [TK]D-Fender | ^ |
| 16:15.40 | Samot | The issue might not be the phone. |
| 16:15.43 | [TK]D-Fender | Show us your failure |
| 16:15.48 | Samot | You are sending a call from Asterisk to the UCM |
| 16:15.59 | Samot | Have you confirmed that is all correct? |
| 16:16.20 | Samot | Asterisk is sending it right, the UCM is receiving right? |
| 16:17.43 | UOL | Samot yes.. its correct.. i call from asterisk extension 1001 to UCM extension 2001.. it works.. |
| 16:18.00 | Samot | Not the original call. |
| 16:18.02 | Samot | The TRANSFER |
| 16:18.33 | UOL | Samot no log message on UCM and asterisk debug.. |
| 16:19.03 | Samot | Show things. |
| 16:19.05 | *** join/#asterisk zerohalo (~zerohalo@2601:199:417f:9c3d:d4ce:ccd1:a4f6:832e) |
| 16:19.10 | Samot | At this point you need to start showing things. |
| 16:19.23 | UOL | well.. tell me how can i do it on x-lite or zoiper.. just asterisk server |
| 16:19.27 | Samot | You need to reproduce this issue and doing it will you have a debug. |
| 16:19.33 | UOL | Samot wait... |
| 16:19.34 | Samot | There's nothing to tell. |
| 16:19.37 | Samot | It's a button. |
| 16:19.40 | Samot | You press it |
| 16:19.45 | UOL | on x-lite? |
| 16:19.50 | Samot | They will both have "transfer" buttons. |
| 16:19.53 | Samot | Yes. |
| 16:20.17 | [TK]D-Fender | X-Lite didn't have a transfer button last I checked. has that changed? |
| 16:20.36 | [TK]D-Fender | That used to be a fewture they cripped to get you to buy Bria |
| 16:20.41 | Samot | Actually, I haven't looked in a while. |
| 16:20.45 | [TK]D-Fender | That used to be a feature they crippled to get you to buy Bria |
| 16:20.50 | Samot | Well transfer might be one of those |
| 16:20.57 | Samot | I know BLF and couple others are. |
| 16:21.03 | [TK]D-Fender | Either way we shouldn't be moving targets |
| 16:21.11 | Samot | But Zoiper will have a transfer button. |
| 16:21.16 | [TK]D-Fender | UOL, Stop talking about other phones and look at the problem you have now. |
| 16:21.34 | [TK]D-Fender | <UOL> on x-lite? <- on YOUR phone. |
| 16:21.49 | [TK]D-Fender | Stop looking at other stuff and look at YOUR problem with YOUR gear |
| 16:23.00 | UOL | [TK]D-Fender forget phone.. talk about smart phones. like zoiper or x-lite or anyother |
| 16:23.17 | [TK]D-Fender | UOL, Show us taht the phone is the actual probelm. |
| 16:23.18 | Samot | OK, I'm done. |
| 16:23.28 | Samot | The phone, at this point, doesn't appear to be the issue. |
| 16:23.29 | [TK]D-Fender | Other wise yyou'll likely end up with the SAME problem. |
| 16:23.42 | [TK]D-Fender | Phone is NOT the probelm so far. |
| 16:23.46 | Samot | But if we're going to keep talking about phones or softphones, there's no point in the conversation. |
| 16:23.50 | UOL | [TK]D-Fender and Samot wait.. let me open x-lite on my 2 pcs.. |
| 16:23.54 | [TK]D-Fender | ---> SHOW US THE FAILED CALL <---- |
| 16:24.16 | UOL | and try to transfer to the call to 3rd one... without cisco.. all 3 on asterisk server for testing.. ok |
| 16:24.21 | Samot | [TK]D-Fender: All yours. |
| 16:24.28 | Samot | goes back to work. |
| 16:24.28 | [TK]D-Fender | Why do we need 2 X-Lite's? You're talking about sending a call to UCM. that isn't "2 X-Lites". Your test is NOT the same and your description is garbage. |
| 16:24.36 | [TK]D-Fender | Samot, I feel ya.... |
| 16:25.52 | UOL | [TK]D-Fender wait bro... i said leave UCM for a while... |
| 16:26.31 | [TK]D-Fender | Why? |
| 16:26.34 | [TK]D-Fender | that was the PROBLEM |
| 16:26.56 | [TK]D-Fender | Talking about other things outside of the actual problem is a waste of time |
| 16:29.54 | UOL | no.. actually.. we are planning for a call center.. in which we will provide smart phones. like zoiper or x-lite. not the cisco phones.... that's why.. i want to test it too. |
| 16:31.00 | [TK]D-Fender | Then you should be using BRia or something higher quality than those |
| 16:32.59 | *** join/#asterisk overyander (~jeff@12.49.160.131) |
| 16:34.40 | UOL | Bria is premium :( |
| 16:38.32 | [TK]D-Fender | You want something GOOD? |
| 16:38.39 | [TK]D-Fender | Guess what, life costs sometimes. |
| 16:39.05 | [TK]D-Fender | When yuo realize your phones sleep-mode will screw you with other softwares, etc you'll realize this |
| 16:39.46 | Samot | If you're going to use a softphone for this.. |
| 16:39.50 | Samot | Pay for it. |
| 16:40.09 | Samot | Because it comes with a whole set of issues that IP phones do not. |
| 16:40.41 | Samot | IP phones don't care about what your PC/mobile device is doing. |
| 16:41.01 | Samot | IP phones don't get impacted by the PC/mobil device being overloaded. |
| 16:41.06 | Samot | Not enough memory |
| 16:41.08 | Samot | CPU |
| 16:41.22 | Samot | Other programs and backgrounds processes taking up resources. |
| 16:42.06 | [TK]D-Fender | "sleep mode" killing your Wifi connection. |
| 16:42.15 | Samot | All sorts. |
| 16:42.32 | Samot | On mobile devices, poor backgrounding.. |
| 16:42.44 | [TK]D-Fender | And then hoping you'll get a **GUI** to send some sort of wake-up to compensate for your poor choices? Yeah... you're building on a poor foundation |
| 16:43.08 | Samot | This isn't like a call center business right? |
| 16:43.20 | Samot | Where other companies use you as their call center? |
| 16:43.29 | Samot | This is just some internal call center? |
| 16:43.59 | UOL | Samot.. 1 more thing.... |
| 16:44.10 | UOL | is there any billing module in asterisk...? |
| 16:44.27 | [TK]D-Fender | Have you gone looking? |
| 16:44.32 | [TK]D-Fender | Asterisk doesn't PROVIDE one. |
| 16:44.38 | [TK]D-Fender | other people make add-ons. |
| 16:45.14 | [TK]D-Fender | Asterisk is not in the business of making "ready-to-roll-out" calling card business server solutions. |
| 16:45.30 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:45.30 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 16:45.33 | [TK]D-Fender | or "ITSP-in-a-box" |
| 16:46.29 | UOL | hmmm.... |
| 16:46.46 | UOL | so no module in asterisk... or anyother 3rd party for billing |
| 16:47.04 | [TK]D-Fender | <[TK]D-Fender> other people make add-ons. <-- what part of this is unclear? |
| 16:47.18 | [TK]D-Fender | THAT'S VERY CLEARLY 3RD PARTY |
| 16:47.24 | [TK]D-Fender | OTHER people make them |
| 16:47.26 | [TK]D-Fender | WE don't |
| 16:47.44 | UOL | kindly refer me some 3rd party tool please.. :) |
| 16:47.45 | [TK]D-Fender | They make them. We don't and we don't support their stuff. |
| 16:47.51 | [TK]D-Fender | www.google.com <----- |
| 16:48.00 | Samot | We have no idea on what you need. |
| 16:48.11 | Samot | What type of billing |
| 16:48.17 | Samot | How you're going to bill |
| 16:48.22 | Samot | What you are billing |
| 16:48.29 | Samot | How can we recommend something? |
| 16:48.36 | [TK]D-Fender | And we aren't here to build your business for you |
| 16:49.15 | [TK]D-Fender | Get Google-ing. |
| 16:49.32 | [TK]D-Fender | And keep your actual needs in mind. |
| 17:08.07 | *** part/#asterisk kamalpanhwar (~kamalpanh@111.88.123.240) |
| 17:24.26 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |
| 17:41.25 | *** join/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net) |
| 17:42.52 | igcewieling | If anyone can recommend a good place to get SSL certs, but NOT from Thawte, VeriSign, Equifax, GeoTrust, or RapidSSL? /msg my privately so we don't spam the channel |
| 17:44.11 | Samot | Kinda leaves Comodo |
| 17:48.11 | igcewieling | Samot: thanks, didn't remember them |
| 17:49.22 | Samot | I'm sure there might be others. The real question is device support. |
| 17:52.28 | igcewieling | Comodo is about 1/3 the price of the other ones I've seen. DigiCert: $175, Entrust: $160, GlobalSign $249 |
| 18:01.47 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 18:17.30 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 18:18.15 | *** part/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net) |
| 18:20.36 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 18:22.36 | *** join/#asterisk samwierema (~samwierem@095-097-255-066.static.chello.nl) |
| 18:25.16 | samwierema | What's the default timeout for a call originated from Asterisk? I.e. sending a CANCEL after x seconds if not receiving a 200 OK on an INVITE. And how can I configure it? |
| 18:26.01 | rrittgarn | sorry thought i had /msg in front of that |
| 18:32.38 | [TK]D-Fender | samwierema, It's your job to specify the timeout |
| 18:32.45 | [TK]D-Fender | it's a parameter for a reason |
| 18:33.10 | [TK]D-Fender | nothing specified should = unlimited as long as there is progress |
| 18:35.24 | samwierema | [TK]D-Fender: ok, clear. Thanks! |
| 18:35.51 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 18:38.48 | *** join/#asterisk sekil (~sekil@cable-89-216-221-107.dynamic.sbb.rs) |
| 18:39.09 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 19:07.53 | Kobaz | UOL: a2billing |
| 19:08.09 | Kobaz | oh, he's gone |
| 19:08.33 | Kobaz | speaking of soft phones |
| 19:08.37 | Kobaz | i quoted out a system for 200 polycoms |
| 19:08.50 | Kobaz | and then they were like, umm, what about if we go with soft phones |
| 19:09.12 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 19:09.24 | Kobaz | i'm like um... you'll save in hardware, but then we'll quadroupple your support contract cost |
| 19:12.19 | [TK]D-Fender | and have shitty headsets on your PC's you're paying for instead, distrations with getting to/from the interface between taking other action, slower things like initial dial, transfer, etc |
| 19:12.34 | [TK]D-Fender | In the end I only recommend them in the smallest of cases |
| 19:12.49 | *** join/#asterisk overyander (~jeff@12.49.160.131) |
| 19:12.52 | [TK]D-Fender | but he's talking "mobiles".... so there's another set of issues, but more of a reason to use one |
| 19:24.13 | *** join/#asterisk Yiota (~textual@2605:8d80:6c6:652b:7450:c70a:7108:10f4) |
| 19:24.37 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 19:52.11 | *** join/#asterisk d3vnull (~d3vnull@154.160.1.72) |
| 19:56.22 | *** join/#asterisk Yiota (~textual@2605:8d80:6c7:1988:5075:53b1:fd60:1176) |
| 20:06.54 | *** join/#asterisk Yiota (~textual@2605:8d80:6c7:1988:5075:53b1:fd60:1176) |
| 20:09.32 | *** join/#asterisk ezra-s (~ezra-s@apache/committer/dferradal) |
| 20:17.12 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 20:20.44 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:20.44 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 20:41.23 | *** join/#asterisk Yiota (~textual@2605:8d80:6c7:1988:5075:53b1:fd60:1176) |
| 20:42.01 | ezra-s | hello, after I established a call if there is an ivr on the other end or similar, when I try to dial for the options available, the numbers I dial are not recognized, anyone familiar with this issue can help? |
| 20:44.34 | vo1pbx | set DTMF mode correctly |
| 20:44.47 | vo1pbx | RFC-something somthing |
| 20:45.03 | vo1pbx | 2813 |
| 20:45.05 | vo1pbx | 1832 |
| 20:45.16 | vo1pbx | _will_ open the lock |
| 20:45.19 | ezra-s | RFC2833 |
| 20:45.22 | ezra-s | did that |
| 20:45.23 | vo1pbx | ^^ |
| 20:45.31 | vo1pbx | show some log |
| 20:45.39 | ezra-s | I dag a little, but I'm still failing |
| 20:45.45 | vo1pbx | LOG |
| 20:46.11 | vo1pbx | rolls down stairs, alone or in pairs, and over the neighbours dog |
| 20:46.27 | vo1pbx | fits on your back, great for a snak, etc. |
| 20:46.49 | *** join/#asterisk tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 20:50.27 | ezra-s | vo1pbx: https://hastebin.com/molimujati.md <-- LOG |
| 20:51.57 | vo1pbx | auth failure on line 15(of fifty-one, srsly) |
| 20:52.15 | vo1pbx | passthrough |
| 20:52.19 | vo1pbx | ^^get rid of that |
| 20:54.35 | ezra-s | vo1pbx: this one? -> confbridge.conf:;dtmf_passthrough=yes |
| 20:54.45 | vo1pbx | uhm |
| 20:54.51 | ezra-s | seems like a default value since its commented, but setting it to "no" manually |
| 20:54.53 | vo1pbx | potentailly |
| 20:57.30 | ezra-s | mmm, set that to no, restarted asterisk, same problem remains... if there is anything else I can show, config files, other logs.. |
| 20:57.31 | vo1pbx | i don't recall any mention of 'conference' |
| 20:58.17 | ezra-s | vo1pbx: probably my absolute ignorance, I did grep passthrough through the whole asterisk conf directory and thats the only thing I could find |
| 20:58.59 | vo1pbx | all i'm saying is, say no to inband signnaling |
| 20:59.31 | vo1pbx | bridged channels and all that jazz |
| 20:59.40 | ezra-s | the voip phone priorizes RFC2833 |
| 20:59.58 | ezra-s | and the sip parameters have only the same rfc2833 |
| 21:01.59 | ezra-s | admits to be quite clueless regarding asterisk |
| 21:02.07 | *** join/#asterisk mutin-s (~s-mutin@85.234.114.134) |
| 21:03.32 | vo1pbx | ~book |
| 21:03.32 | infobot | Asterisk: The Definitive Guide, 4th Edition (ISBN 1-4493-3242-0) available at http://oreilly.com/catalog/0636920025894 - Asterisk: The Definitive Guide is released under a Creative Commons License (http://creativecommons.org/licenses/by-nc-nd/3.0/us/) and a version is available for reading online at http://www.asteriskdocs.org/ or see ~buybook |
| 21:03.44 | vo1pbx | ^^free |
| 21:03.56 | ezra-s | ohh, nice! |
| 21:04.29 | vo1pbx | someone may have more to offer, but, sadly, i'm off... perhaps a little later. |
| 21:05.00 | vo1pbx | verbose logging and extreme detail will help in the interim |
| 21:05.42 | ezra-s | I'll go for that |
| 21:07.02 | ezra-s | vo1pbx: thanks for trying |
| 21:11.07 | *** join/#asterisk danielyk (~danielyk@p549344C4.dip0.t-ipconnect.de) |
| 21:11.11 | *** join/#asterisk sirsnus (~woose@c-76-105-87-190.hsd1.ga.comcast.net) |
| 21:14.09 | danielyk | Hello. I have a question to the logical structure of /var/lib/asterisk/sounds/. I use asterisk with multi-language, default is 'en' and some extensions/trunks uses 'de'. Should be in the directory /var/lib/asterisk/sounds/ only two subdirectories 'en' and 'de'? Or also one copy of the 'en' directory as fallback? |
| 21:18.10 | vo1pbx | voip-info.org has some dated yet relevant information pertaining to your query. |
| 21:30.24 | danielyk | I interpret this that all default language files (for fallback) should be in /var/lib/asterisk/sounds/en/ |
| 21:32.33 | vo1pbx | i run 1.6.. yes |
| 21:32.58 | vo1pbx | ymmv |
| 21:33.17 | danielyk | Why on so an old version? |
| 21:33.25 | vo1pbx | cepstral |
| 21:33.59 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:33.59 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 21:40.12 | *** join/#asterisk Perlon (minimalist@2a03:b0c0:0:1010::36:1) |
| 21:41.20 | *** join/#asterisk youtmon (~yout@c-98-242-250-233.hsd1.fl.comcast.net) |
| 22:17.23 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 22:30.35 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 22:30.36 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 22:53.06 | *** join/#asterisk Yiota (~textual@207.164.151.42) |
| 23:20.14 | *** join/#asterisk MrTAP (~MrT@unaffiliated/mrtap) |