[Home]

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
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.11.0 10.3.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.

*Problem*

- 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*
{noformat}
[sipuser]
host=127.0.0.2
{noformat}
{noformat}
Dial(SIP/sipuser/123/1.2.3.4)
{noformat}

Results in:

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

*Expected behaviour*

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

*Why?*

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.


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

P.S. Using 127.0.0.2 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. 4.3.2.1) 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*

{noformat}
[general]
outboundproxy=THE_RIGHT_PROXY_IP ; which returns a 4xx

[someuser]
host=4.3.2.1
type=friend
{noformat}

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

*Results*

{noformat}
Reliably Transmitting (no NAT) to THE_RIGHT_PROXY_IP:5060:
INVITE sip:123@4.3.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK5038565c
...

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

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

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.