| 00:13.29 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-coznycculjvuzayx) |
| 00:26.19 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 00:32.29 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 00:36.34 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 01:00.35 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 01:04.23 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 01:10.36 | *** join/#asterisk ShellyRoll (~ShellyRol@c-67-170-30-252.hsd1.wa.comcast.net) |
| 01:17.17 | *** join/#asterisk anthm (~anthm@freeswitch/developer/anthm) |
| 01:20.54 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 02:03.51 | *** join/#asterisk MICROburst1 (~Thunderbi@x4e366565.dyn.telefonica.de) |
| 02:15.25 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 02:19.39 | *** join/#asterisk FuriousGeorge (477d5f7d@pool-71-125-95-125.nwrknj.east.verizon.net) |
| 02:19.43 | FuriousGeorge | hey all |
| 02:20.36 | FuriousGeorge | im trying to set up a new provider with my pbx. i have udpbindport set to 5080, but inbound calling fails, according to the provider, because my contact header is indicating the communication should be on 5060 |
| 02:21.11 | FuriousGeorge | i can't think of what setting to change in order to make it work. all the phones are registered on 5080 without prloblems, and i'd rather not use 5060 anyway |
| 02:23.31 | FuriousGeorge | i just set externaddr to {IP}:5080 |
| 02:24.25 | FuriousGeorge | no change |
| 02:36.48 | FuriousGeorge | checking my sip dump, i see: |
| 02:36.58 | FuriousGeorge | Contact: <sip:19737184766@104.196.159.99:5080> That looks correct to me |
| 02:37.10 | FuriousGeorge | I'm assuming that's the contact header he's referring to. |
| 02:45.06 | Samot | Do you see the call hit Asterisk? |
| 02:59.47 | *** join/#asterisk ketas (~ketas@0011-0000-0000-0000-d7dc-830e-07d0-2001.dyn.estpak.ee) |
| 03:03.09 | *** join/#asterisk jkroon (~jkroon@165.16.203.110) |
| 03:06.46 | FuriousGeorge | Samot: no... i think the problem is with my provider |
| 03:07.08 | FuriousGeorge | i added the port to the route i defined in their backend, and it briefly worked. their support is helping me. |
| 03:07.54 | Samot | Yeah, if you're not registering to them and they are just routing the calls by host/IP then you need to define the port you're listing on. |
| 03:08.17 | Samot | Otherwise RFC states us 5060 |
| 03:08.24 | Samot | s/us/use/ |
| 03:09.55 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 03:11.25 | FuriousGeorge | i am registering to them. i believe they want me to define an inbound route anyway... maybe it's not needed if I'm registering and removing it will solve the problem... |
| 03:15.41 | Samot | Yes. It has to be either or. |
| 03:16.00 | Samot | Unless they are routing the calls to both locations at once or in a sequence like failover. |
| 03:16.18 | Samot | Otherwise, they either route based on the registration location or the static location you give them. |
| 03:17.05 | FuriousGeorge | hey, that worked |
| 03:17.16 | FuriousGeorge | thx samot |
| 04:04.30 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 04:43.29 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 04:59.04 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 05:02.25 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 05:27.58 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 05:33.29 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:53.20 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:107f:3d7:ea8d:2b51) |
| 05:56.40 | *** join/#asterisk ganbold_ (~ganbold@66.85.186.234) |
| 06:26.54 | *** join/#asterisk somepoortech (~somepoort@72-12-70-165.static.firstlight.net) |
| 06:37.34 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 08:12.07 | *** join/#asterisk eXistenZ (~pectic@bzq-79-176-214-199.red.bezeqint.net) |
| 11:22.55 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 11:44.09 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 11:44.50 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 13:09.04 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 13:35.21 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 14:03.04 | davlefou | Hi, i have some registeur call and i want to compress and copie at the end of each call. How can i launch script a the each end? |
| 14:07.07 | Samot | What? |
| 14:10.32 | davlefou | I need to launch an agi a the end of each call. |
| 14:14.07 | Samot | OK. |
| 14:18.35 | davlefou | Is it okay with h exten? |
| 14:21.08 | Samot | Sure. |
| 14:25.52 | davlefou | I try. |
| 15:17.54 | electronic_eel | davlefou: another way would be to use a script which constantly reads (tails) the cel logs and acts upon special log entries in there |
| 15:18.34 | electronic_eel | I do some stuff post-call and do it that way. It is nicely decoupled from asterisk that way. |
| 15:19.58 | electronic_eel | I write the cel logs as json-per-line (cel-custom) and use a python program with parsible to parse it |
| 15:31.43 | *** join/#asterisk FuriousGeorge (477d5f7d@pool-71-125-95-125.nwrknj.east.verizon.net) |
| 15:31.47 | FuriousGeorge | hi all |
| 15:31.54 | FuriousGeorge | i have a new provider i registered a did with |
| 15:32.22 | FuriousGeorge | the did will work sporadically, but most of the time asterisk rejects the invite on an incoming call with "FORBIDDEN" |
| 15:32.26 | FuriousGeorge | <PROTECTED> |
| 15:32.40 | FuriousGeorge | actually Unauthorized |
| 15:34.01 | FuriousGeorge | I'm also seeing SIP/2.0 404 Not Found |
| 15:34.10 | FuriousGeorge | this is from a tcpdump |
| 15:41.00 | FuriousGeorge | here is what it looks like in sip debug |
| 15:41.30 | FuriousGeorge | https://paste.ubuntu.com/p/NqP7R2nb6H/ |
| 15:41.43 | FuriousGeorge | you can see the call come in, and asterisk respond with 401 Unauthorized... i have no idea why |
| 15:42.47 | Samot | Because you're telling it to. |
| 15:43.22 | Samot | No matching peer for '+12126179898' from '147.75.65.192:5060' <-- Plus there is that. |
| 15:46.31 | FuriousGeorge | Samot: sometimes it works, and sometimes it doesn't. i can't imagine where i'm telling it to do that. sip show registry and sip show peers indicate everything is fine in that respect |
| 15:46.53 | Samot | Show the peer. |
| 15:46.55 | FuriousGeorge | that no matching peer is the source number |
| 15:47.02 | Samot | Because they are sending you a call from another IP it looks like. |
| 15:47.14 | Samot | No. |
| 15:47.26 | Samot | The no matching peer means there isn't a matching peer for the IP |
| 15:48.37 | Samot | Oh this is flowroute. Yeah, you shouldn't be using Chan_SIP for this at all. |
| 15:48.39 | FuriousGeorge | Samot: https://paste.debian.net/1127539/ |
| 15:48.56 | FuriousGeorge | ugh, i've never used pjsip |
| 15:49.08 | Samot | The you need to go and get all the IPs for us-east-nj.sip.flowroute.com |
| 15:49.15 | FuriousGeorge | i have those |
| 15:49.28 | FuriousGeorge | where should i whitelist them tho? |
| 15:49.31 | Samot | OK now, you need to make a chan_SIP trunk for each of them. |
| 15:49.59 | FuriousGeorge | could you restate that? does that mean i need a peer per IP? |
| 15:50.47 | *** join/#asterisk ganbold_ (~ganbold@66.85.186.234) |
| 15:51.00 | Samot | Yes. |
| 15:51.15 | Samot | Because Chan_SIP only knows one IP/host. |
| 15:51.52 | FuriousGeorge | so i set up [flowroute0], [flowroute1], using the same credentials for each... and then somewhere in there i specify the IP address for each one? |
| 15:52.16 | Samot | It would be the host= |
| 15:53.35 | FuriousGeorge | Samot: sounds like i can copy my current flowroute peer, and just add the host= line to each one |
| 15:54.00 | Samot | Sure. You can try that. |
| 15:54.13 | Samot | Why you want to make over 18 peers for one provider is beyond me. |
| 15:55.14 | Samot | Sorry more like close to 30 |
| 15:55.31 | Samot | 147.75.65.192/28, 147.75.65.192-147.75.65.207 <-- Those are the IPs for your PoP with them. |
| 15:55.54 | *** join/#asterisk ganbold (~ganbold@66.85.186.234) |
| 15:55.56 | Samot | A /28 is 16 IPs. The only is a range of 13 IPs. |
| 15:56.08 | Samot | So 29 IPs can deliver you calls. |
| 15:56.42 | Samot | No you can have all those Chan_SIP peers or you can have one PJSIP endpoint. |
| 15:56.56 | Samot | Now* |
| 16:00.06 | FuriousGeorge | i may switch to pjsip |
| 16:00.19 | FuriousGeorge | i added all the peers, and only about 4 became reachable |
| 16:00.44 | Samot | You probably should. Chan_SIP has maybe 3 years left on it at worse. |
| 16:01.02 | Samot | It's marked for removal and can be removed after 2023. |
| 16:02.03 | FuriousGeorge | this may be good enough for now, while i start reading up on pjsip |
| 16:02.24 | FuriousGeorge | inbound calling is working, but idk for sure how reliably, given all the unreachable peers |
| 16:03.26 | Samot | Well that just means Asterisk isn't get a response back from them. |
| 16:03.45 | Samot | But then again, I'm not sure they want 20+ peers from the same source qualifying against them. |
| 16:04.33 | FuriousGeorge | could be, i set a failover route to the managers phone... they are open now, which limits how much troubleshooting i can do |
| 16:05.32 | sibiria | waste no time moving to pjsip, is my advice :) |
| 16:05.53 | sibiria | it's a bit confusing in the start compared to chan_sip, but the pjsip wizard helps a lot |
| 16:06.34 | FuriousGeorge | im reading up on it now |
| 16:06.57 | FuriousGeorge | doesn't seem like i have much of a choice in the long run, or maybe in the short run either |
| 16:09.16 | FuriousGeorge | wpw that's confusing https://wiki.asterisk.org/wiki/display/AST/Migrating+from+chan_sip+to+res_pjsip |
| 16:09.30 | Samot | Chan_SIP was moved from Extended (Community) to Deprecated in Oct 2019. |
| 16:09.57 | drmessano | chan_sip literally can't handle the way modern peers are configured |
| 16:10.37 | drmessano | Flowroute being a great example of a provider that went from stuffing everything into two IP addresses to moving to POPs where many IPs were involved |
| 16:10.39 | FuriousGeorge | it is what it is... gotta evolve... but why the heck do they need to specify [mytrunk] 5 times! |
| 16:11.07 | file | because it configures specific portions |
| 16:11.19 | file | you should watch my Astricon presentation |
| 16:11.59 | file | https://www.youtube.com/watch?v=wCOa04g1c7w&feature=youtu.be |
| 16:12.16 | *** join/#asterisk sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 16:12.35 | FuriousGeorge | The fantastical world of PJSIP and Asterisk ... |
| 16:12.59 | Samot | The next few years is going to be make or break time for a lot of people. |
| 16:13.30 | FuriousGeorge | Samot: what people are you referring to? asterisk admins or sip trunk providers? |
| 16:13.40 | Samot | The new laws and regulations, the changes from how ITSPs are doing their interconnects, Asterisk changes.... |
| 16:13.53 | FuriousGeorge | file, thanks i will watch. hopefully it will explain to me about the 5 portions of a sip trunk that must be defined |
| 16:14.00 | Samot | FuriousGeorge: Yes. |
| 16:14.08 | Samot | I'm talking about both. Things impact both. |
| 16:14.28 | *** join/#asterisk cp- (~cp-@b157153.ppp.asahi-net.or.jp) |
| 16:15.04 | Samot | See here is the thing about Asterisk and the new laws/regulations. |
| 16:15.16 | Samot | Asterisk is _not a PBX_, it's a toolkit. |
| 16:15.33 | Samot | Therefore, Sangoma/Digium, doesn't really need to do much for these new things. |
| 16:15.51 | sibiria | realistically i think chan_sip will be with Asterisk for another 5 years at least |
| 16:16.06 | Samot | FreePBX, on the other hands, is a PBX and thus Sangoma has to do some things for their installers/users. |
| 16:16.16 | sibiria | but i'm sure there's a plan to stop not just crucial bug fixes for it, but also security fixes |
| 16:16.24 | Samot | sibiria: I think it will be gone by v20 |
| 16:16.48 | sibiria | maybe seanbright can hold a neutral and unpartial betting pool for us |
| 16:16.59 | sibiria | no aces in any sleeves!1 |
| 16:17.26 | Samot | FuriousGeorge: But come Feb 16th this year, you could be installing PBX systems illegally if you aren't aware of the new lays. |
| 16:17.27 | sibiria | impartial* is the correct word |
| 16:17.39 | Samot | laws* |
| 16:20.24 | seanbright | wait, what will be gone by v20? |
| 16:20.28 | FuriousGeorge | Samot: what? like CID spoofing? this is the first im hearing of it |
| 16:20.37 | seanbright | chan_sip? i doubt it |
| 16:21.19 | Samot | The new 911 laws. |
| 16:21.32 | sibiria | what are the new 911 laws in the USA? |
| 16:21.39 | Samot | And yes, the new CallerID laws |
| 16:21.59 | FuriousGeorge | Samot: it's not enough to register your address with your DiD at the provider anymore? |
| 16:22.02 | Samot | sibiria: its a couple things. |
| 16:22.14 | Samot | 1. No prefixes for 911 |
| 16:22.53 | Samot | 2. DID presented to 911 for call back must ne routable and answered by someone |
| 16:23.12 | seanbright | i don't know what sangoma's plans for chan_sip are but if you go based on what you see on the issue tracker and code reviews - the plan is basically indifference (and i think that is a good thing) |
| 16:23.34 | Samot | 3. Dispatchable locations down to the floor/room has to be presented per phone |
| 16:24.13 | Samot | 4. New systems made available after feb16 must support alerts as well. |
| 16:24.27 | drmessano | sibiria: chan_sip can hang around for 5 years.. but time and time again, some provider moves to having more than 1 IP per POP, because it's not 2005, and chan_sip becomes impractical |
| 16:24.41 | FuriousGeorge | 1. is easy enough to implement with asterisk... 2. what is meant by routeable there? |
| 16:24.46 | FuriousGeorge | drmessano: as im finding now |
| 16:24.54 | Samot | Old systems need to support it if a minir update or nonmajor update fixes it |
| 16:25.17 | drmessano | So chan_sip is now becoming obsolete on the wire as well as being unsupported |
| 16:25.32 | sibiria | the EU is also on its way implementing a lot of new restrictions for systems acting out on the PSTN |
| 16:25.37 | file | seanbright: effectively - although in the case of critical regressions we usually get involved, I'm half tempted to just take a "revert, reopen original issue, push back on committer" approach on that tbh |
| 16:25.42 | seanbright | community supported <> unsupported |
| 16:25.43 | FuriousGeorge | 3. I notice that flowroute did ask me for the floor when i registered 911.... 4. alerts? |
| 16:25.53 | seanbright | but when no one from the community gives a shit either, it's effectively the same |
| 16:26.29 | Samot | FuriousGeorge: If you have a school with 75 rooms and two floors, each phone in the school must present their exact location in the building to 911. |
| 16:27.00 | Samot | That can be done with buying a DID per phone or finding a provider that supports Dynamic Location Routing. |
| 16:27.41 | sibiria | the EU's first move was to make it economically unfeasible with spoofing: it still allows "blind" caller IDs that don't connect to anything, or are even registered real numbers/VLNs, but operators are now burdened with being charged _a lot_ for routing those calls, and SIP trunk providers have to pass those termination charges on |
| 16:27.56 | sibiria | the price differences are up towards 10-20x the usual fees |
| 16:28.13 | Samot | Oh that's STIR/SHAKEN here. |
| 16:28.27 | Samot | Where the CallerID must be in a valid NANP/International format. |
| 16:28.29 | sibiria | and that's just the first move. more regulations will come |
| 16:28.49 | Samot | The carriers will start validating your calls for proper CallerID |
| 16:28.50 | seanbright | file: well i hope my MESSAGE fix doesn't end up breaking anything then |
| 16:29.05 | file | seanbright: are you feeling lucky? |
| 16:29.14 | FuriousGeorge | Samot: im reading about Kari's law. when you mention 4. alerts... that would be the notifications part? |
| 16:29.25 | Samot | Yes. |
| 16:29.30 | Samot | That would be notifications. |
| 16:29.35 | Samot | Alerting you that a 911 call was made. |
| 16:30.34 | Samot | sibiria: Like I said, Asterisk is NOT a PBX. Therefore Sangoma doesn't have to rely any of this information for the new laws to users. |
| 16:31.05 | Samot | However vendors like Mitel, Avaya, PhoneSuite, FreePBX, etc. should be informing their agents/installers of this new process. |
| 16:32.26 | Samot | Because now the hammer can come down on the installer/admin of the PBX if things are screwed up. |
| 16:32.42 | Samot | There is going to be actual accountability for this. |
| 16:32.54 | *** join/#asterisk deavmi (~quassel@41.164.64.226) |
| 16:32.57 | FuriousGeorge | in terms of the location information, couldn't providers parse the sip headers, get the calling extension, and pass that along? the burden would be on the installer to register every extension with the correct location |
| 16:33.36 | FuriousGeorge | for instrance, i just got a did from flowroute, they asked me for the floor when setting up 911, but the location has a basement with a couple of phones as well |
| 16:33.52 | Samot | No. |
| 16:33.55 | FuriousGeorge | so a 911 call from the basement would still show up 1st floor\ |
| 16:34.12 | Samot | Because not everyone is on SIP. |
| 16:34.42 | FuriousGeorge | so how the heck does that work, unless you get a did per extension? |
| 16:34.44 | Samot | FuriousGeorge: So you either need a DID for each of those phones so you can register a location with Flowroute OR you need a 911 provider that supports Dynamic Location Routing. |
| 16:35.10 | FuriousGeorge | who is my 911 provider? is it not flowroute in this case? |
| 16:35.33 | drmessano | That was the first part of the OR |
| 16:35.56 | drmessano | This is what I love about 2020 |
| 16:36.07 | Samot | Look, it's simple. The days of throwing in an Asterisk/FreePBX box and slapping a Flowroute trunk on it and calling it a day is over. |
| 16:36.50 | FuriousGeorge | What are the Benefits of Dynamic Location Routing |
| 16:36.55 | FuriousGeorge | what about cordless phones? |
| 16:37.02 | Samot | Because I can have 1 DID and 100 locations associated to it. |
| 16:37.20 | Samot | And using SIP headers I can push the proper location out. |
| 16:37.38 | *** join/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 16:37.54 | Samot | A cordless phone as a station. Where is that station? |
| 16:37.57 | drmessano | A cordless phone usually has a base station |
| 16:38.00 | Samot | Wherever that station is, that's the location. |
| 16:38.03 | drmessano | Come on |
| 16:38.10 | FuriousGeorge | true, and you usually can't go to far from it |
| 16:38.32 | FuriousGeorge | but sometime you can go a floor up and a room over, and it still works |
| 16:38.40 | Samot | Hotels, Schools, Campuses, Medical, Wharehouses... |
| 16:38.43 | drmessano | I was waiting for that |
| 16:38.59 | Samot | Those all automatically qualify as needing Dispatchable Locations for them. |
| 16:39.26 | FuriousGeorge | ok, in any case, now the phone or the pbx has to know about location object headers... presumably this comes with updates |
| 16:39.39 | Samot | FuriousGeorge: Those days are over. The FCC gave states the chance to deal with this. They didn't, they stepped in. |
| 16:39.53 | drmessano | FuriousGeorge: You do realize they are efforting to get a reasonable, narrowed down location for the call.. they're not looking for a certification that the call isn't coming from one office over |
| 16:40.28 | FuriousGeorge | drmessano: i realize that. you can usually use a cordless phone an entire floor away, but fair enough |
| 16:40.39 | Samot | This also makes POTS line invalid for these setups. |
| 16:41.13 | Samot | Which means you can no longer have 4 POTS lines in your PBX for a hotel or a school.. |
| 16:41.25 | Samot | Because they can't support having multiple CallerIDs pushed over them. |
| 16:41.48 | Samot | Your options will be SIP/T1/PRI |
| 16:43.13 | Samot | FuriousGeorge: But let's make this simple. If you install a PBX after Feb 16th 2020 and something goes wrong with 911 for any reason. Wrong address, no address, failed call backs, etc. YOU are now LEGALLY responsible for that. |
| 16:43.34 | drmessano | But lets also be clear |
| 16:43.53 | Samot | You can be fined, you could be criminally held responsible if someone dies. |
| 16:43.59 | drmessano | If you call 911 on a cordless and walk outside, changing your location, you're not going to prison |
| 16:44.01 | Samot | Which, by the way, is why all this happened anyways. |
| 16:44.08 | FuriousGeorge | Samot: yeah, i had deduced that part. i don't have any hotels, schools, or hospitals as clients. i have a warehouse but i don't think it's big enough to apply |
| 16:44.16 | Samot | Yes, it is. |
| 16:44.27 | Samot | Wharehouse are specially listed. |
| 16:44.49 | FuriousGeorge | all the phones are in the office, so a call can't come from anywhere else |
| 16:45.01 | Samot | Then you're fine. |
| 16:45.08 | FuriousGeorge | they have a pa system, but thats just one way audio from phone to warehouse, and so you can't call 911 from it anyway |
| 16:45.14 | Samot | Where ever this is a _phone_ it must be able to dial 911 |
| 16:45.23 | Samot | And have dispatchable location. |
| 16:46.15 | FuriousGeorge | where does one who isn't on irc go for this information? my state has no continuing education requirement for MLTS insrtallation |
| 16:46.38 | Samot | Right, this is why the FCC stepped in. |
| 16:47.13 | Samot | Only about half the states actually did something and even then some aren't as strict or enforced that hard. |
| 16:47.26 | FuriousGeorge | so is there a ferderal continuing education program for MLTS installers? my concern is that Feb is not far away, and I imagine a large percentage of ppl have no idea |
| 16:47.45 | Samot | FuriousGeorge: The FCC released information about this last year. Numerous providers have been posted blogs/FAQs on it. |
| 16:48.21 | Samot | Again, PBX vendors like Mitel, etc are educating their agents/installers. |
| 16:48.27 | Samot | Asterisk IS NOT A PBX. |
| 16:49.05 | FuriousGeorge | asterisk, being a b2bua will need to support dynamic location information itself, no? presumably in chan_pjsip, chan_iax, etc |
| 16:49.10 | Samot | Sangoma has no obligation to update Asterisk users about this. Because there is nothing that states Asterisk is an MLTS system. |
| 16:49.35 | Samot | I can have an Asterisk system for voicemail only |
| 16:49.35 | FuriousGeorge | right, you can use it as an intercom system with no outbound calling, as i have before |
| 16:49.40 | Samot | ConfBridge's only. |
| 16:49.55 | Samot | Asterisk becomes a PBX when programmed that way. |
| 16:50.28 | Samot | So someone like FreePBX or VitalPBX, they have an obligation to update their users/installers. |
| 16:50.56 | electronic_eel | how does this dynamic location routing thing work on the sip level? (I'm from Germany, we don't have anything similar here) |
| 16:51.13 | Samot | FuriousGeorge: This is actually an important question. Who do your end users pay for the VoIP service? Do they pay Flowroute directly or do they pay you? |
| 16:52.04 | FuriousGeorge | depends on the user (and it may not be flowroute, as I just started using it), but presumably if i resell minutes i incur more liability. is that where you're going? |
| 16:52.37 | Samot | Well if you resale the service then you fall under a Provider. |
| 16:52.50 | Samot | As well as an installer. |
| 16:54.01 | Samot | electronic_eel: I explained it already. There will be certain SIP headers used. |
| 16:54.50 | electronic_eel | ok, extra sip header. Are these headers standardized across sip carriers or does everyone have it's own proprietary stuff? |
| 16:55.26 | Samot | It will be based on the provider. |
| 16:55.32 | Samot | Since the information is between you and them. |
| 16:56.49 | electronic_eel | I hate it. Why can't they come up with a common protocol for stuff like that? |
| 16:57.07 | Samot | Uhm, SIP is the protocol. |
| 16:57.41 | electronic_eel | yes, but the dynamic location thing is a protocol extension. Like PAI and so on |
| 16:57.51 | Samot | It's also not uncommon for a provider to have custom headers or support custom headers for their users. |
| 16:57.57 | Samot | Right. |
| 16:58.11 | Samot | So you can send it in whatever header you'd like because SIP allows you to add them. |
| 16:58.37 | Samot | See between me and my users, they have to send me the station's CallerID, that's it. |
| 16:59.01 | Samot | Then I tag them with their DLR headers for the 911 provider. |
| 17:00.41 | electronic_eel | but how these dlr headers are called and how they are formatted changes with the carrier used. So you have to implement formatting code for each provider |
| 17:01.00 | Samot | Yes. |
| 17:01.19 | Samot | But I don't have multiple 911 providers. |
| 17:01.28 | electronic_eel | and if you are a pbx vendor, you either need to have a dropdown with all supported carriers, or you need some dynamic scripting language to allow the individual formatting |
| 17:01.41 | Samot | I have a single 911 with multiple geo-redundant pops. |
| 17:02.12 | Samot | Well let's look at it this way. |
| 17:02.18 | electronic_eel | that makes it way more complicated than if there'd be one common DLR protocol extension for all providers |
| 17:02.26 | Samot | If you're using a T1 or PRI, then DLR isn't a solution for you. |
| 17:02.37 | Samot | Because they are not SIP. |
| 17:02.50 | Samot | So you must do the traditional thing and have DIDs for your 911 locations. |
| 17:03.48 | Samot | Many US Telecom's follow the T1/PRI traditions for SIP Trunks. They still channelize it and they still give a bucket of DIDs. |
| 17:04.05 | electronic_eel | don't know about the US, but here in Germany at least Deutsche Telekom will disconnect the last PRIs and BRIs this year. Most are already migrated |
| 17:04.10 | Samot | Your Flowroute, Twilio, VoIP.MS, etc. are pure SIP and just give you a connection. |
| 17:04.53 | Samot | electronic_eel: Most PRI's in the US are only PRI to the PBX at this point. |
| 17:05.09 | Samot | It's 100% SIP to the CPE that converts it to PRI to handoff to the PBX. |
| 17:05.43 | electronic_eel | but will they keep offering them? Isn't it quite costly to still support the equipment? |
| 17:06.03 | Samot | Yes because people still have PRI PBX systems. |
| 17:06.12 | Samot | There are modern PBX systems that use PRI handoffs. |
| 17:06.29 | electronic_eel | the main motivation for the Telcos here was that Nokia Siemens discontinued support for the old exchanges that offered PRI and BRI |
| 17:06.36 | Samot | Plus a PRI also has the SLA/MTTR that a normal SIP trunk doesn't. |
| 17:06.48 | Samot | You're not following me. |
| 17:06.57 | Samot | If I install a "PRI Trunk" tomorrow... |
| 17:07.15 | Samot | It's a 100% SIP until it hits my gateway their PBX connects to. |
| 17:07.23 | Samot | Then it converts it to PRI and vice versa. |
| 17:07.50 | Samot | There's no copper. There's no SmartJack. |
| 17:08.07 | joepublic | aluminum? |
| 17:08.37 | electronic_eel | ah, so it's sip to the customer and at the customer site there is some converter box |
| 17:08.46 | Samot | T1/PRI these days is more about the handoff and the service level provided. Not the actual infrastructure. |
| 17:09.08 | electronic_eel | yeah, we have these here too and whenever I see such a thing I try to replace it with pure SIP as fast as possible |
| 17:09.19 | Samot | Yes. Cable companies offer PRIs and their 100% coax. |
| 17:09.28 | Samot | So it's SIP to their gateway. |
| 17:10.07 | Samot | electronic_eel: That is great if the PBX supports SIP. Not all do or they require additional hardware for it. |
| 17:10.40 | Samot | Right now I have around 55 customers with old analog PBX systems and using FXS handoffs. |
| 17:10.56 | electronic_eel | if they don't support sip then they are usually >10 years old and about to be replaced |
| 17:11.12 | Samot | These new laws now require them to either put in a PRI card or a SIP card (if it supports it) |
| 17:11.35 | Samot | Well the US is a bit more lax on things than the EU honestly. |
| 17:11.49 | Samot | Our PSTN infrastructure is a rats nest of a nightmare. |
| 17:11.59 | Samot | Because it's the oldest in the world. |
| 17:12.30 | Samot | So a lot of people are still using PBX's from the 70's or 80's. |
| 17:12.42 | Samot | Or 15+ years old. |
| 17:13.06 | Samot | I have a subset of customers who's PBX systems don't support an external CallerID per extension. |
| 17:13.32 | Samot | Which means regardless of PRI or SIP, the PBX can't send an external call with a per phone CallerID. |
| 17:13.38 | electronic_eel | yeah, but can you still get upgrades or spare parts for stuff that old? |
| 17:13.50 | Samot | Sure, if you want to spend $15K |
| 17:14.13 | Samot | Mitel still supports these old PBXes with spare hardware but it's priced out of the world. |
| 17:14.18 | electronic_eel | are the companies that made that stuff in the 80ies still around? |
| 17:14.24 | Samot | Even they are trying to foce them to upgrade. |
| 17:16.29 | electronic_eel | hmm, I thought company executives in the US are more of the pragmatic type and more willing to throw out old stuff than invest a lot into fixing old stuff |
| 17:16.57 | Samot | It's not like they are making things for these old PBX systems. |
| 17:17.05 | Samot | At some point they did have stock to support them. |
| 17:18.53 | drmessano | I remember 8 years ago or so I had an NEC PBX... Our contract guy comes out to do some work |
| 17:19.02 | drmessano | I mention I was going to set up a SIP PBX soon |
| 17:19.17 | drmessano | "Oh I can slap a SIP card in that thing that will do whatever you want" |
| 17:19.30 | drmessano | Slapping a SIP card in |
| 17:19.47 | FuriousGeorge | samot: so practically speaking, the provider has to support dynamic location, and you implement it at the asterisk level with a sipaddheader, with that header following the provider's understood format |
| 17:19.47 | drmessano | I hope those guys all go extinct soon |
| 17:20.50 | Samot | FuriousGeorge: Correct. |
| 17:23.35 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 17:24.26 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 17:31.44 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:8dd0:1128:3595:13bf) |
| 17:42.36 | Samot | drmessano: Kill me now. |
| 17:43.19 | Samot | drmessano: Someone is having voice issues on their LAN, they want me to help figure it out. They have at least FOUR VLANs for voice traffic because....no good reason. |
| 17:44.49 | Samot | Then they were trying to apply QoS rules _per_ protocol and PORTS the phones/PBX use. |
| 17:58.46 | drmessano | LOL wow |
| 18:01.51 | Samot | Yeah, they are making some changes so I guess I'll see what happens. |
| 18:02.07 | Samot | They are using HP switches and SonicWall...so yay! |
| 18:18.55 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:8dd0:1128:3595:13bf) |
| 18:34.18 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 18:44.52 | *** join/#asterisk paulgrmn (~paulgrmn@c-68-34-113-42.hsd1.mi.comcast.net) |
| 18:47.18 | davlefou | electronic_eel, did you have an sample? I use cdr actualy, is it possible? |
| 18:49.28 | davlefou | electronic_eel, you give me an good idea! |
| 19:11.19 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:101f:3d60:61d0:ea5e:c968:d111) |
| 19:41.18 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 20:08.20 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 20:09.38 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 20:41.55 | *** join/#asterisk miralin (~Thunderbi@host-77-39-76-46.stavropol.ru) |
| 20:51.52 | electronic_eel | davlefou: I haven't looked at cdr much, used cel from the beginning. I don't have code I can share. But take a look at parsible, you can hook your parser right in and trigger with it what you want |
| 20:54.23 | electronic_eel | a pattern I often use with this setup is to write a custom cel event from dialplan like this: CELGenUserEvent(MISSED,Remote hangup) |
| 20:54.54 | electronic_eel | the parsing script detects this and acts upon. in this example it adds a call to the server-side missed calls list |
| 21:37.45 | *** join/#asterisk miralin (~Thunderbi@host-77-39-76-46.stavropol.ru) |
| 21:48.30 | *** join/#asterisk Ai9zO5AP (~BQcdf9eiZ@37.120.203.83) |
| 22:06.23 | *** join/#asterisk lankanmon (~LKNnet@CPEb4fbe4e331bd-CM64777d632380.cpe.net.cable.rogers.com) |
| 22:25.57 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 22:42.35 | *** join/#asterisk jkroon (~jkroon@165.16.203.110) |
| 23:20.46 | *** join/#asterisk matrix1233 (~matrix123@80.215.111.79) |
| 23:46.03 | *** join/#asterisk bmg505 (~leon@169-0-149-142.ip.afrihost.co.za) |
| 23:48.46 | *** join/#asterisk wyoung (~wyoung@wesleyy.com) |