| 00:00.20 | xochilpili | i have installed asterisk13 on centos and proxmox, and i cant access to asterisk, im using zoiper. In asterisk (normal) instalation (just test) i have to extensions, in proxmox i have done: iptables -t nat -A PREROUTING -i eth0 -p udp --dport 5061 -j DNAT --to 10.0.1.4:5061 and 5060 both protocols: udp|tcp |
| 00:01.29 | xochilpili | and i have a virtualized machine on proxmox which is 10.0.1.4 then, from my terminal (@home) telnet mypubip 5060 and from asterisk server: tcpdump -v -x -X -s 1500 -i eth0 'port 5060' and get packages |
| 00:02.19 | xochilpili | also using 5061, nc -u mypubaddr 5060|5061 and tcpdump get packages |
| 00:02.29 | xochilpili | but asterisk just sitting there doing nothing. |
| 00:02.49 | xochilpili | i also, from asteriskCli>sip set debub on and core set debug 9 |
| 00:03.25 | xochilpili | but nothing happens, please, what am i missing ? i have to tell, in asterisk server, i have (for now) disabled iptables |
| 00:13.52 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 00:15.23 | [TK]D-Fender | And did you expressly configure * to listen for TCP on those ports? |
| 00:15.43 | *** join/#asterisk Surye (b8b1a482@gateway/web/freenode/ip.184.177.164.130) |
| 00:15.59 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:6553:d638:46d0:68b) |
| 00:18.06 | Surye | I'm running Asterisk 13.16.0, using pjsip, and I seem to be having a NAT issue to our SIP trunk. In a packet dump I can see the SIP header information is re-written correctly (external IP), but the SDP information does not (even though I have external_media_address and external_signaling_address set to the internet IP) |
| 00:19.20 | Surye | so calls establish fine, but there's no audio either way, and from my firewall all I see is outgoing RTP |
| 00:24.24 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 00:26.25 | *** join/#asterisk jkroon (~jkroon@165.16.204.164) |
| 00:57.24 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 01:19.35 | *** join/#asterisk infobot (ibot@rikers.org) |
| 01:19.35 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.19.0 (2018/01/11), Standard: 15.2.0 (2018/01/11); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 01:42.43 | *** join/#asterisk Alblasco1702 (~Alblasco1@ip5456b46b.speed.planet.nl) |
| 01:50.07 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:c5a3:df70:63f1:bef1) |
| 02:15.37 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 02:25.11 | *** join/#asterisk thiagoc_ (~thiagoc@unaffiliated/thiagoc) |
| 02:46.03 | xochilpili | [TK]D-Fender, yes: UDP Bindaddress: 0.0.0.0:5060 and TCP SIP Bindaddress: 0.0.0.0:5060 |
| 02:46.22 | xochilpili | [TK]D-Fender, sorry for the delay, ^ directly from sip show settings |
| 02:47.48 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 03:13.00 | xochilpili | rtp are udp or tcp? |
| 03:16.38 | xochilpili | nevermind :D |
| 03:22.36 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 03:22.47 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 03:31.55 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 04:07.24 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:c5a3:df70:63f1:bef1) |
| 04:08.03 | *** join/#asterisk sarman (6c48e6d2@gateway/web/freenode/ip.108.72.230.210) |
| 04:25.50 | wyoung | xochilpili: UDP is the only way to fly |
| 04:26.24 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 05:05.26 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:17.09 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 06:24.28 | *** join/#asterisk waldo323_ (~waldo323@12.239.4.3) |
| 06:51.20 | *** join/#asterisk paulgrmn (~paulgrmn@198-0-107-153-static.hfc.comcastbusiness.net) |
| 07:43.24 | *** join/#asterisk miralin (~Thunderbi@91.237.94.2) |
| 08:14.32 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 08:16.46 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 08:20.21 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 08:42.44 | *** join/#asterisk areski (~areski@154.red-83-47-211.dynamicip.rima-tde.net) |
| 08:53.19 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:53.44 | wyoung | hi gang |
| 08:58.18 | *** join/#asterisk sotoz (~sotoz@095-097-255-070.static.chello.nl) |
| 09:06.17 | *** join/#asterisk sekil (~sekil@94-21-177-123.static.digikabel.hu) |
| 09:50.49 | *** join/#asterisk PrezPusyGrab (~gbully@71-223-44-106.phnx.qwest.net) |
| 10:07.21 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 10:07.59 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 10:22.00 | *** join/#asterisk Syco (~syco@86.43.91.148) |
| 10:25.58 | Syco | Hello, I have a question about asterisk 1.8 and sip. How can I make Dial(SIP/${number}@${ipaddress}) to use tcp in certain cases? |
| 10:31.47 | *** join/#asterisk DanB (~DanB@fw2.nextpertise.nl) |
| 10:35.00 | tzafrir | Syco: generally: use a peer and not an IP |
| 10:35.08 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 10:39.34 | Syco | I know that's a solution, but it's a large environment, creating peers and keeping them in sync between servers would be too much of a job and of cource I'm not allowed to change the infrastructure too much |
| 10:48.11 | JohnWigley | Syco: usually you'd put ;transport=tcp as in the following example sip/291@192.168.1.4:61032;transport=tcp |
| 10:48.39 | JohnWigley | that example also has a port number 61032 in it as well. |
| 10:52.48 | JohnWigley | if you really need to do that as part of a large infrastructure, there are several different ways you may be able to do it easier, one would be to look up DUNDI (https://www.voip-info.org/wiki/view/Asterisk+DUNDi+Call+Routing), the other things you could do include putting routing information in a database then accessing it from Asterisk's DB lookup functions, or put it in a webservice and |
| 10:52.48 | JohnWigley | use CURL to retrieve it, or you could use DNS names instead of IP addresses, and then have each server responsible for updating its own address in DNS so you don't have to maintain all the current IP addresses per server. |
| 10:54.23 | JohnWigley | The idea of havign to maintain an IP address set per server seems a horrific management overhead, which is why most people will tell you to try and avoid it for a clean design. |
| 11:22.29 | Syco | This is one of those situations where the structure built over the last 10 years is monolitic and can't be changed by the last hired.. anyway, the Dial command doesn't accept ;transport=tcp, if I Dial(sip/291@192.168.1.4:61032;transport=tcp) it takes "192.168.1.4:61032;transport=tcp" as the hostname and the call fails |
| 11:25.47 | file | https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L19 states the possible Dial strings for chan_sip |
| 11:28.22 | Syco | thanks, so this is the line I was looking for: SIP/username[:password[:md5secret[:authname[:transport]]]]@host[:port] |
| 11:29.17 | Syco | and my dial simply changes to Dial(SIP/number::::tcp@ipaddress), that I considering my db structure and management software is the best solution in this case ;) |
| 11:29.42 | JohnWigley | Syco, sorry my mistake @file has the correct syntax. I confused the dial cmd with the transport representation in the actual SIP message. |
| 11:29.57 | file | JohnWigley: you would have been correct if speaking PJSIP |
| 11:31.25 | *** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 11:34.19 | Syco | I agree, pjsip would be so much easier. Anyway, thanks both of you |
| 11:38.04 | *** join/#asterisk nix8n82 (~AndChat58@2601:283:8302:2f0d:c1c3:38f:cd94:2d23) |
| 11:38.44 | *** join/#asterisk corretico (~corretico@200.91.143.34) |
| 11:48.03 | vt | Is there any way to tell Monitor() to record channels using the active audio codec (to not transcode anything, just dump to disk) ? |
| 11:50.58 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
| 11:58.40 | JohnWigley | Hi, I wonder if someone knowledgeable could take a quick look at this SIP message flow between Callcentric and an Asterisk server - the SIP flow shows a successful registration to Callcentric, and then Callcentric calling Asterisk from the same IP/PORT as the SIP registration (as you'd expect for NAT traversal), however Asterisk rejects the Invite stating: Failed to authenticate. |
| 11:58.41 | JohnWigley | https://pastebin.com/KWThpjGd |
| 11:59.19 | JohnWigley | insecure=Invite is configured for this connection, so according to the docs Asterisk ought to be authenticating it based only on the IP/PORT that the request came from? |
| 12:01.50 | JohnWigley | Could it be that the FROM header shows a different IP address to the SIP Invite that was received? However I thought that this should not matter because Asterisk should only match on the actual IP/PORT the Invite came from rather than that claimed in the From header, in order to support NAT in the path. |
| 12:30.05 | *** join/#asterisk nix8n82 (~AndChat58@2601:283:8302:2f0d:c1c3:38f:cd94:2d23) |
| 12:38.00 | *** join/#asterisk DanB (~DanB@fw2.nextpertise.nl) |
| 12:47.46 | vt | in a gosub call : Spawn extension (cdr-detail, s, 2) exited non-zero on 'SIP/0004F21458A1-00000000' |
| 12:48.12 | vt | is there anyway to have things more verbose ? (I know the s,2 is a simple Set) |
| 13:00.34 | Samot | JohnWigley: Why are you authing their invites? |
| 13:01.25 | JohnWigley | Samot: I'm not intending to, what could be causing it to try and auth the invites. Insecure=Invite is configured. |
| 13:01.27 | Samot | Feb 2 11:36:53 voip2 asterisk[2325]: VERBOSE[2609]: chan_sip.c:4816 in send_request: Reliably Transmitting (NAT) to 204.11.192.163:5060: <-- Also, I highly doubt Call Centric is behind NAT |
| 13:01.34 | Samot | insecure=invite,port |
| 13:03.23 | JohnWigley | I agree, however there is discussion mentioned that callcentric have a bunch of servers and occasionally send invites NOT from the server you've registered with. In order for their services to work in practice for users behind NAT they MUST be sending messages back from the same IP/PORT, and therefore by forcing Asterisk to include Rport etc, my theory is it will stop that behaviour and |
| 13:03.23 | JohnWigley | they'll make sure they send all SIP messages back from the registration IP/PORT. |
| 13:04.41 | JohnWigley | Samot: But the message returned comes from the same port (5060) as the registration request (that's why I included the Register message flow), so it can't be that Insecure=Invite/port can it? |
| 13:06.05 | Samot | Huh? |
| 13:06.14 | Samot | You are totally confusing how things work. |
| 13:06.49 | Samot | A REGISTER tells Call Centric -> Please send calls/requests to this IP:Port |
| 13:06.50 | JohnWigley | I would understand what I'm seeing IF they were sending SIP messages NOT from the ip/port that is registered, but the Invite comes from the same IP/PORT as Asterisk registered to - so therefore it cannot be that the issue I'm seeing is anything to do with the ip/port that the Invite came from - can it? |
| 13:08.30 | JohnWigley | Samot: I don't believe that I am (though I could be mistaken;) Asterisk registers with Callcentric, it registers to callcentric at 204.11.192.163:5060. The Invite from callcentric comes from 204.11.192.163:506 - therefore Asterisk should match that. What bit of this am I misunderstanding? |
| 13:08.57 | JohnWigley | <PROTECTED> |
| 13:10.51 | file | you would need to provide the configuration |
| 13:11.30 | JohnWigley | @file - which parts of the config should I post, the sip.conf section for callcentric? |
| 13:12.13 | file | yes, and you should also use "sip show peer" to confirm the resolved address for the peer that it is matching |
| 13:12.23 | JohnWigley | one min... |
| 13:15.36 | file | also - you must create a peer for all their possible IP addresses or if they send from elsewhere it won't match |
| 13:15.42 | file | one peer for each. |
| 13:18.11 | JohnWigley | https://pastebin.com/DdH7ateq |
| 13:18.36 | JohnWigley | Sorry took a while to delete all the irrelevant config in sip.conf, it had a lot of users/registrations in it. |
| 13:19.07 | Samot | [1777853XXXX] <-- Change that |
| 13:19.45 | file | callcentric.com can resolve to different IP addresses |
| 13:19.51 | file | it may not have resolved to what you think. |
| 13:19.58 | Samot | nat = force_rport,comedia <-- Again, Call Centric is not behind NAT |
| 13:20.09 | JohnWigley | @file: re: creating a peer for all their IPs - I've seen other users talk about doing that and ending up with a mess of 50+ peer definitions in it. However they are an ITSP who deal with SOHO/consumers, if they do that for any user behind a normal NAT then inbound calls are going to fail, so they MUST not be doing that in practice if they detect a subscriber is behind NAT, otherwise it would |
| 13:20.09 | JohnWigley | cause them a support nightmare. |
| 13:20.35 | Samot | Uhm. |
| 13:22.01 | Samot | Asterisk checks the IP address (and port number) that the INVITE |
| 13:22.01 | Samot | ; was sent from and matches against any devices with type=peer |
| 13:22.33 | JohnWigley | @file: yes, callcentric.com has a ton of A records in it, that they rotate frequently - presumably it's how they load balance. BUT the issue we're seeing is NOT this issue where they send from a different IP/port, you can see 100% definitely that the rejected Invite came from the same IP/PORT that was registered to - so how can this be related to the issue I've seen? |
| 13:23.02 | file | because the register line and the peer are resolved independently so they can have different IPs? |
| 13:23.10 | JohnWigley | @file AH! |
| 13:23.11 | file | did you look at the "sip show peer" output to see what the resolved IP address/port was? |
| 13:23.25 | Samot | Also... |
| 13:23.29 | JohnWigley | @file: Sorry forgot in my haste to paste the sip.conf - will check now. |
| 13:23.33 | JohnWigley | That would explain it wouldn't it. |
| 13:23.42 | Samot | I highly doubt their SIP domain is just "callcentric.com" |
| 13:23.57 | JohnWigley | I followed their asterisk setup guide from their website. |
| 13:24.16 | JohnWigley | I've seen a lot of ITSPs do that, presumably for vanity reasons. |
| 13:24.33 | file | Samot: it can be. |
| 13:24.39 | Samot | I know it can be. |
| 13:24.39 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:25.03 | Samot | I've never seen an ITSP use the main domain |
| 13:25.06 | file | they do SRV off the domain |
| 13:25.12 | Samot | I've seen sip.callcentric.com |
| 13:25.15 | Samot | I'm sure they can... |
| 13:25.16 | *** join/#asterisk billxx (49958984@gateway/web/freenode/ip.73.149.137.132) |
| 13:25.21 | Samot | Or some other sub domain |
| 13:25.31 | JohnWigley | This was working several months ago, and yesterday in my testing it worked successfully once - so I bet it's exactly as @file describes. I didn't realise that the peer and register were independently resolved. |
| 13:25.50 | Samot | I don't know why you need to match the port |
| 13:25.56 | Samot | You have a static host. |
| 13:26.21 | JohnWigley | It does seem insane that Asterisk would do that, for any outbound registration surely you'd want it to match on the ip/port that it actually registered to. |
| 13:26.22 | Samot | insecure=invite,port <-- common for ITSP trunks. |
| 13:27.18 | file | registration and inbound matching are independent. |
| 13:27.27 | JohnWigley | The insecure=Port option only means that it ignores the port the sip request came from not to though doesn't it? |
| 13:27.46 | file | in chan_pjsip there is an option to use the registration to match inbound, if the upstream supports it. |
| 13:27.52 | JohnWigley | Just checking the sip show peer output |
| 13:27.52 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:28.51 | Samot | https://www.irccloud.com/pastebin/fTI6FFJu/ |
| 13:29.29 | Samot | OK so they use callcentric.com |
| 13:29.44 | Samot | But is there a reason your trunk is missing key settings from their sample configs? |
| 13:30.00 | Samot | First off, they say "peer" |
| 13:30.15 | Samot | They do have insecure=port,invite |
| 13:30.29 | JohnWigley | https://pastebin.com/48iM1iLf |
| 13:30.49 | file | tada. |
| 13:31.01 | JohnWigley | @file: It's exactly as you said, the resolved peer IP is NOT the same as the registration IP - THANK YOU! |
| 13:32.06 | JohnWigley | Samot: The sip.conf is generated by Wazo (nee Xivo), so I don't have easy way to exactly configure it as per their example, but it was working fine when I previously tested it. |
| 13:34.08 | JohnWigley | Ok, so a possible solution to this then is to fake a new domain name such as callcentric.mydomain.com and make sure that it has only a single A record in it resolved from callcentric.com. So if they change IPs then it will update almost immediately BUT when Asterisk queries it, it will only ever come back with a single IP address. |
| 13:37.45 | JohnWigley | @file - This behaviour would also explain another similar issue I have with another ITSP (Andrews&Arnold) where occasionally (once per month or so) we start getting calls rejected. They also have multiple A records for their SIP proxy, and I think the same thing is happening, but only very occasionally for some reason. |
| 13:41.39 | JohnWigley | In a peer definition, the IP ACL rules PERMIT/DENY - they don't happen to figure in the matching do they, in other words could I use a PERMIT rule specifying the whole of Callcentric's subnet 204.11.192.0/24 for it to match against? |
| 13:41.49 | file | nope. |
| 13:42.04 | JohnWigley | @file: didn't think so. |
| 13:43.21 | JohnWigley | I certainly do NOT want to try and maintain a peer list covering every possible server (50+, and changing randomly) in order for this to work reliably. So I need to find another way such as ensuring that the peer and registration domain always resolve to the same IP. |
| 13:44.50 | Samot | You can't. |
| 13:44.57 | JohnWigley | Samot: why not? |
| 13:45.04 | Samot | Not without using a FQDN that actually resolves to 1 IP. |
| 13:45.12 | Samot | It's not your DNS? |
| 13:45.15 | JohnWigley | Samot: yes, that's exactly the approach I thought. |
| 13:45.44 | JohnWigley | No, obviously I don't have control over callcentric.com but I could use another FQDN that I do have control of. |
| 13:45.51 | Samot | You can't magically make calls from 4 of their servers look like the same IP. |
| 13:46.33 | JohnWigley | Samot: But I don't need to, all I need to do is ensure that when Asterisk looks up callcentric.com it gets the same IP for the registration AND the peer lookup. |
| 13:46.52 | Samot | OK? |
| 13:47.00 | Samot | That's for outbound. |
| 13:47.05 | file | you can put IP addresses in there... |
| 13:47.09 | Samot | ^^^ |
| 13:47.18 | Samot | It would be the IP it would send/take calls from. |
| 13:47.25 | Samot | But what if they send a call from another server?! |
| 13:47.34 | Samot | You can't control where the incoming calls are coming from. |
| 13:47.53 | JohnWigley | @file: yes, I was thinking of that BUT then if they rotate a server out of service then it's not going to work. I'm trying to come up with a solution, that works now, AND doesn't need constant updating whenever they change server IPs. |
| 13:48.09 | Samot | They don't "change" server IPs. |
| 13:48.15 | Samot | They have multiple hosts. |
| 13:48.26 | Samot | You don't control which one the call comes from. |
| 13:48.34 | JohnWigley | Samot: Yes, you can, they MUST be coming from the ip/port you register to, otherwise for every user behind NAT calls would randomly fail. They cannot be doing that as a consumer/soho ITSP. |
| 13:48.39 | Samot | NO |
| 13:48.41 | Samot | They do not. |
| 13:49.57 | JohnWigley | Samot: sorry not understanding you, do you agree they must be sending Invite's from the IP/port you register to, in order for their service to work reliably for consumer users behind NAT routers? |
| 13:49.59 | Samot | Incoming calls do not have to source from the LOCATION server. |
| 13:50.40 | Samot | Again, ALL the REGISTER does it tell CallCentric what IP:Port your PBX is at. |
| 13:50.40 | JohnWigley | Samot: If they didn't then they wouldn't work for anyone behind a NAT fw/router - All consumer orientated ITSPs I've seen do that for that exact reason. |
| 13:50.46 | Samot | And where to send the requests. |
| 13:50.58 | Samot | YOU are the one choosing to only accept calls from a certain place. |
| 13:51.06 | Samot | No. |
| 13:51.09 | Samot | You are incorect. |
| 13:51.12 | Samot | You are incorrect. |
| 13:51.35 | *** join/#asterisk qxork (~qxork@unaffiliated/qxork) |
| 13:51.51 | JohnWigley | Samot: I understand that it how the SIP RFCs are specified, however in order for it to work in the real world, all the one's I've seen ignore the contact addresses in the SIP register, and just send all traffic back to the IP/PORT that the registration request actually came from. |
| 13:52.11 | JohnWigley | Even Asterisk does the same. |
| 13:52.23 | Samot | This is kinda what I do. |
| 13:52.41 | file | that's different than using the same registration server, I've seen them send from different ones |
| 13:52.47 | Samot | I'm pretty sure I understand how ITSP's/Telco's do this. |
| 13:52.49 | file | and whether it would work or not depends on the NAT implementation |
| 13:52.57 | JohnWigley | For TCP/TLS it's actually mandatory that you send subsequent messages back over the same connection flow. |
| 13:53.14 | file | it's not mandatory, but in practice it's the best thing |
| 13:53.30 | Samot | Twilio sends calls from 5 or MORE proxies. |
| 13:53.45 | Samot | They do not source from the same location you send a REGISTER to. |
| 13:53.51 | Samot | CallCentric does it. |
| 13:54.08 | Samot | There are multiple ITSPs that tell you "Our Calls AND/OR MEDIA source from different IPs" |
| 13:54.16 | JohnWigley | Twillio isn't a consumer ITSP, so I can understand that they would do it. |
| 13:54.29 | Samot | Sure they are. |
| 13:54.40 | Samot | They have a pretty big consumer base. |
| 13:55.08 | Samot | Let's be clear about something... |
| 13:55.14 | Samot | CallCentric is much like me. |
| 13:55.18 | Samot | They are an aggregator. |
| 13:55.24 | Samot | They are an aggregate. |
| 13:55.40 | Samot | Most ITSPs "pass-through" their stuff to the upstreams. |
| 13:55.55 | Samot | They handle Registration but then everything past that is outside them. |
| 13:55.58 | Samot | They just proxy. |
| 13:56.15 | JohnWigley | I remember years ago getting silent calls behind NAT with issues around media being sent to local IPs etc, but in the last few years, I've never seen an ITSP not ignore the SDP addresses and just send the RTP back down the same port as it's received from. |
| 13:56.34 | Samot | Because they are doing NAT Repair. |
| 13:56.40 | Samot | They are fixing your bad NAT |
| 13:56.52 | Samot | It's exactly what I do. |
| 13:57.06 | Samot | There should be ZERO RFC1819 IPs in your packet. |
| 13:57.24 | Samot | When going over the Internet. |
| 13:59.09 | JohnWigley | ok, maybe I've got a rose tinted view of what the ITSPs I deal with do in practice, but it doesn't make any sense to me at all that if you're selling a consumer orientated service and you actually want Joe user to be able to use your service by setting up a softphone or plugging in a phone to a normal consumer router that you would EVER send SIP messages from anywhere BUT the already opened |
| 13:59.09 | JohnWigley | NAT connection to your registration proxy. It just seems insane, you're asking for a support nightmare by doing it. |
| 13:59.44 | Samot | Wait... |
| 13:59.47 | Samot | Stop. |
| 14:00.51 | Samot | An ITSP provides the "Class 4" connection. |
| 14:01.14 | Samot | That is to say, in a broad sense, they give you "dial tone". |
| 14:01.26 | Samot | They give you a way to receive and send calls to/from the PSTN |
| 14:01.46 | Samot | Features like voicemail, call waiting, all that are handle by you because you should have a PBX. |
| 14:02.31 | Samot | In some cases they will also provider "Class 5" services... |
| 14:02.52 | Samot | When you register a Softphone/ATA to them and they provide all those features at their level.. |
| 14:03.19 | Samot | But then you generally end up with a "Traditional Setup" |
| 14:03.35 | Samot | I.e. You only have two call paths, just like a normal POTS line. |
| 14:03.42 | Samot | They provide you a voicemail box. |
| 14:03.52 | Samot | They do any call forwarding |
| 14:06.20 | JohnWigley | Samot: I appreciate your help, but how is any of that relevant to whether or not they should/would send SIP messages back down the same flow as the registration? |
| 14:06.21 | Samot | Certain ITSPs/VoIP Providers never expect OR want a PBX on their network. They want Softphones/ATAs. |
| 14:06.33 | Samot | Certain ITSPs ONLY expect PBX systems. |
| 14:06.41 | Samot | Because it's not required. |
| 14:06.52 | Samot | Or a common practice for certain level ITSPs. |
| 14:06.58 | Samot | ALL |
| 14:07.01 | Samot | I mean ALL |
| 14:07.09 | JohnWigley | Ok, well maybe we can agree that if you want a non technical user to be able to use a softphone/deskphone in practice then you MUST send all SIP messages back down the registration flow? |
| 14:07.10 | Samot | A REGISTER does it tell them WHERE TO SEND REQUESTS |
| 14:07.17 | Samot | NO |
| 14:07.19 | Samot | You do not. |
| 14:07.28 | Samot | That is a choice. |
| 14:07.34 | Samot | By the ITSP/Provider. |
| 14:08.22 | JohnWigley | So without getting joe user to either open a port forward, or configure UPNP, or pray they have a wide open NAT - how would you expect it to work, if you send calls from random IPs? |
| 14:08.36 | Samot | That's why there is a market. |
| 14:08.47 | Samot | You choose the provider that fits your needs. |
| 14:09.16 | Samot | If you're choosing your provider based only on "cheap" then you have to spend time jumping through hoops because they could have an outlandish setup. |
| 14:09.32 | Samot | Where it is "cheap" for them because they basically have almost no infrastructure. |
| 14:09.56 | Samot | The fact *I* send everything through ONE IP for the most part.. |
| 14:10.07 | Samot | Makes me a better option for people in those markets I am in. |
| 14:10.11 | Samot | It's a bonus for me. |
| 14:10.29 | Samot | But I also do it because I insist on having control. |
| 14:11.15 | Samot | ALL Signalling and Media between the upstreams and my end users go through _me_. |
| 14:13.37 | Samot | You also keep saying "consumer" without a distinction. |
| 14:14.06 | Samot | A Business Consumer is not treated the same as a "Non-Business/Resi" Consumer. |
| 14:14.25 | JohnWigley | I'm not meaning to be rude, but I'm really not understanding your thinking here - Business/technically orientated SIP origination and termination providers I can understand for reasons of network optimisation and redundancy sending calls from multiple IPs, particularly RTP. However if you have users REGISTER to you, then that screams that they're on Dynamic IPs, Dynamic IPs are *usually* |
| 14:14.25 | JohnWigley | behind NAT, if you're behind NAT then unless you open ports you will NOT receive inbound SIP messages from anywhere BUT the outbound registration you've made. Hence IF you actually want to sell a service to consumers that works reliably, and does not cause you a support nightmare, why on earth would you even consider sending SIP messages from anywhere BUT the registration ip/port? |
| 14:14.57 | Samot | JohnWigley: Your logic assumes that all users USE Registration. |
| 14:15.04 | Samot | That's not true. |
| 14:15.21 | Samot | You're taking the "Non-Business" Consumer look at things. |
| 14:15.36 | Samot | Residential and Business services are not the same. |
| 14:15.42 | Samot | They are not treated the same |
| 14:16.01 | Samot | They have different expectations. |
| 14:16.35 | JohnWigley | No it doesn't, it assumes that IF they register then as a provider you really want to send messages back down the flow. I use ITSPs that give you the option, and sure I totally get that if you don't register and they send calls to a statically configured address that it's reasonable in that case for them to originate from various locations as you would already by definition have got to have |
| 14:16.35 | JohnWigley | ensured you've got an open inbound path BUT not for users that register to you. |
| 14:16.44 | Samot | OK. |
| 14:16.45 | Samot | So.. |
| 14:16.52 | Samot | Just so we can cut to the chase here... |
| 14:17.05 | Samot | I've spent over a decade at ITSPs/Telcos/LECs. |
| 14:17.27 | Samot | What you are basically doing is telling me how my job, as an engineer at those places, is being done. |
| 14:18.39 | JohnWigley | Not at all, I'm simply suggesting that if you want to offer a reliable and LOW support service to consumers then you must do that. If I'm missing something, please explain how you think it would work in practice sending Invite's to consumers behind NAT from random IPs? |
| 14:18.52 | Samot | Again. |
| 14:18.57 | Samot | You are stuck on this single thread. |
| 14:19.08 | Samot | The requests do not have to source from where you REGISTER to. |
| 14:19.09 | Samot | Period. |
| 14:19.11 | Samot | At all. |
| 14:19.20 | Samot | It's a GOOD practice. |
| 14:19.27 | JohnWigley | Ok, so in that case HOW is it expected to work for a user behind NAT? |
| 14:19.45 | Samot | But larger ITSPs, ones who carter to BUSINESS consumers don't worry about that. |
| 14:19.57 | Samot | Because in most cases they are handling that themselves. |
| 14:20.27 | JohnWigley | Finally something we agree on ;), and they shouldn't have to because they can assume a degree of competency on the part of the end user. |
| 14:20.36 | Samot | Wait.. |
| 14:20.43 | Samot | Now you are using Asterisk.. |
| 14:20.47 | Samot | And making a trunk.. |
| 14:20.56 | Samot | A trunk that says "I only expect calls from X place" |
| 14:21.01 | Samot | NAT has nothing to do with that |
| 14:21.10 | Samot | Your setup does |
| 14:21.29 | Samot | This isn't NAT stopping your call. |
| 14:21.36 | Samot | This is Asterisk DENYING the call. |
| 14:21.36 | JohnWigley | Agreed |
| 14:21.46 | Samot | Because of how your configuration. |
| 14:21.53 | Samot | configured* |
| 14:21.59 | Samot | Again.. |
| 14:22.22 | Samot | ITSPs are pretty open about "We send calls from X amount of IPs/proxies so you need to allow them" |
| 14:22.34 | Samot | At that point you, as the consumer, have to make a choice. |
| 14:22.42 | Samot | "Do I want to deal with that or not?" |
| 14:23.27 | Samot | The provider didn't choose you. |
| 14:23.33 | Samot | You chose the provider. |
| 14:23.54 | Samot | Complaining about their "odd" setup doesn't change that fact. |
| 14:24.05 | Samot | If they have a setup you do not like or want to deal with, get another provider. |
| 14:25.53 | *** join/#asterisk Offer (~Offer@80.74.123.8) |
| 14:26.25 | Samot | I will give you an example from my perspective. |
| 14:26.34 | JohnWigley | I think we're going round in circles a bit here, I understand you're saying that business ITSPs should and do have the freedom to send calls from multiple locations - I agree with that. I also agree that the SIP RFCs say that this is fine too. My point is that IF you're trying to cater to the consumer market then you CANNOT do that in practice, unless you want to start a large support budget |
| 14:26.34 | JohnWigley | trying to educate them as to how they open ports. I'm saying Callcentric markets itself as Joe Idiot can plug in a phone and go - therefore for them to do that is stupid. They are perfectly entitled to do that and as you say; you select a provider that works for you. HOWEVER, in this case we are NOT seeing that behaviour, Callcentric HAVE sent all Invite's back down the registration flow (as |
| 14:26.34 | JohnWigley | I'd expect them to do), the issue is that Asterisk for historical reasons has evaluated the FQDN to two different IPs for the registration and peer lookups, and that is the root cause of this issue - nothing to do with them sending calls from multiple locations. |
| 14:26.40 | Samot | I'm in markets in New Mexico. |
| 14:26.48 | Samot | Where ITSPs are not big. |
| 14:27.05 | Samot | Why? Because the consumers like the "truck roll" aspect of what the Telco's offer there. |
| 14:27.31 | Samot | New Mexico Telco's still support 7 digit dialing, ITSPs do not. |
| 14:27.46 | Samot | Their telco's still support some old school methods. |
| 14:28.08 | Samot | So _all_ the consumers have expectations for service based on that fact. |
| 14:28.17 | Samot | It is why ITSPs fail their. |
| 14:28.19 | Samot | It is why ITSPs fail there. |
| 14:28.31 | Samot | I *made a choice* to support 7 digit dialing |
| 14:28.46 | Samot | I *made a choice* to put boots on the ground for truck rolls and service calls |
| 14:29.08 | Samot | I made choices to make my services and offerings more appealing for the consumers in that market. |
| 14:30.43 | Samot | JjohnWigley: Also... |
| 14:30.52 | Samot | JohnWigley: Also |
| 14:31.30 | Samot | There is a reason CallCentric has all those hosts listed for Asterisk/PBX systems... |
| 14:31.42 | Samot | Because looking at their services and how they work... |
| 14:31.52 | Samot | A broadband Internet connection. |
| 14:31.52 | Samot | A softphone such as Callcentric's free Softphone; or bring your own Telephone Adapter or IP Phone. |
| 14:31.58 | Samot | ^^ That's what they require.. |
| 14:32.01 | Samot | You see.. |
| 14:32.08 | Samot | An ATA or an IP Phone or a Softphone... |
| 14:32.12 | Samot | Those are DUMB devices... |
| 14:32.19 | Samot | They just accept calls. |
| 14:32.21 | Samot | From any IP |
| 14:32.25 | Samot | Any port.. |
| 14:32.32 | Samot | So when you're asking "How can they do this" |
| 14:32.43 | Samot | It's because they have an EXPECTATION of what the end point is. |
| 14:32.51 | Samot | Because how they deliver their services.... |
| 14:33.00 | Samot | When you decide "Hey I'm going to use a PBX" |
| 14:33.24 | Samot | They say "OK but you need to add ALLLLLLL these hosts for it to work. Because PBXs will want that" |
| 14:34.15 | Samot | This is _exactly_ what I have been saying. |
| 14:35.19 | Samot | When the business model is "95% of our endpoints will be dumb devices and about 5% will be PBXes/smart devices" |
| 14:35.37 | Samot | the 5% have a lot more hoops to jump through because the network is not geared towards them over all. |
| 14:36.47 | Samot | In old school terms, Call Centric would deliver 24 POTS lines to give you 24 channels vs giving you a single line with 24 channels (PRI) |
| 14:36.58 | Samot | Because that's the kind of service they do. |
| 14:37.45 | JohnWigley | I wonder if Kamailio is smart enough to actually to realise it ought to accept Invites back from the same IP/port it registered to... That might be an easier solution than a DNS proxy for this case. You mentioned PJsip can also do this, but the problem is that the infrastructure around Asterisk in my case won't allow using PJsip. |
| 14:37.59 | Samot | Sigh |
| 14:38.02 | Samot | PJSIP = SIP |
| 14:38.08 | Samot | It is just a SIP Stack/Driver. |
| 14:38.13 | JohnWigley | I meant Pjsip instead of ChanSIP. |
| 14:38.45 | Samot | ITSPs support SIP |
| 14:38.52 | Samot | See now.. |
| 14:38.59 | Samot | Kamailio is a solution. |
| 14:39.08 | Samot | Because Kamailo can peer with all 50 hosts |
| 14:39.20 | Samot | And send them to the endpoints from ONE source location. |
| 14:39.28 | JohnWigley | Unless I misunderstoof you - It's ChanSIPs behaviour to independently lookup the FQDN for the registration and peer IP addresses which is my issue, and that PJsip didn't behave like that? Or have I misunderstood? |
| 14:39.34 | Samot | so you would need to put Kamailio in front of your PBX. |
| 14:39.49 | Samot | Chan_SIP allows one host per peer |
| 14:40.13 | Samot | Chan_PJSIP will allow multiple. |
| 14:40.27 | JohnWigley | It wouldn't have to go in front theoretically, it would just have to handle the sip registration and inbound responses from Callcentric, it wouldn't actually have to proxy all the users or other SIP trunks. |
| 14:40.47 | Samot | It needs to be between call Center and the PBX |
| 14:40.56 | Samot | One peer between Kamailio and the PBX |
| 14:41.05 | Samot | And all the peers between Call Centric and Kamailio. |
| 14:41.49 | Samot | You should get a provider that supports PBXes as their primary endpoints. |
| 14:42.14 | Samot | Not one that expects ATAs, Softphones, IP Phones and _can do_ PBXes if you do X, Y, Z. |
| 14:42.58 | JohnWigley | Samot: I don't believe and haven't seen any convincing evidence so far that Callcentric are sending Invites from multiple IPs, in fact I would BET that they're not. All of the SIP traffic from them that I've looked through ALWAYS has the Invite's originate from the registration flow. I think that what's happening when other people are thinking they see this is that they are frequently |
| 14:42.58 | JohnWigley | re-registering to callcentric and those re-registrations are to different IP addresses, and hence they THINK Callcentric is sending them invite's from multiple IPs. Whereas I think and the logs I have support this - is that they're actually sending you invites from the LAST ip you registered to. |
| 14:43.42 | Samot | https://www.callcentric.com/support/device/asterisk/14 |
| 14:43.47 | Samot | Seriously man |
| 14:43.57 | Samot | I'm reading their "How to connect Asterisk to us" docs. |
| 14:44.08 | Samot | They are pretty clear on how to do this with Chan_SIP and what is needed. |
| 14:44.54 | Samot | They literally tell you to add 15+ hosts. |
| 14:45.55 | JohnWigley | Agreed, I'm saying I don't believe that it's neccessary ;) Look at their list of supported devices IF they actually did this and sent from multiple IPs - how would you expect ANY of the softphones/ATA's/Deskphones to work??? |
| 14:46.08 | Samot | Because they are DUMB DEVICES |
| 14:46.26 | Samot | They don't care what the source IP or Port is. |
| 14:47.06 | Samot | A PBX and an IP Phone are apples and oranges. |
| 14:47.15 | JohnWigley | So what - they would NEVER even see the inbound invite if they were behind a NAT router - the fact that they are dumb devices or what their particular matching logic is, is totally irrelevant - they wouldn't get the chance to match an Invite from a random IP because it would NEVER make it through the NAT router! |
| 14:47.33 | Samot | That's also wrong. |
| 14:47.46 | Samot | The REGISTER is a request sourced by the device behind NAT |
| 14:48.00 | Samot | Therefore, the router should open a "NAT Hole" for that traffic. |
| 14:48.32 | Samot | This is why devices have Keep-Alive and "NAT" Settings to have them source requests to keep the NAT hole open. |
| 14:48.49 | Samot | And why systems like Asterisk have keep alives. |
| 14:49.03 | Samot | To keep that NAT hole going after the endpoint opened it. |
| 14:49.11 | JohnWigley | WHAT? If you make an outbound register request from a device behind a NAT router, then the only packets let back in and routed to your device are going to be from the same IP, if you're lucky and they're on a Cone NAT then you MIGHT be able to get away with sending from another port on the same IP but it's not something you can rely on. What you sure as hell cannot do is to expect to send |
| 14:49.11 | JohnWigley | them an Invite from a completely different IP and expect the endpoint to receive it. |
| 14:49.23 | Samot | OK. |
| 14:49.25 | Samot | Again.. |
| 14:49.30 | Samot | This is my job. |
| 14:49.35 | Samot | What I do 24/7 |
| 14:49.53 | Samot | I deploy services to end users like you. |
| 14:50.17 | Samot | I have spent my entire carrier building/supporting SIP/VoIP Telephony networks |
| 14:50.33 | JohnWigley | It might be, but I also have a lot of anecdotal experience with NAT routers, and I KNOW you cannot send traffic back from different IPs and have it reliably go back through the NAT entry. Possibly SIP ALGs in the router may help but you CANNOT rely on it. |
| 14:50.39 | Samot | You are literally making end users level arguments |
| 14:51.23 | file | this is going in circles, just stop |
| 14:51.27 | Samot | Yes. |
| 14:52.23 | Samot | The end result is this: CallCentric is probably not the right provider to use for pure SIP Trunking. |
| 14:52.31 | Samot | Because it's not their core model. |
| 14:52.42 | file | just stop :P |
| 14:52.48 | JohnWigley | Just so I'm clear - you're saying that if you open a connection outbound from a SIP endpoint behind a common NAT router, then you think if you send a SIP invite back to the NAT routers external IP/PORT FROM A DIFFERENET IP addres, that the NAT router is going to send that packet back to the SIP endpoint? |
| 14:52.50 | Samot | That's it. |
| 14:52.55 | file | JohnWigley knows the underlying reason, he can do as he wants |
| 14:53.23 | Samot | He's a big boy. Can make the choice, I know. |
| 14:53.56 | Samot | Funny part.. |
| 14:54.05 | JohnWigley | ok let's stop, clearly this antagonising everyone else. I do appreciate both of your help on this, and am glad you pinned down the exact reason the calls were failing, much appreciated! |
| 14:54.19 | Samot | I agree with him, I don't like ITSPs that source calls from a high amount of proxies. |
| 14:54.32 | Samot | Because of all the reasons mentioned. |
| 14:54.39 | Samot | It does become a support nightmare. |
| 14:55.00 | Samot | It's why I don't do it and why it makes me beat places like that in a sales deal. |
| 14:58.14 | Samot | This was a "We both agree 2 + 2 = 4 but I used old math and he used New Math so we don't agree on how it gets there" |
| 14:58.41 | Samot | https://www.youtube.com/watch?v=W6OaYPVueW4 |
| 15:11.09 | *** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co) |
| 15:18.55 | JohnWigley | Ok, so have implemented what is hopefully the final resolution to this issue for both Callcentric and another ITSP that I was now seeing this Asterisk behaviour affect. I've got a script running once a minute that looks up Callcentric's A records, picks one, confirms that it responds to a SIP options ping, and then updates the hosts file - so now Asterisk only ever will see a single IP address |
| 15:18.55 | JohnWigley | per FQDN, and hence the registration and peer IPs match, and HOPEFULLY this issue will never occur again, without any need to keep track of their 50 or so ever changing IP addresses. |
| 15:36.30 | *** join/#asterisk jeffspeff (~Jeff@12.49.160.131) |
| 15:42.10 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 15:45.12 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:8045:9b5e:e101:3cbd) |
| 15:58.55 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-zpisatpuvytuzkvn) |
| 15:58.55 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 16:00.24 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:52.33 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 16:57.34 | *** join/#asterisk visip (~visix@gateway/tor-sasl/visip) |
| 16:58.04 | visip | So... general question: Can I use asterisk to replace my cisco PBX (CUE)? |
| 17:01.58 | *** join/#asterisk visip (~visix@gateway/tor-sasl/visip) |
| 17:03.59 | *** join/#asterisk Worldexe_ (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 17:14.27 | [TK]D-Fender | Asterisk can be a PBX |
| 17:14.34 | [TK]D-Fender | Thousands already use it |
| 17:28.27 | jamesaxl | visip: and without problems |
| 17:28.45 | jamesaxl | [TK]D-Fender: do you use SIP or AIX2? |
| 17:29.07 | [TK]D-Fender | wishes people could spell it properly... |
| 17:29.56 | visip | u wot m8 |
| 17:30.34 | jamesaxl | [TK]D-Fender: I can spell of course |
| 17:31.08 | [TK]D-Fender | IAX <-------------- |
| 17:31.18 | [TK]D-Fender | AIX = IBM's UNIX OS |
| 17:31.20 | *** join/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net) |
| 17:31.47 | jamesaxl | [TK]D-Fender: it is just mistake then |
| 17:32.12 | jamesaxl | Do you use IAX2 or SIP? |
| 17:32.16 | visip | Hold the presses... |
| 17:32.18 | [TK]D-Fender | it's a 3 letter acronym if you exclude the version #. That means you got 2/3 of its letters wrong. #stats |
| 17:32.35 | [TK]D-Fender | SIP |
| 17:32.47 | [TK]D-Fender | I have used IAX2 before however |
| 17:37.05 | *** join/#asterisk paulgrmn (~paulgrmn@198-0-107-153-static.hfc.comcastbusiness.net) |
| 17:40.29 | jamesaxl | I am planing to use IAX2 for the three next projects, I just read about IAX2 and I see it is very good, |
| 17:41.57 | [TK]D-Fender | Generic praise and no pros & cons. Great start! |
| 17:51.01 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 18:22.26 | *** join/#asterisk Typhon (~Typhon@ipservice-092-218-213-030.092.218.pools.vodafone-ip.de) |
| 18:35.14 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 18:37.35 | *** join/#asterisk jkroon (~jkroon@165.16.204.174) |
| 18:54.31 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 19:07.59 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 19:15.18 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 19:25.09 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 19:33.24 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 19:33.59 | *** join/#asterisk Primer (~daniel@ceregatti.org) |
| 19:35.16 | Primer | Hi. About a year ago my home asterisk stopped working when I received a G1100 router from Frontier, which has SIPALG enabled and can't be turned off. All of a sudden it just started working again, and I'm trying to figure out what changed. |
| 19:35.52 | Primer | Has asterisk worked around NAT + SIPALG recently? |
| 19:36.20 | file | nope. |
| 19:36.28 | Primer | Actually, I just realized that I replaced the route recently, swapping one G1100 for another, due to its wifi having stopped working |
| 19:36.34 | Primer | router, that is |
| 19:36.58 | Primer | Is there any way to tell if SIPALG is being enforced at the NAT, where the NAT is mostly a black box? |
| 19:37.13 | Primer | I have an admin web interface, and that's it. SIPALG isn't mentioned anywhere. |
| 19:37.33 | Primer | Let me actually check that, new router and all |
| 19:38.27 | Primer | I just have to suppose this new router doesn't have it enabled, but asterisk is working as expected all of a sudden |
| 19:38.31 | Primer | I just hate not knowing |
| 19:40.02 | Primer | but yeah, it's just working again...oh well, thanks |
| 19:41.01 | Primer | yeah, I'm not finding anything that even mentions sip in the router's admin (which is not surprising) |
| 19:42.12 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 19:52.34 | *** part/#asterisk Primer (~daniel@ceregatti.org) |
| 19:53.11 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 19:53.47 | *** join/#asterisk miralin1 (~Thunderbi@195.209.246.194) |
| 20:02.33 | *** join/#asterisk miralin (~Thunderbi@91.237.94.2) |
| 20:04.31 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 20:21.01 | *** join/#asterisk areski (~areski@37.223.2.207) |
| 20:22.12 | *** join/#asterisk iggi (~iggi@ip69.50-31-21.static.steadfastdns.net) |
| 20:43.54 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 20:47.41 | *** join/#asterisk Dovid (~dovid@ool-45738ae3.dyn.optonline.net) |
| 20:49.44 | *** join/#asterisk iggi (~iggi@ip69.50-31-21.static.steadfastdns.net) |
| 20:51.31 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 20:59.24 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 21:10.12 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 21:19.51 | *** join/#asterisk Mchammerdad (~Mchammerd@96-18-0-34.cpe.cableone.net) |
| 21:20.17 | Mchammerdad | hey guys, if I have audio issues incoming only, is there anything I can do network wise to improve the performance? |
| 21:33.41 | *** join/#asterisk dar123 (~dar@172.58.38.187) |
| 21:43.00 | Kobaz | mmm |
| 21:43.12 | Kobaz | is there any way to set the external ip address on an adtran pri gateway |
| 22:05.07 | Samot | Well that is a rather specific question. I recall the Adtran docs having something about that |
| 22:08.06 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 22:10.02 | *** join/#asterisk tzafrir (~tzafrir@2a02:a03f:3e10:da00:7578:689f:eb68:5903) |
| 22:19.41 | igcewieling | your adtran is behind nat? |
| 22:20.00 | igcewieling | or you have your adtran doing natting? |
| 22:24.46 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 22:34.03 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407) |
| 22:49.25 | *** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407) |
| 23:04.14 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 23:05.06 | n\ack | When did RES_JSON first appear in Asterisk? |
| 23:07.10 | n\ack | ...Or is this just somebody's pet project |
| 23:13.07 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 23:16.07 | Kobaz | igcewieling: adtran is behind a nat |
| 23:16.20 | Kobaz | igcewieling: figured it out... you need to define a loopback interface with the public ip |
| 23:17.43 | igcewieling | Why not let Asterisk handle the nat? Is the adtran not connecting to Asterisk? |
| 23:19.03 | Kobaz | there's no asterisk |
| 23:19.06 | Kobaz | that's the issue |