IRC log for #asterisk on 20180202

00:00.20xochilpilii 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.29xochilpiliand 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.19xochilpilialso using 5061, nc -u mypubaddr 5060|5061 and tcpdump get packages
00:02.29xochilpilibut asterisk just sitting there doing nothing.
00:02.49xochilpilii also, from asteriskCli>sip set debub on and core set debug 9
00:03.25xochilpilibut 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-FenderAnd 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.06SuryeI'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.20Suryeso 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.03xochilpili[TK]D-Fender, yes: UDP Bindaddress:        0.0.0.0:5060 and TCP SIP Bindaddress:    0.0.0.0:5060
02:46.22xochilpili[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.00xochilpilirtp are udp or tcp?
03:16.38xochilpilinevermind :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.50wyoungxochilpili: 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.44wyounghi 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.58SycoHello, 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.00tzafrirSyco: generally: use a peer and not an IP
10:35.08*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
10:39.34SycoI 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.11JohnWigleySyco: usually you'd put ;transport=tcp as in the following example sip/291@192.168.1.4:61032;transport=tcp
10:48.39JohnWigleythat example also has a port number 61032 in it as well.
10:52.48JohnWigleyif 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.48JohnWigleyuse 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.23JohnWigleyThe 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.29SycoThis 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.47filehttps://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L19 states the possible Dial strings for chan_sip
11:28.22Sycothanks, so this is the line I was looking for: SIP/username[:password[:md5secret[:authname[:transport]]]]@host[:port]
11:29.17Sycoand 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.42JohnWigleySyco, sorry my mistake @file has the correct syntax. I confused the dial cmd with the transport representation in the actual SIP message.
11:29.57fileJohnWigley: you would have been correct if speaking PJSIP
11:31.25*** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl)
11:34.19SycoI 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.03vtIs 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.40JohnWigleyHi, 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.41JohnWigleyhttps://pastebin.com/KWThpjGd
11:59.19JohnWigleyinsecure=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.50JohnWigleyCould 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.46vtin a gosub call : Spawn extension (cdr-detail, s, 2) exited non-zero on 'SIP/0004F21458A1-00000000'
12:48.12vtis there anyway to have things more verbose ? (I know the s,2 is a simple Set)
13:00.34SamotJohnWigley: Why are you authing their invites?
13:01.25JohnWigleySamot: I'm not intending to, what could be causing it to try and auth the invites. Insecure=Invite is configured.
13:01.27SamotFeb  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.34Samotinsecure=invite,port
13:03.23JohnWigleyI 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.23JohnWigleythey'll make sure they send all SIP messages back from the registration IP/PORT.
13:04.41JohnWigleySamot: 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.05SamotHuh?
13:06.14SamotYou are totally confusing how things work.
13:06.49SamotA REGISTER tells Call Centric -> Please send calls/requests to this IP:Port
13:06.50JohnWigleyI 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.30JohnWigleySamot: 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.57JohnWigley<PROTECTED>
13:10.51fileyou would need to provide the configuration
13:11.30JohnWigley@file - which parts of the config should I post, the sip.conf section for callcentric?
13:12.13fileyes, and you should also use "sip show peer" to confirm the resolved address for the peer that it is matching
13:12.23JohnWigleyone min...
13:15.36filealso - you must create a peer for all their possible IP addresses or if they send from elsewhere it won't match
13:15.42fileone peer for each.
13:18.11JohnWigleyhttps://pastebin.com/DdH7ateq
13:18.36JohnWigleySorry took a while to delete all the irrelevant config in sip.conf, it had a lot of users/registrations in it.
13:19.07Samot[1777853XXXX] <-- Change that
13:19.45filecallcentric.com can resolve to different IP addresses
13:19.51fileit may not have resolved to what you think.
13:19.58Samotnat = force_rport,comedia <-- Again, Call Centric is not behind NAT
13:20.09JohnWigley@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.09JohnWigleycause them a support nightmare.
13:20.35SamotUhm.
13:22.01SamotAsterisk checks the IP address (and port number) that the INVITE
13:22.01Samot;   was sent from and matches against any devices with type=peer
13:22.33JohnWigley@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.02filebecause the register line and the peer are resolved independently so they can have different IPs?
13:23.10JohnWigley@file AH!
13:23.11filedid you look at the "sip show peer" output to see what the resolved IP address/port was?
13:23.25SamotAlso...
13:23.29JohnWigley@file: Sorry forgot in my haste to paste the sip.conf - will check now.
13:23.33JohnWigleyThat would explain it wouldn't it.
13:23.42SamotI highly doubt their SIP domain is just "callcentric.com"
13:23.57JohnWigleyI followed their asterisk setup guide from their website.
13:24.16JohnWigleyI've seen a lot of ITSPs do that, presumably for vanity reasons.
13:24.33fileSamot: it can be.
13:24.39SamotI know it can be.
13:24.39*** join/#asterisk [TK]D-Fender (~joe@216.191.106.165)
13:25.03SamotI've never seen an ITSP use the main domain
13:25.06filethey do SRV off the domain
13:25.12SamotI've seen sip.callcentric.com
13:25.15SamotI'm sure they can...
13:25.16*** join/#asterisk billxx (49958984@gateway/web/freenode/ip.73.149.137.132)
13:25.21SamotOr some other sub domain
13:25.31JohnWigleyThis 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.50SamotI don't know why you need to match the port
13:25.56SamotYou have a static host.
13:26.21JohnWigleyIt 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.22Samotinsecure=invite,port <-- common for ITSP trunks.
13:27.18fileregistration and inbound matching are independent.
13:27.27JohnWigleyThe insecure=Port option only means that it ignores the port the sip request came from not to though doesn't it?
13:27.46filein chan_pjsip there is an option to use the registration to match inbound, if the upstream supports it.
13:27.52JohnWigleyJust checking the sip show peer output
13:27.52*** join/#asterisk brad_mssw (~brad@66.129.88.50)
13:28.51Samothttps://www.irccloud.com/pastebin/fTI6FFJu/
13:29.29SamotOK so they use callcentric.com
13:29.44SamotBut is there a reason your trunk is missing key settings from their sample configs?
13:30.00SamotFirst off, they say "peer"
13:30.15SamotThey do have insecure=port,invite
13:30.29JohnWigleyhttps://pastebin.com/48iM1iLf
13:30.49filetada.
13:31.01JohnWigley@file: It's exactly as you said, the resolved peer IP is NOT the same as the registration IP - THANK YOU!
13:32.06JohnWigleySamot: 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.08JohnWigleyOk, 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.45JohnWigley@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.39JohnWigleyIn 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.49filenope.
13:42.04JohnWigley@file: didn't think so.
13:43.21JohnWigleyI 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.50SamotYou can't.
13:44.57JohnWigleySamot: why not?
13:45.04SamotNot without using a FQDN that actually resolves to 1 IP.
13:45.12SamotIt's not your DNS?
13:45.15JohnWigleySamot: yes, that's exactly the approach I thought.
13:45.44JohnWigleyNo, obviously I don't have control over callcentric.com but I could use another FQDN that I do have control of.
13:45.51SamotYou can't magically make calls from 4 of their servers look like the same IP.
13:46.33JohnWigleySamot: 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.52SamotOK?
13:47.00SamotThat's for outbound.
13:47.05fileyou can put IP addresses in there...
13:47.09Samot^^^
13:47.18SamotIt would be the IP it would send/take calls from.
13:47.25SamotBut what if they send a call from another server?!
13:47.34SamotYou can't control where the incoming calls are coming from.
13:47.53JohnWigley@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.09SamotThey don't "change" server IPs.
13:48.15SamotThey have multiple hosts.
13:48.26SamotYou don't control which one the call comes from.
13:48.34JohnWigleySamot: 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.39SamotNO
13:48.41SamotThey do not.
13:49.57JohnWigleySamot: 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.59SamotIncoming calls do not have to source from the LOCATION server.
13:50.40SamotAgain, ALL the REGISTER does it tell CallCentric what IP:Port your PBX is at.
13:50.40JohnWigleySamot: 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.46SamotAnd where to send the requests.
13:50.58SamotYOU are the one choosing to only accept calls from a certain place.
13:51.06SamotNo.
13:51.09SamotYou are incorect.
13:51.12SamotYou are incorrect.
13:51.35*** join/#asterisk qxork (~qxork@unaffiliated/qxork)
13:51.51JohnWigleySamot: 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.11JohnWigleyEven Asterisk does the same.
13:52.23SamotThis is kinda what I do.
13:52.41filethat's different than using the same registration server, I've seen them send from different ones
13:52.47SamotI'm pretty sure I understand how ITSP's/Telco's do this.
13:52.49fileand whether it would work or not depends on the NAT implementation
13:52.57JohnWigleyFor TCP/TLS it's actually mandatory that you send subsequent messages back over the same connection flow.
13:53.14fileit's not mandatory, but in practice it's the best thing
13:53.30SamotTwilio sends calls from 5 or MORE proxies.
13:53.45SamotThey do not source from the same location you send a REGISTER to.
13:53.51SamotCallCentric does it.
13:54.08SamotThere are multiple ITSPs that tell you "Our Calls AND/OR MEDIA source from different IPs"
13:54.16JohnWigleyTwillio isn't a consumer ITSP, so I can understand that they would do it.
13:54.29SamotSure they are.
13:54.40SamotThey have a pretty big consumer base.
13:55.08SamotLet's be clear about something...
13:55.14SamotCallCentric is much like me.
13:55.18SamotThey are an aggregator.
13:55.24SamotThey are an aggregate.
13:55.40SamotMost ITSPs "pass-through" their stuff to the upstreams.
13:55.55SamotThey handle Registration but then everything past that is outside them.
13:55.58SamotThey just proxy.
13:56.15JohnWigleyI 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.34SamotBecause they are doing NAT Repair.
13:56.40SamotThey are fixing your bad NAT
13:56.52SamotIt's exactly what I do.
13:57.06SamotThere should be ZERO RFC1819 IPs in your packet.
13:57.24SamotWhen going over the Internet.
13:59.09JohnWigleyok, 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.09JohnWigleyNAT connection to your registration proxy. It just seems insane, you're asking for a support nightmare by doing it.
13:59.44SamotWait...
13:59.47SamotStop.
14:00.51SamotAn ITSP provides the "Class 4" connection.
14:01.14SamotThat is to say, in a broad sense, they give you "dial tone".
14:01.26SamotThey give you a way to receive and send calls to/from the PSTN
14:01.46SamotFeatures like voicemail, call waiting, all that are handle by you because you should have a PBX.
14:02.31SamotIn some cases they will also provider "Class 5" services...
14:02.52SamotWhen you register a Softphone/ATA to them and they provide all those features at their level..
14:03.19SamotBut then you generally end up with a "Traditional Setup"
14:03.35SamotI.e. You only have two call paths, just like a normal POTS line.
14:03.42SamotThey provide you a voicemail box.
14:03.52SamotThey do any call forwarding
14:06.20JohnWigleySamot: 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.21SamotCertain ITSPs/VoIP Providers never expect OR want a PBX on their network. They want Softphones/ATAs.
14:06.33SamotCertain ITSPs ONLY expect PBX systems.
14:06.41SamotBecause it's not required.
14:06.52SamotOr a common practice for certain level ITSPs.
14:06.58SamotALL
14:07.01SamotI mean ALL
14:07.09JohnWigleyOk, 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.10SamotA REGISTER does it tell them WHERE TO SEND REQUESTS
14:07.17SamotNO
14:07.19SamotYou do not.
14:07.28SamotThat is a choice.
14:07.34SamotBy the ITSP/Provider.
14:08.22JohnWigleySo 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.36SamotThat's why there is a market.
14:08.47SamotYou choose the provider that fits your needs.
14:09.16SamotIf 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.32SamotWhere it is "cheap" for them because they basically have almost no infrastructure.
14:09.56SamotThe fact *I* send everything through ONE IP for the most part..
14:10.07SamotMakes me a better option for people in those markets I am in.
14:10.11SamotIt's a bonus for me.
14:10.29SamotBut I also do it because I insist on having control.
14:11.15SamotALL Signalling and Media between the upstreams and my end users go through _me_.
14:13.37SamotYou also keep saying "consumer" without a distinction.
14:14.06SamotA Business Consumer is not treated the same as a "Non-Business/Resi" Consumer.
14:14.25JohnWigleyI'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.25JohnWigleybehind 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.57SamotJohnWigley: Your logic assumes that all users USE Registration.
14:15.04SamotThat's not true.
14:15.21SamotYou're taking the "Non-Business" Consumer look at things.
14:15.36SamotResidential and Business services are not the same.
14:15.42SamotThey are not treated the same
14:16.01SamotThey have different expectations.
14:16.35JohnWigleyNo 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.35JohnWigleyensured you've got an open inbound path BUT not for users that register to you.
14:16.44SamotOK.
14:16.45SamotSo..
14:16.52SamotJust so we can cut to the chase here...
14:17.05SamotI've spent over a decade at ITSPs/Telcos/LECs.
14:17.27SamotWhat you are basically doing is telling me how my job, as an engineer at those places, is being done.
14:18.39JohnWigleyNot 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.52SamotAgain.
14:18.57SamotYou are stuck on this single thread.
14:19.08SamotThe requests do not have to source from where you REGISTER to.
14:19.09SamotPeriod.
14:19.11SamotAt all.
14:19.20SamotIt's a GOOD practice.
14:19.27JohnWigleyOk, so in that case HOW is it expected to work for a user behind NAT?
14:19.45SamotBut larger ITSPs, ones who carter to BUSINESS consumers don't worry about that.
14:19.57SamotBecause in most cases they are handling that themselves.
14:20.27JohnWigleyFinally 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.36SamotWait..
14:20.43SamotNow you are using Asterisk..
14:20.47SamotAnd making a trunk..
14:20.56SamotA trunk that says "I only expect calls from X place"
14:21.01SamotNAT has nothing to do with that
14:21.10SamotYour setup does
14:21.29SamotThis isn't NAT stopping your call.
14:21.36SamotThis is Asterisk DENYING the call.
14:21.36JohnWigleyAgreed
14:21.46SamotBecause of how your configuration.
14:21.53Samotconfigured*
14:21.59SamotAgain..
14:22.22SamotITSPs are pretty open about "We send calls from X amount of IPs/proxies so you need to allow them"
14:22.34SamotAt that point you, as the consumer, have to make a choice.
14:22.42Samot"Do I want to deal with that or not?"
14:23.27SamotThe provider didn't choose you.
14:23.33SamotYou chose the provider.
14:23.54SamotComplaining about their "odd" setup doesn't change that fact.
14:24.05SamotIf 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.25SamotI will give you an example from my perspective.
14:26.34JohnWigleyI 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.34JohnWigleytrying 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.34JohnWigleyI'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.40SamotI'm in markets in New Mexico.
14:26.48SamotWhere ITSPs are not big.
14:27.05SamotWhy? Because the consumers like the "truck roll" aspect of what the Telco's offer there.
14:27.31SamotNew Mexico Telco's still support 7 digit dialing, ITSPs do not.
14:27.46SamotTheir telco's still support some old school methods.
14:28.08SamotSo _all_ the consumers have expectations for service based on that fact.
14:28.17SamotIt is why ITSPs fail their.
14:28.19SamotIt is why ITSPs fail there.
14:28.31SamotI *made a choice* to support 7 digit dialing
14:28.46SamotI *made a choice* to put boots on the ground for truck rolls and service calls
14:29.08SamotI made choices to make my services and offerings more appealing for the consumers in that market.
14:30.43SamotJjohnWigley: Also...
14:30.52SamotJohnWigley: Also
14:31.30SamotThere is a reason CallCentric has all those hosts listed for Asterisk/PBX systems...
14:31.42SamotBecause looking at their services and how they work...
14:31.52SamotA broadband Internet connection.
14:31.52SamotA softphone such as Callcentric's free Softphone; or bring your own Telephone Adapter or IP Phone.
14:31.58Samot^^ That's what they require..
14:32.01SamotYou see..
14:32.08SamotAn ATA or an IP Phone or a Softphone...
14:32.12SamotThose are DUMB devices...
14:32.19SamotThey just accept calls.
14:32.21SamotFrom any IP
14:32.25SamotAny port..
14:32.32SamotSo when you're asking "How can they do this"
14:32.43SamotIt's because they have an EXPECTATION of what the end point is.
14:32.51SamotBecause how they deliver their services....
14:33.00SamotWhen you decide "Hey I'm going to use a PBX"
14:33.24SamotThey say "OK but you need to add ALLLLLLL these hosts for it to work. Because PBXs will want that"
14:34.15SamotThis is _exactly_ what I have been saying.
14:35.19SamotWhen the business model is "95% of our endpoints will be dumb devices and about 5% will be PBXes/smart devices"
14:35.37Samotthe 5% have a lot more hoops to jump through because the network is not geared towards them over all.
14:36.47SamotIn 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.58SamotBecause that's the kind of service they do.
14:37.45JohnWigleyI 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.59SamotSigh
14:38.02SamotPJSIP = SIP
14:38.08SamotIt is just a SIP Stack/Driver.
14:38.13JohnWigleyI meant Pjsip instead of ChanSIP.
14:38.45SamotITSPs support SIP
14:38.52SamotSee now..
14:38.59SamotKamailio is a solution.
14:39.08SamotBecause Kamailo can peer with all 50 hosts
14:39.20SamotAnd send them to the endpoints from ONE source location.
14:39.28JohnWigleyUnless 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.34Samotso you would need to put Kamailio in front of your PBX.
14:39.49SamotChan_SIP allows one host per peer
14:40.13SamotChan_PJSIP will allow multiple.
14:40.27JohnWigleyIt 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.47SamotIt needs to be between call Center and the PBX
14:40.56SamotOne peer between Kamailio and the PBX
14:41.05SamotAnd all the peers between Call Centric and Kamailio.
14:41.49SamotYou should get a provider that supports PBXes as their primary endpoints.
14:42.14SamotNot one that expects ATAs, Softphones, IP Phones and _can do_ PBXes if you do X, Y, Z.
14:42.58JohnWigleySamot: 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.58JohnWigleyre-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.42Samothttps://www.callcentric.com/support/device/asterisk/14
14:43.47SamotSeriously man
14:43.57SamotI'm reading their "How to connect Asterisk to us" docs.
14:44.08SamotThey are pretty clear on how to do this with Chan_SIP and what is needed.
14:44.54SamotThey literally tell you to add 15+ hosts.
14:45.55JohnWigleyAgreed, 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.08SamotBecause they are DUMB DEVICES
14:46.26SamotThey don't care what the source IP or Port is.
14:47.06SamotA PBX and an IP Phone are apples and oranges.
14:47.15JohnWigleySo 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.33SamotThat's also wrong.
14:47.46SamotThe REGISTER is a request sourced by the device behind NAT
14:48.00SamotTherefore, the router should open a "NAT Hole" for that traffic.
14:48.32SamotThis is why devices have Keep-Alive and "NAT" Settings to have them source requests to keep the NAT hole open.
14:48.49SamotAnd why systems like Asterisk have keep alives.
14:49.03SamotTo keep that NAT hole going after the endpoint opened it.
14:49.11JohnWigleyWHAT? 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.11JohnWigleythem an Invite from a completely different IP and expect the endpoint to receive it.
14:49.23SamotOK.
14:49.25SamotAgain..
14:49.30SamotThis is my job.
14:49.35SamotWhat I do 24/7
14:49.53SamotI deploy services to end users like you.
14:50.17SamotI have spent my entire carrier building/supporting SIP/VoIP Telephony networks
14:50.33JohnWigleyIt 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.39SamotYou are literally making end users level arguments
14:51.23filethis is going in circles, just stop
14:51.27SamotYes.
14:52.23SamotThe end result is this: CallCentric is probably not the right provider to use for pure SIP Trunking.
14:52.31SamotBecause it's not their core model.
14:52.42filejust stop :P
14:52.48JohnWigleyJust 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.50SamotThat's  it.
14:52.55fileJohnWigley knows the underlying reason, he can do as he wants
14:53.23SamotHe's a big boy. Can make the choice, I know.
14:53.56SamotFunny part..
14:54.05JohnWigleyok 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.19SamotI agree with him, I don't like ITSPs that source calls from a high amount of proxies.
14:54.32SamotBecause of all the reasons mentioned.
14:54.39SamotIt does become a support nightmare.
14:55.00SamotIt's why I don't do it and why it makes me beat places like that in a sales deal.
14:58.14SamotThis 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.41Samothttps://www.youtube.com/watch?v=W6OaYPVueW4
15:11.09*** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co)
15:18.55JohnWigleyOk, 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.55JohnWigleyper 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.04visipSo... 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-FenderAsterisk can be a PBX
17:14.34[TK]D-FenderThousands already use it
17:28.27jamesaxlvisip: and without problems
17:28.45jamesaxl[TK]D-Fender: do you use SIP or AIX2?
17:29.07[TK]D-Fenderwishes people could spell it properly...
17:29.56visipu wot m8
17:30.34jamesaxl[TK]D-Fender: I can spell of course
17:31.08[TK]D-FenderIAX <--------------
17:31.18[TK]D-FenderAIX = IBM's UNIX OS
17:31.20*** join/#asterisk igcewieling (~ewieling@speedy-02.nyigc.net)
17:31.47jamesaxl[TK]D-Fender: it is just mistake then
17:32.12jamesaxlDo you use IAX2 or SIP?
17:32.16visipHold the presses...
17:32.18[TK]D-Fenderit'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-FenderSIP
17:32.47[TK]D-FenderI have used IAX2 before however
17:37.05*** join/#asterisk paulgrmn (~paulgrmn@198-0-107-153-static.hfc.comcastbusiness.net)
17:40.29jamesaxlI 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-FenderGeneric 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.16PrimerHi. 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.52PrimerHas asterisk worked around NAT + SIPALG recently?
19:36.20filenope.
19:36.28PrimerActually, I just realized that I replaced the route recently, swapping one G1100 for another, due to its wifi having stopped working
19:36.34Primerrouter, that is
19:36.58PrimerIs there any way to tell if SIPALG is being enforced at the NAT, where the NAT is mostly a black box?
19:37.13PrimerI have an admin web interface, and that's it. SIPALG isn't mentioned anywhere.
19:37.33PrimerLet me actually check that, new router and all
19:38.27PrimerI just have to suppose this new router doesn't have it enabled, but asterisk is working as expected all of a sudden
19:38.31PrimerI just hate not knowing
19:40.02Primerbut yeah, it's just working again...oh well, thanks
19:41.01Primeryeah, 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.17Mchammerdadhey 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.00Kobazmmm
21:43.12Kobazis there any way to set the external ip address on an adtran pri gateway
22:05.07SamotWell 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.41igcewielingyour adtran is behind nat?
22:20.00igcewielingor 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.06n\ackWhen did RES_JSON first appear in Asterisk?
23:07.10n\ack...Or is this just somebody's pet project
23:13.07*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
23:16.07Kobazigcewieling: adtran is behind a nat
23:16.20Kobazigcewieling: figured it out... you need to define a loopback interface with the public ip
23:17.43igcewielingWhy not let Asterisk handle the nat?  Is the adtran not connecting to Asterisk?
23:19.03Kobazthere's no asterisk
23:19.06Kobazthat's the issue

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.