| 00:20.54 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 01:06.58 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 01:34.05 | *** join/#asterisk Iamnacho (~Iamnacho@ip68-102-131-177.ks.ok.cox.net) |
| 01:35.45 | *** join/#asterisk Champi (Champi@damn.e-leet.be) |
| 01:37.24 | *** join/#asterisk segnior (segnior@gateway/shell/xshellz/x-jahtbduextfcmhgi) |
| 02:25.42 | *** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 02:53.28 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-ldqnqjbyonimibta) |
| 02:59.33 | *** join/#asterisk tsal (~tsal@i59F5220C.versanet.de) |
| 03:01.41 | *** join/#asterisk ckb_ (~ckb@unaffiliated/ckb) |
| 03:42.39 | *** join/#asterisk electronic_eel_ (~quassel@213.240.182.98) |
| 04:13.29 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
| 04:17.14 | *** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos) |
| 04:48.57 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 05:04.33 | *** join/#asterisk waldo323__ (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 05:15.29 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 05:22.30 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 06:44.00 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 06:51.09 | *** join/#asterisk eXistenZ (~pectic@bzq-79-177-207-192.red.bezeqint.net) |
| 07:55.44 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 08:08.40 | *** join/#asterisk TulaZula (TulaZula@gateway/vpn/privateinternetaccess/tulazula) |
| 08:51.26 | *** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk) |
| 09:02.22 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 09:05.16 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 09:06.38 | *** join/#asterisk sinaowolabi (~Sina@169.159.74.124) |
| 09:08.40 | *** join/#asterisk cation21- (cation21@gateway/vpn/protonvpn/cation21) |
| 09:10.07 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 09:34.07 | *** join/#asterisk sinaowolabi (~Sina@105.112.147.95) |
| 10:05.09 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 10:51.11 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 11:28.21 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 12:07.46 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 12:28.46 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 13:26.32 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 14:06.18 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 14:08.59 | *** join/#asterisk Posterdati (~posterdat@host-79-37-129-8.retail.telecomitalia.it) |
| 14:15.43 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 14:16.16 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:35.46 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 14:42.45 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 14:45.03 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 14:48.52 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-tsurvefivjzmpqow) |
| 14:48.52 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:03.07 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 15:27.12 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:46.40 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-awavxcexxmdfcjcs) |
| 15:46.40 | *** mode/#asterisk [+o bford] by ChanServ |
| 16:09.27 | *** join/#asterisk sinaowolabi (~Sina@105.112.147.95) |
| 16:16.30 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 16:18.13 | *** join/#asterisk MLC (~MLC@63.249.40.11) |
| 16:18.38 | MLC | Seems like the QUEUEHOLDTIME variable is in seconds. Can anyone confirm or deny? |
| 16:24.39 | seanbright | confirmed |
| 16:24.43 | Samot | Yes |
| 16:24.45 | MLC | thanks |
| 16:24.52 | seanbright | i will not be taking follow ups |
| 16:25.08 | MLC | darn, I was going to ask about the meaning of life as a followup |
| 16:25.09 | Samot | Thanks sean spencer |
| 16:26.57 | Samot | Or Spicer...yeah shows how fast I forgot about him |
| 16:28.53 | *** join/#asterisk sinaowolabi (~Sina@169.159.74.124) |
| 16:38.51 | vasilakisfil | what do you think about SIP ? will it be relevant in 10 years? from what I hear it's a bit difficult to scale sip in the era of cloud.. Personally I doubt that any other protocol will manage to replace all SIP features/rfcs |
| 16:40.20 | Samot | 11:39:17 AM <Samot> What? |
| 16:40.20 | Samot | 11:39:23 AM <Samot> How is it difficult to scale? |
| 16:40.28 | Samot | From my reply in #kamailio |
| 16:42.33 | *** join/#asterisk ckb (~ckb@unaffiliated/ckb) |
| 16:45.47 | igcewieling | I think SIP beat out IAX, IAX2, MGCP, SCCP (arguably) , and H323. I'm not worried about it going away. |
| 16:46.18 | igcewieling | Personally, wish MGCP or IAX2 won the protocol wars, but SIP won. |
| 16:46.48 | *** join/#asterisk ckb_ (~ckb@unaffiliated/ckb) |
| 16:48.55 | *** part/#asterisk MLC (~MLC@63.249.40.11) |
| 16:53.55 | igcewieling | *sigh* Apparently, our Hosted platform returns a 486 when a destination is busy AND when a DID is not loaded. So, no way to tell if the call failed because someone didn't do their job and load the number or if the extension was just busy without voicemail setup. |
| 17:03.33 | *** join/#asterisk waldo323_ (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 17:31.58 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 17:39.16 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 18:04.49 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 18:24.09 | *** join/#asterisk vancz (~vancz@unaffiliated/vancz) |
| 18:25.37 | vancz | Hi folks. I know nothing about telephony internals, nor about PBX's but I had an idea and I'm wondering how feasible it is or where I could go to learn more; I know for voice calls you can get multiplexed to internal phone numbers, could you do the same with SMS? |
| 18:26.18 | vancz | Oh hm. I just realized when you do the voice multiplexing you have to dial the extension after the pbx picks up, so its just doing it at the software level using the number tones |
| 18:26.21 | vancz | :I |
| 18:27.26 | vancz | Hm, unrelatedly, how can a pbx receive multiple simultaneous calls? or is that somehow solved by using IP these days |
| 18:29.01 | Samot | It's been solved for decades and before IP |
| 18:29.14 | vancz | Ok, I wasnt sure about that |
| 18:29.50 | vancz | I was wondering if it would be possible to make a temporary sms service simlar to the email ones - getting numbers seems difficult/expensive? and I imagine phone number space is relatively limited. So I was wondering if you could have a handful of numbers and do some multiplexing with the suffix as a sort of preshared key |
| 18:32.00 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 18:41.29 | Samot | Sure if you want to build it |
| 18:41.41 | Samot | But numbers arent the issue |
| 18:45.01 | vancz | Samot: come on you cant stop there, do tell :p |
| 18:45.32 | Samot | What do you mean? |
| 18:45.40 | vancz | what *is* the issue |
| 18:45.52 | Samot | There isn't one |
| 18:46.08 | Samot | There is not issue that requires your solutuon |
| 18:46.12 | Samot | Solution |
| 18:46.26 | vancz | ok |
| 18:47.03 | Samot | There isn't a shortage of DIDs |
| 18:50.04 | *** join/#asterisk waldo323__ (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 18:52.36 | *** join/#asterisk grummund (~unknown@unaffiliated/grummund) |
| 18:53.17 | *** join/#asterisk Posterdati (~posterdat@host-79-37-129-8.retail.telecomitalia.it) |
| 18:56.26 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 19:03.48 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 19:10.49 | *** join/#asterisk aoeui (~aoeui@unaffiliated/aoeui) |
| 19:11.25 | *** join/#asterisk electronic_eel (~quassel@213.240.182.98) |
| 19:11.51 | *** join/#asterisk Ax0n (~morcant@068-113-021-065.res.spectrum.com) |
| 19:14.15 | *** join/#asterisk DerKo (ac3aae4d@172.58.174.77) |
| 19:15.20 | DerKo | hi, im trying to create a call using /var/spool/asterisk/outgoing/ that will stay active until the called party hangs up |
| 19:15.54 | seanbright | sounds good |
| 19:16.01 | seanbright | let us know if we can help |
| 19:17.13 | seanbright | calls will stay up until one party hangs up by default |
| 19:17.25 | seanbright | so if that is not happening you are doing something to cause it |
| 19:17.45 | DerKo | this is what my call file looks like |
| 19:17.46 | DerKo | https://pastebin.com/vXmPV5n0 |
| 19:18.09 | Samot | Does the call work? |
| 19:18.10 | DerKo | the extentions.conf is basically just a dial |
| 19:18.12 | DerKo | yes |
| 19:18.21 | Samot | So what is the problem? |
| 19:18.22 | DerKo | but it cancels 10 seconds after the 200 ok |
| 19:18.36 | DerKo | i would like for it to stay active a bit longer |
| 19:18.41 | Samot | OK, that could be a number of things |
| 19:18.46 | Samot | Not related to the call file. |
| 19:19.09 | DerKo | whan i make a manual call |
| 19:19.11 | DerKo | it does not happen |
| 19:19.20 | DerKo | and the cancel is initiated by asterisk |
| 19:19.37 | DerKo | so i figured is the way this outbound module works |
| 19:19.42 | DerKo | and something im doing wrong |
| 19:20.26 | Samot | Well we need to see a full debug of the outgoing call |
| 19:20.33 | Samot | asterisk -rvvvvvvvvvvvv |
| 19:20.40 | Samot | sip set debug on |
| 19:20.45 | Samot | then trigger the callfile |
| 19:21.42 | DerKo | doing it |
| 19:24.33 | DerKo | https://pastebin.com/bjKsphgt |
| 19:29.39 | igcewieling | [Feb 4 19:23:05] WARNING[2462][C-000021a5]: pbx.c:4510 __ast_pbx_run: Channel 'SIP/10.116.248.205:5160-000026b3' sent to invalid extension but no invalid handler: context,exten,priority=other,3000,1 |
| 19:32.25 | seanbright | yup |
| 19:32.36 | seanbright | the WARNING was a dead giveaway |
| 19:45.00 | vancz | www.ozekisms.com/p_2547-ozeki-1.4-sms-number-formats.html#1.4.5 "Long code means that the telephone number is longer than the standard phone number length in the network. e.g.: +36201234567111111In this case, a freely defined postfix is appended to the phone number itself. This feature is available in some networks only. It is very useful because the postfix part of the telephone number can by used to carry a unique message id, that can be used by |
| 19:45.00 | vancz | applications. [..] Long code numbers are only available on IP SMS connections (such as SMPP, UCP, CIMD2). The GSM modem technology does not permit this. If you use a GSM modem, you can only receive messages on the appropriate MSISDN number." |
| 19:46.02 | Samot | What? |
| 20:06.28 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 20:12.07 | igcewieling | vancz: that is not supported in the USA or Canada |
| 20:13.00 | igcewieling | Something which sounds identical has been available in at least Germany on PRIs for at least a decade. |
| 20:18.42 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 20:32.26 | Kobaz | sooooooo |
| 20:33.26 | Kobaz | in pjsip, is there a way to try and match an endpoint if an identify matches but doesn't pass? |
| 20:34.21 | Kobaz | Ie: I have an endpoint configured in pjsip-wizard called say.. '205', and i just so happen to have an identify that matches the ip address that a REGISTER is coming from... but does not match the auth associated |
| 20:35.31 | Kobaz | so for example... https://dpaste.com/CMSM89722 |
| 20:35.57 | Kobaz | so.. yes is-bob-main-identify does match the ip address in question.. but there is a *better* match, that accepts registrations |
| 20:39.30 | Kobaz | which is this one: https://dpaste.com/8MLTM6LVV |
| 20:45.41 | Kobaz | my issue is... from the log: this REGISTER should be matching the type=wizard endpoint. not those other identifies |
| 20:46.04 | Samot | Where is that ebdpoint associated with the identity? |
| 20:46.33 | Kobaz | It's not |
| 20:46.33 | Samot | And is that endpoints being told to check that vs user/ip |
| 20:47.08 | Samot | There is an author order |
| 20:47.17 | Samot | Auth |
| 20:47.22 | Kobaz | ah |
| 20:47.37 | Kobaz | is-bob-main is another endpoint wizard |
| 20:47.37 | Samot | User/IP is default |
| 20:47.43 | Kobaz | with remote hosts |
| 20:47.56 | Kobaz | okay... i have my chan_sip set up for auth_name_match |
| 20:48.04 | Kobaz | so it prioritizes endpoint names that match, and THEN ips |
| 20:48.11 | Kobaz | but pjsip is.... doing... not sure what |
| 20:48.35 | igcewieling | it does what endpoint_idenfity_order is set to, IIRC |
| 20:48.43 | Samot | Correct |
| 20:48.53 | Samot | User/IP is default |
| 20:48.59 | Kobaz | k |
| 20:48.59 | Kobaz | cool |
| 20:49.03 | Samot | That is checked first |
| 20:49.18 | Kobaz | endpoint_idenfity_order is... global? |
| 20:49.24 | Kobaz | let me look that up |
| 20:49.25 | igcewieling | Kobaz: I ran into something similar yesterday. |
| 20:49.39 | Samot | No |
| 20:49.45 | Samot | It is per endpoint |
| 20:50.36 | igcewieling | I set up an [anonymous] endpoint to catch bots. But one of my peers, one with a static IP send some calls to me from anonymous and it matched the anonymous endpoint instead of the correct one. Since I don't care that much about messing with bots, I remove the anonymous endpoint. |
| 20:51.16 | Kobaz | right |
| 20:51.24 | Kobaz | since names, can cause issues like that |
| 20:51.50 | Kobaz | i had that exact issue because i had say a peer in chan_sip called '101' |
| 20:51.55 | igcewieling | Kobaz: it was sending "anonymous" on calls without callerid blocked. evil. |
| 20:52.23 | Kobaz | And then, a pbx we were integrating with, was sending '101 as a callerid for transferred calls, like a blind transfer from the real 101 |
| 20:52.28 | Kobaz | and then it was failing auth |
| 20:52.43 | igcewieling | Kobaz: the main reason I switched to pjsip to get away from chan_sip's incredibly confusing matching/auth. pjsip might be more complicated, but it makes sense, most of the time. |
| 20:53.16 | Kobaz | since the call from '101 was coming over a trunk from a pbx, it should always auth |
| 20:53.36 | Kobaz | but my issue i ran into with the match name first, was... blind transfers set the From: and then causes it to fail auth |
| 20:53.36 | Samot | Nope |
| 20:53.49 | Samot | The first peer to match wins |
| 20:54.04 | Samot | If 101 exist s before the trunk, it wins |
| 20:54.11 | Kobaz | yeah |
| 20:54.29 | igcewieling | I'm got it easy, 163 of my 164 endpoints have static IPs and auth by ip. |
| 20:54.43 | igcewieling | at least one one server. |
| 21:06.38 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 21:27.57 | *** join/#asterisk tsal (~tsal@i59F5220C.versanet.de) |
| 21:33.41 | vancz | igcewieling: hm. thats a shame because the cheapest numbers seem to be in the us :I |
| 21:52.03 | vancz | igcewieling: can you give any pointers on what you said? "long code" seems to be sufficiently overloaded that im having trouble looking into it |
| 21:53.17 | igcewieling | vancz: it isn't a standard thing. Almost no country supports tacking on random digits to phone numbers to create pseudo-DIDs. |
| 21:53.40 | igcewieling | Countries are moving away from variable length dialing, not towards it. |
| 21:54.03 | vancz | mmmm -_- |
| 21:59.56 | igcewieling | You can dial all the extra digits you want, the usa telecos will only accept the expected number of digits. |
| 22:16.56 | *** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:21e7:a7ed:6184:3cb7) |
| 22:17.31 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 22:21.39 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |