Summary:ASTERISK-19677: SIP dial string //IPorHost does not work like expected
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2012-04-09 04:41:55Date Closed:2012-08-03 16:40:21
Versions: 10.3.0 Frequency of
Description:The SIP dial string is supposedly able to take an additional "host-or-ip" parameter which should be used as destination when making an outgoing call. This is new since 1.8.

This value is overruled/ignored on multiple occasions, making it unusable.


- sip_request_call takes the parameter, sets remote_address_sa and passes that to create_addr
- create_addr takes that and puts it in dialog->sa

That's all good. But, when the call attempt is finally made, we get this:

- transmit_invite ... send_request ... __sip_xmit
- __sip_xmit calls sip_real_dst() and that one checks the SIP_NAT_FORCE_RPORT and SIP_NAT_RPORT_PRESENT and returns p->recv instead of p->sa if either is set

Disabling NAT does not help a lot.

- __sip_xmit now returns the right p->sa... but
- when e.g. a 401 is returned from that machine, we reply to the IP found in the To: header instead of to the p->sa that we were communicating with
- therefore our ACK to the 401 goes to the original host=... and
- consequtive packets (invite with auth) does to original host= too

*Steps to reproduce*

Results in:

INVITE => (if nat=no, otherwise is selected here too)
  401 <=
(set_destination: Parsing <sip:123@> for address/port to send to)
(set_destination: set destination to
  ACK =>

*Expected behaviour*

I'd expect to see my packets go to up until the ACK to the 200.


I was using the IPorHost feature because I need to select a proxy at dialplan call time and this was the option that seemed like it would do the trick.

Comments:By: Walter Doekes (wdoekes) 2012-04-09 07:30:58.904-0500

P.S. Using did create a bad Via header too. That is a different bug, but not relevant at the moment. Choose a non-local different host= IP (e.g. to get more practical results.

By: Walter Doekes (wdoekes) 2012-04-09 07:58:45.475-0500

P.S.2. To be on the safe side, I double-checked that the issue was an issue in trunk. It is, and it is even an issue for regular (peer and global) outboundproxy=.

*Steps to reproduce*

outboundproxy=THE_RIGHT_PROXY_IP ; which returns a 4xx


*CLI> channel originate SIP/someuser/123 application Wait 3


Reliably Transmitting (no NAT) to THE_RIGHT_PROXY_IP:5060:
INVITE sip:123@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK5038565c

<--- SIP read from UDP:THE_RIGHT_PROXY_IP:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP;branch=z9hG4bK5038565c;received=MY_EXTERNAL_IP
From: "Anonymous" <sip:Anonymous@anonymous.invalid>;tag=as5cf849ce
To: <sip:123@>;tag=as24899600

--- (10 headers 0 lines) ---
set_destination: Parsing <sip:123@> for address/port to send to
set_destination: set destination to
Transmitting (no NAT) to
ACK sip:123@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK5038565c
From: "Anonymous" <sip:Anonymous@anonymous.invalid>;tag=as5cf849ce
To: <sip:123@>;tag=as24899600
That last one should go to THE_RIGHT_PROXY_IP, but it goes to

With my patch from the reviewboard, the ACK is sent to THE_RIGHT_PROXY_IP if I use a peer-specific outboundproxy. It seems I broke the global outboundproxy though. Will fix, but not today.