| 00:01.59 | aNullValue | lol |
| 00:02.04 | aNullValue | ok, thanks for the anti-answer |
| 00:06.01 | Samot | What anti-answer? |
| 00:06.20 | Samot | You claimed to have searched the Internet and couldn't find any SIP phones that supported video that wasn't Android. |
| 00:06.38 | Samot | I've given you three vendors that have multiple options. |
| 00:06.52 | Samot | Are you looking for a specific phone? |
| 00:08.03 | aNullValue | literally all three vendors you mentioned (poly, yealink, grandstream), of their phones that i can determine support video calling, they are _all_ built on ancient versions of android. it's right there on their spec sheets. |
| 00:08.42 | aNullValue | i'm not looking for a specific phone; i'm looking for someone who had experience and could give advice (the first words i said), and elaborated that i'm worried because all of these phones seem sketchy to me |
| 00:09.46 | Samot | Sketchy? |
| 00:09.59 | Samot | They are like in the top 5 vendors in this space. |
| 00:10.09 | Samot | Polycom is at the top. |
| 00:10.21 | Samot | So sketchy that fortune 500 companies use them. |
| 00:10.24 | aNullValue | yes, i understand that those are among the best vendors |
| 00:10.27 | aNullValue | jesus fuck i'm aware |
| 00:10.40 | Samot | So if you need a solid phone that does video, Poly or Yealink. |
| 00:10.40 | aNullValue | these _models_ are what worry me, not the companies |
| 00:11.01 | Samot | OK well as someone who uses them on a large scale, they are fine. |
| 00:11.11 | Samot | They work just fine. They have firmware updates regularly. |
| 00:33.10 | *** join/#asterisk Casper (~Casper@unaffiliated/thephantom) |
| 00:35.42 | Casper | hi there, I use a VoIP provider, that run asterisk on their side... They claim there is no issue on their side (and no reviews say anything, so I tend to believe it, somewhat). I get a loss of incomming or outgoing audio, intermittant, permanant, which persist on the next immediate call. I use an ATA box (which got replaced). Does anyone have an idea how to debug this to prove that it is on my side or theirs or my isp or whatever? |
| 00:42.57 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 00:44.11 | *** join/#asterisk Dovid (~dovid@ool-4356e81f.dyn.optonline.net) |
| 01:13.41 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 01:24.15 | *** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 02:09.18 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 04:23.55 | *** join/#asterisk ttys000 (~ttys000@142.126.114.49) |
| 04:43.11 | *** join/#asterisk retentiveboy (~retentive@c-76-97-11-199.hsd1.ga.comcast.net) |
| 05:24.02 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 06:06.50 | *** join/#asterisk retentiveboy (~retentive@c-76-97-11-199.hsd1.ga.comcast.net) |
| 06:28.55 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 06:39.47 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 07:11.16 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 07:53.51 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 08:03.43 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 08:10.45 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 08:31.58 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 08:41.31 | *** join/#asterisk velix (~velix@unaffiliated/velix) |
| 08:43.01 | velix | Hmm. Seems my manager.conf didn't make it from 17.5.1 to 18.1.0 - it's listening, but I cannot connect. I wasn't able to find a change in the changelog. Anyone with an idea, what might be wrong? https://bpa.st/4YJA |
| 08:45.54 | velix | The module is loaded, the port is listening |
| 08:49.41 | velix | oh heck... found it ;) |
| 08:52.29 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 09:32.31 | *** part/#asterisk velix (~velix@unaffiliated/velix) |
| 10:13.40 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 11:07.10 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 11:38.23 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 11:43.39 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 11:46.12 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 11:59.09 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 12:10.32 | *** join/#asterisk vasilakisfil (~vasilakis@51.15.225.200) |
| 12:11.51 | vasilakisfil | hey I am building a sip server just for fun, but I was lookin in rfc 3261 and in the client transaction state machine, I found a flow (which I guess is already known, or I am missing something since this rfc is 20 years old). Specifically, in the case that the client transaction receives a provisional code, there is no way out of that state, unless it then receives a final response. At least the rfc doesn't mention anything.. |
| 12:12.08 | vasilakisfil | rfc 6026 doesn't make any changes to that either |
| 12:12.23 | vasilakisfil | does anyone know for how long it should stay in proceeding state ? |
| 12:17.12 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 12:19.48 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 12:43.58 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 14:14.43 | *** join/#asterisk pedro__ (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 14:25.55 | *** join/#asterisk mrkiko (~mrkiko@negher.net) |
| 14:28.25 | mrkiko | Hello guys! I am trying since some time to develope a channel driver for asterisk or alternatively a SIP->GSM gateway similar in scope to chan_dongle, but based on a different approach (e.g.: using ModemManager). I wrote down the code interfacing with MM and thus can track incoming calls and so on. My problem was I couldn't wrap my head around PJSIp and so on. so was seeking for recommendations. |
| 14:29.14 | mrkiko | Maybe I can handle calls on my own and talk to Asterisk somehow to tell it something like - go read audio from serial / write it to serial ? I managed to handle audio also, doing calls from the console, but with a standalone app, not within asterisk |
| 14:46.38 | *** join/#asterisk drathir87 (~drathir@gateway/tor-sasl/drathir) |
| 14:58.18 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 15:02.49 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 16:06.36 | *** join/#asterisk tips (~tips@pool-173-72-12-154.cmdnnj.fios.verizon.net) |
| 16:28.54 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 17:07.44 | *** join/#asterisk jkroon (~jkroon@165.16.203.107) |
| 17:08.28 | *** join/#asterisk COVID-1984 (worker@2a01:7e01::f03c:92ff:fecb:5a96) |
| 17:08.38 | COVID-1984 | <PROTECTED> |
| 17:08.46 | COVID-1984 | <PROTECTED> |
| 17:19.04 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 17:26.42 | *** join/#asterisk retentiveboy (~retentive@c-76-97-11-199.hsd1.ga.comcast.net) |
| 17:37.36 | aNullValue | anyone have experience with Avaya Vantage phones in Asterisk? i'm wondering if they "just work", as the docs seem to indicate, or if they are difficult and aren't great SIP phones (like Avaya's 96x0 and 12xx lines, which I've worked with in Avaya environments) |
| 17:45.51 | sibiria | COVID-1984: most DID providers also offer shortcodes and relaying of SMSes sent to them |
| 17:47.05 | sibiria | but short codes are expensive everywhere, even when you buy just a prefix on a shared one :) |
| 17:47.48 | COVID-1984 | @sibiria can you recommend a provider that explicitly states they support receiving shortcodes? |
| 17:48.01 | COVID-1984 | I tried voip.ms and about 90% of shortcodes I've not been able to receive. |
| 17:48.52 | sibiria | voxbone, infobip, sinch |
| 17:49.51 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 17:50.45 | sibiria | i don't know the full list of countries they provide short codes for, but we have such registered with these three providers in a handful of european countries |
| 17:51.08 | sibiria | messagebird also provides short codes |
| 17:51.59 | COVID-1984 | thanks will try those out and switch to whomever is the most confident about receiving shortcodes long-term. |
| 17:52.13 | COVID-1984 | Too bad banking and many other services (Uber) still needs them |
| 17:52.16 | sibiria | and regarding reliability, i have no concerns about any of these three |
| 17:52.35 | sibiria | at least not in the scope of SMSes sent to them through european cellular grids |
| 17:52.55 | sibiria | they've been entirely reliable for us |
| 17:55.21 | COVID-1984 | will need to receive US shortcodes, and receive them on browser or app (software)... I'm guessing those three don't require any hardware (they are SIP) |
| 17:55.40 | drmessano | What do you mean you haven't been able to recieve 90% of them? |
| 17:56.01 | sibiria | they relay SMSes over REST towards an http endpoint of yours. very basic, and the most common solution for these things |
| 17:56.10 | drmessano | Yep |
| 17:57.44 | COVID-1984 | drmessano: I ported my phone # from Google Voice to voipms and about 90% of the services I was using and needed to send shortcodes (airbnb, uber, etc)... they cannot be received on voipms (and voipms docs say they cannot officially support shortcodes)... And googling about it shows very little about who official supports them. |
| 17:58.26 | COVID-1984 | sibiria: nice, sounds like it'll work well |
| 18:09.12 | Samot | Well shared short codes are being phased out. |
| 18:16.02 | COVID-1984 | 'shared' meaning? |
| 18:16.39 | sibiria | that you get a prefix rather than a whole short code just for yourself |
| 18:17.10 | sibiria | short codes in most countries are 5 digits, sometimes 6. very limited availability, high cost to subscribe to one |
| 18:17.44 | sibiria | so customers can use a shared one where the text message must contains a prefix to be relayed to you |
| 18:18.31 | COVID-1984 | ok, was just talking about random shortcodes from services for sending OTPs |
| 18:18.49 | sibiria | what do you mean by "random short codes"? |
| 18:18.56 | COVID-1984 | there's the shortcode itself, and then the messages sent within it, right? Which is OTP in these cases. |
| 18:19.25 | COVID-1984 | sibiria: when you login to your bank, for example... They don't just use a password. They have to send you an one-time-password via SMS often. |
| 18:19.36 | COVID-1984 | This OTP they send via SMS is done using a shortcode SMS, right? |
| 18:19.47 | sibiria | sometimes, sometimes not |
| 18:19.55 | sibiria | more common with an alphanumeric sender in my experience |
| 18:20.33 | sibiria | there's technically no difference |
| 18:20.41 | COVID-1984 | Well voipms classifies them as "Shortcodes" and that is why it says it does not support them. |
| 18:20.50 | sibiria | it comes down to what the SMS provider you use will allow |
| 18:20.52 | COVID-1984 | Even more receiving only. |
| 18:21.12 | sibiria | some of them will relay SMSes on your behalf using any sender, whether numerical or alphanumerical |
| 18:22.12 | sibiria | the providers we use, and the european countries we operate with mostly, have no restrictions on SMS sender IDs |
| 18:22.14 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 18:22.42 | COVID-1984 | Cool. voipms citied some US laws that make it difficult for them to support |
| 18:23.30 | sibiria | some countries restrict this in terms of having to register the sender ID with all providers operating in the country in question, on national level |
| 18:23.42 | sibiria | but, again, as far as europe goes it's mostly still entirely open use |
| 18:24.02 | sibiria | can send an SMS from "12345" or "fuckface", and providers in most countries will relay it as-is |
| 18:24.20 | sibiria | without us having to "register" or be affiliated in some way with the sender ID |
| 18:57.02 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 19:09.02 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 19:20.03 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 19:36.52 | Casper | hi there, I use a VoIP provider, that run asterisk on their side... They claim there is no issue on their side (and no reviews say anything, so I tend to believe it, somewhat). I get a loss of incomming or outgoing audio, intermittant, permanant, which persist on the next immediate call. I use an ATA box (which got replaced). Does anyone have an idea how to debug this to prove that it is on my side or theirs or my isp or whatever? |
| 19:39.59 | *** part/#asterisk mrkiko (~mrkiko@negher.net) |
| 19:42.23 | akp55 | take a tcpdump |
| 19:43.24 | akp55 | is it possible to set a name on a channel, so that if a call is forwarded from the phone, asterisk applies a named pattern to it? |
| 20:25.23 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 20:25.23 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-183.dsl.bell.ca) |
| 20:25.23 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 20:25.23 | *** join/#asterisk _0x5eb_ (~seb@seb-hpws2.elen.ucl.ac.be) |
| 20:25.23 | *** join/#asterisk johndoto (~johndoto@cpe-24-168-58-62.hvc.res.rr.com) |
| 20:25.23 | *** join/#asterisk hvxgr (~wl2v_usrn@epjdn.zq3q.org) |
| 20:25.23 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 20:25.23 | *** join/#asterisk Kritnich (~Kritnich@kritni.ch) |
| 20:25.32 | *** join/#asterisk mir100 (~Vladimir@168.91.199.5) |
| 20:26.06 | *** join/#asterisk ghoti (~paul@bras-base-ptldon0102w-grc-03-76-66-164-183.dsl.bell.ca) |
| 20:27.06 | *** join/#asterisk Champi (Champi@damn.e-leet.be) |
| 20:27.42 | *** join/#asterisk tsal (~tsal@i59F4A3BD.versanet.de) |
| 20:28.00 | *** join/#asterisk [NC] (~NC@208.94.241.140) |
| 20:28.16 | *** join/#asterisk leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:28.16 | *** mode/#asterisk [+o leifmadsen] by ChanServ |
| 22:16.39 | drmessano | Casper: What are you using for a router? |
| 22:18.27 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 22:19.09 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 22:21.44 | Casper | drmessano: ubiquiti ER-6p |
| 22:22.15 | drmessano | I guess if you have a SIP ALG on there, disable it |
| 22:22.56 | Casper | appears to be disabled |
| 22:23.17 | Casper | but sip alg.. wouln't that cause it to just not work? it work fine for like 25-30 mins then the problem happen... |
| 22:23.29 | Casper | and then... I can be months without any issue |
| 22:24.26 | drmessano | 25-30 mins sounds like a timeout |
| 22:24.45 | Casper | but again, it's intermittant |
| 22:24.46 | drmessano | and typically on the local NAT |
| 22:26.02 | Casper | so can still be a router issue if it work fine for months then for a while it do that, then fine again for months? |
| 22:26.14 | drmessano | Sure can |
| 22:27.21 | Casper | is there any easy tests that can be done to make sure that it is the issue? |
| 22:27.44 | drmessano | Can you resolve the issue by power cycling the ATA? |
| 22:28.07 | drmessano | or does it persist through a reboot? |
| 22:28.58 | Casper | it persisted sometime throught an entire power cycle (modem + router + ata) |
| 22:29.41 | Casper | but usually an ATA power cycle did fixed it, but I'm tempted to say that it may not be related as it is not constant |
| 22:30.33 | drmessano | so all 3 devices power cycled, you're 100% certain? |
| 22:31.10 | *** join/#asterisk mTeK (~quassel@192.151.137.68) |
| 22:31.41 | Casper | yup, 100% sure that it did not always fixed it |
| 22:32.23 | Casper | thing is, when it do it, the immediate next call is still in trouble, but the second one usually is fine (but only have a few minutes so don't know if it is really fine or not) |
| 22:37.35 | Casper | any idea how to do some tests? |
| 22:38.03 | Casper | because I'm about to cancel 3 voip lines and go to landline... at 10 times the price... |
| 22:39.23 | drmessano | 99% of the time, client issues are the firewall |
| 22:39.27 | drmessano | But |
| 22:39.31 | drmessano | If the provider is the issue |
| 22:39.50 | drmessano | Why in the actual hell are you going to go back to copper? Why not just... find another provider? |
| 22:40.13 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 22:40.22 | drmessano | That seems like a 2003 reaction |
| 22:41.01 | Casper | because I'm that fed up with the troubles |
| 22:41.19 | Casper | just want something that work |
| 22:41.27 | drmessano | Copper is dead |
| 22:41.31 | drmessano | Find another provider, really |
| 22:41.43 | Casper | (actually will be phone over coax, but meh) |
| 22:42.09 | drmessano | ¯\_(ã)_/¯ |
| 22:43.10 | drmessano | Who is the provider? |
| 22:43.23 | Casper | voip.ms |
| 22:43.42 | Casper | hmm is sip alg = nf_conntrack_sip |
| 22:43.43 | Casper | ? |
| 22:44.02 | drmessano | I have never heard of issues like that with voip.ms. They are my backup carrier |
| 22:44.18 | drmessano | You made it sound like this was some small provider |
| 22:45.05 | drmessano | nf_conntrack_sip is enabled huh? |
| 22:45.20 | drmessano | s/enabled/loaded/ |
| 22:46.07 | drmessano | set system conntrack modules sip disable |
| 23:12.29 | Casper | but if it was that... why would it make trouble for a few days, then be a few months with zero issue? |
| 23:18.54 | *** join/#asterisk AndyCap (~aoy@pdpc/supporter/sustaining/AndyCap) |
| 23:33.07 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 23:37.58 | Kobaz | drmessano: i had that |
| 23:38.18 | Kobaz | drmessano: prospect was all excited about voip and working from home, the director of the place was sold |
| 23:38.46 | Kobaz | and then i didn't realize he wasn't the decision maker... and the owner was like, no i want to stick with copper, and they just ordered like 4 additional pots lines |
| 23:46.11 | drmessano | Casper: was it enabled? |
| 23:48.01 | drmessano | You're asking me to explain an intermittent issue that you are the END USER of.. We have no logs, just some vague timelines and the provider saying "it's not us". If you had SIP ALG enabled, that's a problem. |
| 23:49.04 | drmessano | I don't have a crystal ball. I do know in 15+ years of doing this that SIP ALG on anything is generally "the suck" and especially on Ubiqiuiti and PFsense boxes. |
| 23:49.18 | drmessano | So if it was enabled, and you disabled it, that's a great start. |
| 23:50.29 | drmessano | Surely if you opened a support ticket with the provide, they have logs or dug into this somewhat. Where is that info? What did they find? |
| 23:51.29 | drmessano | Generally we troubleshoot issues here looking at BOTH sides... You're the customer ONLY here. So taking scientific wild ass guesses at known gotchas is as good as it gets. |
| 23:52.32 | drmessano | Still would like you to confirm you hadn't disabled SIP ALG before now. That's a big one. |
| 23:56.54 | Samot | Kobaz: I highly doubt they're going to get copper based lines for POTS. |
| 23:57.08 | Kobaz | well yeah |
| 23:57.19 | Kobaz | I had one customer who verizon just shut them off |
| 23:57.34 | Kobaz | by the way we are moving your copper to fiber, they never dropped in the fiber and they just shut off the copper line |