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-0600Date Closed:2017-07-25 16:53:39
Status:Closed/CompleteComponents:Channels/chan_sip/General Channels/chan_sip/Interoperability
Versions: 10.12.1 11.2.1 Frequency of
is related toASTERISK-21694 Peer with outbound proxy is resolved in DNS
is related toASTERISK-22666 Outbound proxy ignored after initial invite
Environment:Attachments:( 0) outboundproxy_no_dns.diff
( 1) outboundproxy_no_dns.v2.diff
Description:Using the following sip.conf:
nat = yes
outboundproxy =
srvlookup = no

And the following extensions.conf:
exten => 100,1,NoOp()
   same => n,Dial(SIP/100@belanger.home)

Creates the following full log:
[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@ - 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@
[2013-03-08 19:25:44.717] VERBOSE[23027] chan_sip.c: Really destroying SIP dialog '177e5ce53b54f4320ad6f1113b311316@' 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)
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


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.
       if (ast_connect(s, them)) {
               ast_log(LOG_WARNING, "Cannot connect\n");
               return -1;

Here you stumble upon a related bug, which you might be able to solve at once:

 if you put {{belanger.home}} in your hosts file,
 you'll get 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

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:

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.

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.