IRC log for #asterisk on 20180203

00:06.06*** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68)
00:13.45*** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-gzwywlyvqyyssmde)
00:24.45*** join/#asterisk robink (~quassel@unaffilated/robink)
00:46.10*** join/#asterisk jkroon (~jkroon@165.16.204.166)
00:47.57*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
00:48.08kunwon1n\ack: i don't think it's in core
01:18.55*** join/#asterisk infobot (ibot@rikers.org)
01:18.55*** 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:23.38*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
01:34.44*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
01:45.00*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
01:48.30n\ackkunwon1: looks like that to me too. Thanks.
01:55.44*** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407)
02:17.03*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
02:27.52*** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407)
02:50.06*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
03:03.30*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
03:09.40*** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407)
03:19.53*** join/#asterisk [TK]D-Fender (~joe@64.235.216.2)
03:21.25*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
03:27.09*** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-vowubnvjmelkroer)
04:17.43*** join/#asterisk Dirk23 (Dirk23@diehildebrands.de)
04:26.29*** join/#asterisk cryptic_ (~cryptic@142.196.170.87)
04:33.28*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
05:22.52*** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407)
05:31.19*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
05:51.29*** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl)
06:04.05*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
06:18.32*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
06:22.21*** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com)
06:50.06*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
07:20.17*** join/#asterisk hfb (~hfb@cpe-108-185-247-93.socal.res.rr.com)
07:28.56*** join/#asterisk tzafrir (~tzafrir@37.26.148.173)
07:47.50*** join/#asterisk Oatmeal (~Suzeanne@47.51.5.154)
08:07.01*** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru)
08:11.11*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
08:15.39*** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl)
08:24.54*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
08:39.27*** join/#asterisk miralin (~Thunderbi@91.237.94.2)
08:50.27*** join/#asterisk jamesaxl (~James_Axl@109.172.62.242)
09:03.07*** join/#asterisk lowin (~lowin@unaffiliated/lowin)
09:04.35lowinHi, I've got a problem. When a client disconnects from the internet within a call (so no hope of sending bye request) the call remains active in asterisk. Is there a way to define a timeout timer to drop the call when no rtp packets are received within a period of time?
09:17.05lowinsilly me, found the solution as soon as I asked about it in irc ^^
09:28.35*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
09:33.48Worldexeisnt it 30seconds by default? )
09:34.25*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
09:53.29*** join/#asterisk ChannelZ (~bobm@burner.com)
10:01.55*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
10:02.44ChannelZHmmm. Anyone go from Asterisk 14 to 15 using pjsip and outgoing RTP just completely not working?
10:03.12*** part/#asterisk comrad (~comrad@holarse/core/comrad)
10:06.44*** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net)
10:16.32*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
10:17.48*** join/#asterisk miralin (~Thunderbi@91.237.94.2)
10:22.43*** join/#asterisk areski (~areski@37.223.2.207)
10:29.02ChannelZLooks like under 15, Asterisk is telling my phone its WAN IP instead of the LAN IP like it's supposed to.
10:40.56*** join/#asterisk Dirk23 (Dirk23@diehildebrands.de)
10:40.59*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
10:49.16*** join/#asterisk Helena (d49f2d5f@gateway/web/freenode/ip.212.159.45.95)
10:49.55HelenaI'm a visual learner and I find all the books too technician which is fine, it's a technical book, but there are not enough visuals to support me with it.
10:50.11HelenaAnyway, heres the fuss and the problems it has caused.
10:50.13Helena[Feb  3 10:42:32] NOTICE[4652][C-00000000]: chan_sip.c:26401 handle_request_invite: Call from '2001' (10.1.1.254:49822) to extension '9123' rejected because extension not found in context 'friends-internal'.
10:50.38HelenaI'm gonna run my extensions.conf through a pastebin, 1min.
10:51.42HelenaI've tried a combo of guess work, so things could be fragmented in there.
10:52.10Helenahttps://paste.debian.net/1008637/
10:53.02Helenaand my sip.conf https://paste.debian.net/1008638/
10:56.27ChannelZtype-o - your extensions.conf context is called "freinds-internal" instead of "friends-internal"
10:58.14HelenaHaaaaaah!
10:58.18HelenaChannelZ: xD
10:58.21HelenaThanks
10:58.31ChannelZSure. It happens
10:58.33HelenaThat was camaflaged
11:02.33HelenaI corrected that and reloaded but the same issue, I think it has something to do with line 5-8 of extensions.conf, I'm basically trying to get my dailout code 9 to work with dahdi, but I've somehow got my context wrong.
11:03.28ChannelZyou get 'extension not found'?
11:05.29ChannelZoh.. because _9X only matches 9 plus one other character.. if you're dialing 9123 for instance, it won't match that extension
11:07.13HelenaAaaaaah! so that's what the X means!, so if I was to do _9XXX, I would then be able to dial a 3 digit number?
11:07.20HelenaLets try that...
11:07.49ChannelZYes
11:08.29HelenaThen in that case, same problem. I'm gonna be doing a lil Googling too
11:08.57ChannelZX means any digit 0-9. N means anything 1-9. Something like _NXXNXXXXXX is generally used for the US number plan
11:10.42HelenaI was just tryna dial a 3 digit extension from my ISP atm just to test.
11:11.36Helenathat's also my telephone provider
11:11.41SamotUhm.
11:11.57ChannelZWell show your updated extensions.conf and console output if you like since now we don't know what you've got going on with changes
11:12.44SamotYeah.
11:12.51SamotWhere is an actual debug.
11:13.04ChannelZalso you're using a (channels) template but I don't know what that is, is the dialplan actually even loading at all?
11:13.26ChannelZ'dialplan show' on the console will tell all
11:14.20Samot[freinds-internal](channels)
11:16.01*** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru)
11:16.09SamotThere's no templates in dialplan.
11:16.13HelenaWhat would be the best way of debugging?
11:16.15SamotThose are for settings.
11:16.20Samotasterisk -rvvvvvvvvvvvvv
11:16.22Samot^^^
11:16.53Samot6:14:18 AM S<Samot> [freinds-internal](channels) <-- Wrong
11:17.03HelenaSo there's 13 verbosity levels, or more?
11:17.06ChannelZyeah I'm guessing the dialplan parser is failing
11:17.17SamotBecause you have that
11:17.22SamotGet rid of (channels)
11:17.32SamotThat's not valid in dialplan.
11:17.56ChannelZ(last I checked nothing logged over verbose 6 or so, if I remember)
11:18.12SamotNo.
11:18.16*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
11:18.21SamotVerbose 10 is about the highest you can go
11:18.29SamotAnything beyond that doesn't do much
11:24.19SamotHow long does this take?
11:25.34ChannelZPick a number between 1 and infinity
11:28.33SamotHelena: ???
11:28.58HelenaSorry I was in deep research
11:29.06Helena1min
11:29.19HelenaI'll get some debug information and updated config contents now.
11:31.22ChannelZbed time for me
11:33.31HelenaChannelZ: Nite :)
11:34.52HelenaHere is my debug log. https://ssl.thorsen.pm/paste/6e51502e7733
11:35.54SamotWhat is this?
11:36.09SamotBecause it's absolutely not what was requested or the command that was given.
11:36.33Samotcore set debug 0
11:36.37Samotcore set verbose 10
11:36.39Samotmake call.
11:36.42SamotShow output.
11:44.15SamotOK. I'm moving on.
11:45.05*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
11:45.34HelenaAnd here is the log, but I think it looks the same, I tried relying on command line flags, rather than entering commands in the Asterisk console so I could run through nopaste, here you go https://ssl.thorsen.pm/paste/f1f98788ceb3
11:46.39SamotThis is not what I was asking for.
11:46.42SamotAt all.
11:46.46SamotIt has nothing helpful for this.
11:47.05SamotI gave you the commands to run for this debug and you're actively not doing it.
11:47.32HelenaIs there a way of piping output from within the Asterisk console?
11:47.45SamotEnter the console.
11:47.49SamotRun the commands I said
11:48.01SamotCopy and paste the scroll back
11:49.38*** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com)
11:59.52SamotOf course
12:26.29*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
13:10.04*** join/#asterisk K0HAX (~michael@28.139.154.104.bc.googleusercontent.com)
13:17.39*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
14:09.18*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
14:13.33*** join/#asterisk qxork (~qxork@unaffiliated/qxork)
14:15.46*** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68)
14:16.08*** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407)
14:47.56*** join/#asterisk pmden_ (~pmden@fsf/member/pmden)
14:57.29*** join/#asterisk cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
14:57.30*** mode/#asterisk [+o cresl1n] by ChanServ
15:02.18*** join/#asterisk Catatronic (~corrupt@unaffiliated/catatronic)
15:14.42*** join/#asterisk jamesaxl (~James_Axl@109.172.62.242)
15:45.50*** join/#asterisk pmden_ (~pmden@fsf/member/pmden)
16:10.18*** join/#asterisk [TK]D-Fender (~joe@64.235.216.2)
16:18.11*** join/#asterisk wyoung (~wyoung@wesleyy.com)
16:20.38*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
16:21.57*** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru)
16:34.33*** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com)
16:55.44*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
17:00.21*** join/#asterisk yokel (~yokel@unaffiliated/contempt)
17:11.37*** join/#asterisk dstewart (~dstewart@unaffiliated/blast-hardcheese/x-0199635)
17:12.13*** part/#asterisk dstewart (~dstewart@unaffiliated/blast-hardcheese/x-0199635)
17:14.11*** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635)
17:17.11*** join/#asterisk davlefouAMD (~davlefouA@cantaron.reveyo.com)
17:32.19*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
17:46.58blast_hardcheesePlease pardon the basic question; I've inherited an Asterisk setup (Primarily Fax use case, set up with spandsp, ulaw T.30). Network connectivity seems to be good, as I was able to send hundreds of faxes one at a time with 100% success. As soon as I send more than _two_, however, I see no packets transferred in sip show channelstats for all the channels after the first two. I've read plenty of
17:47.04blast_hardcheesearticles about people achieving amazing concurrency, I expect there's just something misconfigured but I'm not sure where to start.
17:48.39blast_hardcheesePoking around in Wireshark, for one of the failed faxes I see -> Invite SDP g711U, <- 100 Trying, (30 seconds pass), -> Cancel
17:49.27blast_hardcheesewhile that does look like a timeout from the sender's perspective, as there have been no packets exchanged from that point, I'm not sure raising it will help anything
17:50.44blast_hardcheeseI'm not a telephony guy, I just have a bit of sysadmin/software development experience
17:58.05Worldexemaybe, RTP port range is not NATed/allowed through firewall somewhere
17:58.29Worldexewell, at least some ports of that range
18:00.23blast_hardcheeseI've got the pcap up, I should be able to verify that
18:03.25*** join/#asterisk u0m3 (~u0m3@5-12-251-34.residential.rdsnet.ro)
18:22.57*** join/#asterisk paulgrmn_ (~paulgrmn@184.75.212.68)
18:27.30blast_hardcheeseI'm not seeing it even attempt to establish RTP
18:37.01*** join/#asterisk dar123 (~dar@2600:1700:38d0:1470:b566:5424:a367:d407)
19:12.19*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
19:24.06drmessanoblast_hardcheese:
19:24.28drmessanoYou can send hundreds of faxes without a problem, but as soon as you send more than _two_ x occurs?
19:24.33drmessanoNot sure what that means
19:24.45blast_hardcheeseone at a time vs concurrently
19:25.13drmessanoOk, you left that out.  Are you sure the provider doesn't have a channel limit?
19:26.58blast_hardcheeseUnlkely, would this show up in any logs?
19:28.09drmessanoUnlikely?
19:28.18drmessanoWhat do you base that on?
19:28.49drmessano2 channels is nice round number for a concurrent call limit for some providers, depending on the provider and account type
19:28.52drmessanoWho is the provider?
19:29.27blast_hardcheeseLet me verify, but I'm pretty sure this happens just talking between two asterisk boxes on the local network as well
19:30.28drmessanoWho is the provider?
19:35.13blast_hardcheeseI'm sorry, I don't know. Even verifying that this isn't an issue on the local network would be enough to at least know asterisk/opensips/spandsp isn't misconfigured in some way
19:36.01drmessanoThere's no misconfiguration that would limit to 2 channels except a limit in the peer config or the provider limiting channels
19:37.30drmessanoWhy dont you enable SIP debug and look at the debug
19:37.39drmessanoor just look at the peer itself
19:38.10drmessanoIf you have the IP addresss of the peer from the peer definition in sip.conf, i can be googled
19:38.24drmessanoit*
19:39.01drmessanoBut almost certainly all flat rate ITSP plans are limited to 2 channels
19:39.08drmessanoand everything after simply fails
19:39.50drmessanoSo before you dismiss it as "unlikely" maybe check a little into where the call is going
19:41.04blast_hardcheeseOk, I appreciate the advice; I'll ask around at work and check back
19:41.14blast_hardcheeseI'll also take a look at the debug logs
19:42.37*** join/#asterisk degenerate (~degenerat@S0106689e199caaf4.no.shawcable.net)
19:48.05*** join/#asterisk znoteer_ (~znoteer_@69-196-143-108.dsl.teksavvy.com)
19:53.32*** join/#asterisk Catatronic (~corrupt@unaffiliated/catatronic)
19:54.35blast_hardcheeseThanks again
20:08.18*** join/#asterisk areski (~areski@37.223.2.207)
20:20.35*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
20:25.53SamotOh they left.
20:27.10Samotdrmessano: Sound theory but it looks like a codec issue. T.30/Ulaw = G711 Pass-Thru. Though they both could be related.
20:35.41*** join/#asterisk robink (~quassel@unaffilated/robink)
20:45.51*** join/#asterisk Larloch (~Mchammerd@96-18-0-34.cpe.cableone.net)
20:54.34drmessanoHow is it a codec issue?
20:57.53SamotMight not be. The only thing i can think of is either the other side wanted t.38 only or the SDP is wrong. So "codec" was too narrow. RTP/media would have been better.
20:58.33SamotBut..depending on the provider they could be handling the over capacity oddly like that
20:59.19SamotBut the 30 second drop after it connects usually means asterisk isnt getting rtp
21:00.31SamotBut your points are 100% valid about being a issue with concurrent calls.
21:05.17*** join/#asterisk _marshy (~a@173-31-143-215.client.mchsi.com)
21:06.31_marshyquick question about call forwarding to an external number... does the asterisk box still responsible for the call once it's connected? i.e. if the asterisk box goes down once it's forwarded, is the call dropped?
21:06.43_marshy-does +is
21:08.36SamotThe call is dropped.
21:08.46SamotAsterisk is still handling that call.
21:09.01SamotThe call still came into Asterisk and went out Asterisk.
21:21.45*** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com)
21:25.43*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
21:27.11_marshyis there a way to not have that happen?
21:27.30_marshy@ Samot
21:34.01SamotNo.
21:34.09SamotAsterisk is in the path.
21:34.18SamotThe call is bridged there
21:34.38SamotIt cant magically bridge the two calls at the PSTN
21:35.40*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
21:40.10_marshyI was afraid of that
21:40.46*** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire)
21:42.48[TK]D-FenderWell there is a "maybe" attached, but highly conditional
21:43.13[TK]D-Fenderon PRI this is possible, though you're still billed for the calls however appropriate to each leg.
21:43.29[TK]D-FenderI suspec a few ITSP's might make that possible as well on a reinvite.
21:43.32[TK]D-Fenderbut most won't
21:44.09_marshyhow difficult is that to set up?
21:44.18_marshy(for a beginner)
21:49.39[TK]D-Fenderfirst what are these calls over?
21:51.20SamotThe maybe is that the call forwarding isn't done in Asterisk.
21:55.57SamotThere is no "call forwarding" in Asterisk. There is Dial()
21:56.12_marshyinteresting
21:56.16[TK]D-FenderWell there is actually depending on a few things
21:56.37SamotWhether or not the is to an endpoint or back out a peer/trunk to the PSTN
21:56.40_marshy[TK]D-Fender: I'm not sure exactly what you mean by that. but asterisk is sitting on a vps
21:56.47[TK]D-FenderDAHDI PRI can do a 2BCT which is a pure hand-off, and there is Transfer() which has to be deliberate to toss a SIP call off for example
21:57.39SamotAnd where does the forwarding happen with the 2BCT?
21:57.51SamotNot at Asterisk?
21:58.14[TK]D-Fenderat the PRI signalling level with the telco
21:58.38[TK]D-Fendertells the telco to recall the 2 B chans and brige at the telco and * ddrops both legs
21:58.44[TK]D-Fenderfreeing up those 2 channels
22:02.03_marshysounds a bit complex for a personal set-up
22:02.52*** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-hnrjunkxopagectr)
22:02.53SamotSo as I said, not at Asterisk.
22:03.20SamotIf the is processed by asterisk then asterisk is in the path
22:05.18*** join/#asterisk syadnom (~syadnom@host-72-174-216-132.bln-mt.client.bresnan.net)
22:05.29syadnomhi all, hope someone is awake today
22:05.37[TK]D-Fender* is involved in the hand-off
22:05.42syadnomwondering about asterisk and real-time mysql latency.
22:06.11syadnomspecifically, using mysql router to split reads/write between a local slave and a remote master.
22:06.33SamotThe question was "if during the forwarded call asterisk dies does the call die"
22:06.54SamotWhat you stated is during setup not during the call
22:07.11SamotAt the point Asterisk is not involved in the call
22:08.59syadnomassuming the connections stay up and there is no packet loss, can asterisk play well with a database write <=200ms away?
22:10.30drmessanoSamot:
22:10.31drmessanoT.30/Ulaw = G711 Pass-Thru
22:10.39drmessanoNo mention of t.38
22:10.40syadnomI should add, stuck on chan_sip
22:11.33SamotRight.
22:11.48SamotWhy I said, the other side wants it and only that so the media never flows.
22:11.59SamotBut who knows really, we're both just reaching.
22:12.12SamotWe never saw anything concrete to show what the actual issue could be.
22:12.13drmessanoI don't think he's using T.38 at all
22:12.18SamotI know.
22:12.27Samotcan't guarantee the outbound route via the ITSP
22:12.42drmessanoUhm
22:12.47SamotIt could be a variety of things, what you said is totally valid.
22:12.49drmessanoThats not what I am saying
22:12.58SamotI know what you are saying.
22:13.05drmessanoI don't think there is an EXPECTATION of using T.38 at all
22:13.12SamotProbably true.
22:13.14drmessanoNot "I dont think T.38 is working"
22:13.23SamotThat's not what I said.
22:13.32SamotI wasn't talking about his side.
22:13.43drmessanoI wasn't talking about his side either
22:14.05SamotAs I said, what you said could be right.
22:14.30drmessanoIt's failing at N+2 calls, exactly
22:14.38SamotThere was not to show if the 30 seconds was due to not RTP
22:14.43drmessanoThere's no sudden T.38 breakdown at a third call in any scenario
22:14.55SamotOr just not hearing the congestion tones.
22:14.58drmessanoIt's a concurrency limit
22:15.09SamotThen a 603 or 503 should be sent back
22:15.18SamotNot 30 seconds of dead air.
22:17.23drmessano12:48:39 <blast_hardcheese> Poking around in Wireshark, for one of the failed faxes I see -> Invite SDP g711U, <- 100 Trying, (30 seconds pass), -> Cancel
22:18.08drmessanoThat's not a timeout
22:20.16SamotYou could be right.
22:20.23SamotI could be pissing in the wind.
22:20.42SamotI saw nothing to disprove or prove either of our theories.
22:21.05drmessanoI see a bunch of invites being sent
22:21.15drmessanoAt N+2
22:21.18drmessanoreproducable
22:21.51SamotSure.
22:22.07SamotBut 30 seconds followed by cancel is the wrong way to handle it.
22:22.16SamotI accept your resolution.
22:22.40SamotThe data is just funky.
22:23.41Samot100 Trying <-- that should be a 503 Service Unavailable or a 603 Declined. There should be no 1XX reply for a concurrency limit or denying/rejecting the call.
22:26.24*** join/#asterisk troyt (~troyt@2601:681:4100:711:44dd:acff:fe85:9c8e)
22:30.12ChannelZOK.. so.. pjsip.. I have a [lan] transport with bind=192.168.1.1 and a [wan] transport bound to my real IP and have local_net and the external addresses configured on that.
22:31.11ChannelZCurrently running Asterisk 14, all is well and everything works. Asterisk tells my phone to send RTP to 192.168.1.1, and gives out the public IP to my ITSP on the wan transport.
22:32.13ChannelZHowever, under Asterisk 15, it's giving out the WAN IP to my phone, instead of the LAN IP.
22:32.45*** part/#asterisk vt (~vt@osa.vbc.su)
22:34.26ChannelZUPGRADE notes don't mention much from 14->15 but obviously something has changed in/with pjsip (I guess)
22:40.54*** join/#asterisk Offer (~Offer@80.74.123.8)
22:54.17*** join/#asterisk Samael28 (~Samael28@176.104.56.91)
23:36.15*** join/#asterisk elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net)
23:54.00*** join/#asterisk tzafrir (~tzafrir@2a02:a03f:3f0d:c600:f26f:1f1a:b94:ba03)

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