Summary: | ASTERISK-21231: When outboundpoxy is set, asterisk should not attempt to resolve DNS | ||||||
Reporter: | Paul Belanger (pabelanger) | Labels: | |||||
Date Opened: | 2013-03-09 15:37:04.000-0600 | Date Closed: | 2017-07-25 16:53:39 | ||||
Priority: | Major | Regression? | No | ||||
Status: | Closed/Complete | Components: | Channels/chan_sip/General Channels/chan_sip/Interoperability | ||||
Versions: | 1.8.20.1 10.12.1 11.2.1 | Frequency of Occurrence | Constant | ||||
Related Issues: |
| ||||||
Environment: | Attachments: | ( 0) outboundproxy_no_dns.diff ( 1) outboundproxy_no_dns.v2.diff | |||||
Description: | Using the following sip.conf:
{code} [general](+) nat = yes outboundproxy = 209.87.247.153 srvlookup = no {code} And the following extensions.conf: {code} [ivr-polybeacon.com] exten => 100,1,NoOp() same => n,Dial(SIP/100@belanger.home) {code} Creates the following full log: {code} [2013-03-08 19:25:44.715] DEBUG[23027] pbx.c: Launching 'NoOp' [2013-03-08 19:25:44.715] VERBOSE[23027] pbx.c: -- Executing [100@ivr-polybeacon.com:1] NoOp("SIP/kamailio-01-prod-00000020", "") in new stack [2013-03-08 19:25:44.715] DEBUG[23027] pbx.c: Launching 'Dial' [2013-03-08 19:25:44.715] VERBOSE[23027] pbx.c: -- Executing [100@ivr-polybeacon.com:2] Dial("SIP/kamailio-01-prod-00000020", "SIP/100@belanger.home") in new stack [2013-03-08 19:25:44.715] CC[23027] ccss.c: Agent policy for SIP/kamailio-01-prod-00000020 is 'never'. CC not possible [2013-03-08 19:25:44.715] DEBUG[23027] chan_sip.c: Asked to create a SIP channel with formats: 0x4 (ulaw) [2013-03-08 19:25:44.715] DEBUG[23027] chan_sip.c: Allocating new SIP dialog for 177e5ce53b54f4320ad6f1113b311316@209.87.247.153:5062 - INVITE (No RTP) [2013-03-08 19:25:44.715] DEBUG[23027] rtp_engine.c: Using engine 'asterisk' for RTP instance '0x1af47e8' [2013-03-08 19:25:44.715] DEBUG[23027] res_rtp_asterisk.c: Allocated port 13420 for RTP instance '0x1af47e8' [2013-03-08 19:25:44.715] DEBUG[23027] rtp_engine.c: RTP instance '0x1af47e8' is setup and ready to go [2013-03-08 19:25:44.715] DEBUG[23027] res_rtp_asterisk.c: Setup RTCP on RTP instance '0x1af47e8' [2013-03-08 19:25:44.715] VERBOSE[23027] netsock2.c: == Using SIP RTP CoS mark 5 [2013-03-08 19:25:44.715] DEBUG[23027] chan_sip.c: Setting NAT on RTP to On [2013-03-08 19:25:44.715] DEBUG[23027] chan_sip.c: OBPROXY: Applying global OBproxy to this call [2013-03-08 19:25:44.716] DEBUG[23027] netsock2.c: Splitting 'belanger.home' into... [2013-03-08 19:25:44.716] DEBUG[23027] netsock2.c: ...host 'belanger.home' and port ''. [2013-03-08 19:25:44.717] ERROR[23027] netsock2.c: getaddrinfo("belanger.home", "(null)", ...): Name or service not known [2013-03-08 19:25:44.717] WARNING[23027] chan_sip.c: No such host: belanger.home [2013-03-08 19:25:44.717] DEBUG[23027] chan_sip.c: Cant create SIP call - target device not registered [2013-03-08 19:25:44.717] DEBUG[23027] chan_sip.c: Destroying SIP dialog 177e5ce53b54f4320ad6f1113b311316@209.87.247.153:5062 [2013-03-08 19:25:44.717] VERBOSE[23027] chan_sip.c: Really destroying SIP dialog '177e5ce53b54f4320ad6f1113b311316@209.87.247.153:5062' Method: INVITE [2013-03-08 19:25:44.717] DEBUG[23027] rtp_engine.c: Destroyed RTP instance '0x1af47e8' [2013-03-08 19:25:44.718] WARNING[23027] app_dial.c: Unable to create channel of type 'SIP' (cause 20 - Unknown) [2013-03-08 19:25:44.718] VERBOSE[23027] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1) {code} | ||||||
Comments: | By: Paul Belanger (pabelanger) 2013-03-09 15:41:00.432-0600 belanger.home is SIP domain within my proxy (kamailio). Obviously if you try to resolve it outside of that, the DNS will fail. In this scenario, when outboundproxy is set, I don't believe asterisk should attempt to resolve it. By: Paul Belanger (pabelanger) 2013-03-09 15:46:10.866-0600 Based on some code that oej[1] has done for 1.4, the follow patch comes from it. [1] http://svnview.digium.com/svn/asterisk?view=revision&revision=53289 By: Paul Belanger (pabelanger) 2013-03-09 17:35:21.745-0600 v2 By: Leif Madsen (lmadsen) 2013-03-09 19:14:11.462-0600 Makes sense to me. I wanted to acknowledge this but figured I should let @newtonr handle this for import for prioritization. Habits die hard :) By: Paul Belanger (pabelanger) 2013-03-10 20:49:05.579-0500 I should note, my patch results in the following: [2013-03-10 21:39:50.285] WARNING[24629] acl.c: Cannot connect Trying to chase it down. By: Walter Doekes (wdoekes) 2013-03-11 03:04:56.424-0500 {{dialog->sa}} is now unset... but you're still setting stuff on it. And finally we get here when deciding what our sent-by address is for this outbound message. {noformat} if (ast_connect(s, them)) { ast_log(LOG_WARNING, "Cannot connect\n"); close(s); return -1; } {noformat} Here you stumble upon a related bug, which you might be able to solve at once: if you put {{belanger.home 127.0.0.1}} in your hosts file, you'll get 127.0.0.1 in the Via sent-by even though your proxy is on the "outside" If you set {{dialog->sa}} to the outboundproxy ip:port in {{createaddr}} you might fix that second bug at the same time. Unfortunately deciding whether you're not breaking something else at the same time is a bit trickier ;) By: Olle Johansson (oej) 2013-08-27 10:12:28.563-0500 The outbound proxy support has been broken so many times I've stopped counting... That patch is very old and 1.4 has changed quite a lot since. I don't think the patch works with 1.8 since a lot of things was changed when adding IPv6, TCP and TLS. We need to revisit this and fix the LTS releases. By: Joshua C. Colp (jcolp) 2013-09-13 08:54:54.405-0500 I now have a patch up for review at https://reviewboard.asterisk.org/r/2851/ which removes this requirement and returns outbound proxy support to a working state. Once complete and shipped this will be merged into all current branches. If you have time though please give this a go. I've tested it myself but more eyes on it are always good. By: Dalius M. (mdalius) 2014-02-07 07:10:42.012-0600 Hello, I have seen this patch was nearly commited but later somehow it was discarded. Why? We need it, because now outboundproxy setting does not work. By: Matt Jordan (mjordan) 2014-06-11 15:15:16.988-0500 From ASTERISK-21694: {quote} I've attached a patch which resolves this issue but due to lack of feedback/testing and potential regressions I am not going to commit it. If the situation changes and we become more comfortable then we can re-visit this. {quote} Outbound proxy settings are tricky and can easily break existing configurations. Blindly applying the patch without sufficient testing and support from those who reported these issues would lead to a lot of gnashing of teeth - which I think we'd like to avoid :-) If you'd like to test out the patch [~jcolp] wrote, please do so and comment on this or the other issue. Until there's sufficient support for a solution, however, a patch will not be merged. By: Rusty Newton (rnewton) 2017-07-25 16:53:39.568-0500 Cleaning up the issue tracker. There has been no movement on this issue for three years and chan_sip is now under extended support. If anyone wants to test this against a supported version and move it through the review process then please request that we reopen the issue. Otherwise we are closing this out for now. |