[Home]

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
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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:
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:
{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.