ERROR:proxy_response: list_get via failed
Status: Beta
Brought to you by:
tries
Menu
▾
▴
Summary: I'm having trouble getting a Trixbox server sitting behind siproxd to work properly with multiple accounts. I can only get one account registered at a time, and keep getting the error
proxy.c:739 ERROR:proxy_response: list_get via failed
in the logs
Detail:
I'm running siproxd 0.5.13-8 which is shipped with the latest Smoothwall Express 3.0.
I'm running this in transparent mode. Smoothie launches siproxd with the following config:
user = sip
daemonize = 1
registration_file = /var/lib/siproxd/registrations/registrations
pid_file = /var/run/siproxd.pid
rtp_proxy_enable = 1
rtp_timeout = 300
rtp_dscp = 46
default_expires = 600
hosts_allow_reg = 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16
debug_level = -1
if_inbound = eth0
if_outbound = eth1
log_calls = 1
silence_log = 1
rtp_port_low = 7070
rtp_port_high = 7120
rtp_dscp = 46
My trixbox server sits behind this on a NATed LAN.
Whenever I start up the SIP on trixbox, I get only one of the SIP accounts registering with the others sitting there saying "Request Sent".
There is nothing substantially different about the SIP accounts, and I have enabled SIP debugging on asterisk for the one working account and one of the non-working ones. As far as I can tell the registration messages for both accounts are as identical as they can be (copy below).
However, if I tcpdump on the Smoothie Red interface (out to the Internet), I see only SIP messages for the account that works being sent. The other SIP REGISTER messages are not proxied through by siproxd.
If I check the logs I get the following regular error messages which seem to correspond with the other SIP account REGISTER messages:
siproxd: proxy.c:739 ERROR:proxy_response: list_get via failed
Looking at the code, it suggests the only reason this message will appear is if the "Via" field of the REGISTER message is null. However, it seems to there and correctly filled in.
Supporting Data:
First the (sanitized) SIP debug messages, working account first
Reliably Transmitting (NAT) to 217.72.171.58:5060:
REGISTER sip:sip.netcom.co.uk SIP/2.0
Via: SIP/2.0/UDP my_external_ip:5060;branch=z9hG4bK3f315b01;rport
From: <sip:my_user@sip.netcom.co.uk>;tag=as3a862937
To: <sip:my_user@sip.netcom.co.uk>
Call-ID: 4dc3441702b06e6f7e7e8d057c00c45b@127.0.0.1
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Expires: 120
Contact: <sip:my_user@my_external_ip>
Event: registration
Content-Length: 0
Now the non-working one:
Retransmitting #6 (NAT) to 217.10.79.23:5060:
REGISTER sip:sipgate.co.uk SIP/2.0
Via: SIP/2.0/UDP my_external_ip:5060;branch=z9hG4bK6f83f493;rport
From: <sip:my_user@sipgate.co.uk>;tag=as70522e71
To: <sip:my_user@sipgate.co.uk>
Call-ID: 7df231a855145b890ef6dfb1201896c8@127.0.0.1
CSeq: 104 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Expires: 120
Contact: <sip:my_user@my_external_ip>
Event: registration
Content-Length: 0
And a snippet from the RED Interface TCP Dump:
20:21:06.236478 IP (tos 0x68, ttl 63, id 62028, offset 0, flags [none], proto UDP (17), length 608) my_external_ip.sip > voip.netcom.co.uk.sip: SIP, length: 580
REGISTER sip:sip.netcom.co
(Tcpdump was done with tcpdump -vv -i eth1 udp port 5060 )
Does anyone know what's going on here?
I'm going to post this in the Smoothwall Express forum for information, although it seems to me to be something inherently with siproxd which is causing this.
Cheers,
Keith
The error "siproxd: proxy.c:739 ERROR:proxy_response: list_get via failed " lets me assume that the request was proxied fine but the *RESPONSE* sent back from the registrar could not be processed by siproxd and has been discarded.
You also may want to try the latest siproxd snapshot and check if the error still persists.
!!!
A note on Asterisk and using multiple SIP accounts.
Asterisk (at least with release 1.4) does match its SIP accounts (peers) only based on the IP address. So it can not properly distinguish between multiple SIP accounts that are hosted on the same SIP registrar (e.g. if you have multiple sipphone.com accounts and want to have them as SIP trunks on the same Asterisk bos, this will not work. The first account will properly register and the second one will not).
Using Asterisk with siproxd as outbound proxy does make this problem even worse. As siproxd does act as a proxy, all traffic (UDP packets) received from the Asterisk box will have the IP address of siproxd. And asterisk will fail in matching the incoming SIP packets to their SIP accounts.
IMO this is a wrong design on how Asterisk does the matching of SIP traffic to its SIP peers.
As I myself do use exactly this (Asterisk + siproxd) I did a quick and dirty patch that tries to find an Asterisk SIP peer by examination of the SIP header data and not the IP address.
I'll make the patch available for download. But let me have said this. It works for me, but I'll provide no support at all. If you want to try it, you are on your own. The patch is against Asterisk version 1.4.
URL: http://siproxd.sourceforge.net/index.php?op=snapshot
File: asterisk_chan_sip_xar.patch
Thanks for the response...
> The error "siproxd: proxy.c:739 ERROR:proxy_response: list_get via failed "
> lets me assume that the request was proxied fine but the *RESPONSE* sent
> back from the registrar could not be processed by siproxd and has been
> discarded.
That was my first assumption. However, when I tested it it turned out to be incorrect: sniffing the traffic on the internet side of siproxd I don't see the requests being proxied.
> Asterisk (at least with release 1.4) does match its SIP accounts (peers)
> only based on the IP address. So it can not properly distinguish between
> multiple SIP accounts that are hosted on the same SIP registrar (e.g. if
> you have multiple sipphone.com accounts and want to have them as SIP
> trunks on the same Asterisk bos, this will not work. The first account
> will properly register and the second one will not).
This isn't relevant in this situation as all my SIP accounts have different addresses. In the example I posted the addresses are:
217.72.171.58 &
217.10.79.23
There is something else wrong.
> You also may want to try the latest siproxd snapshot and check if the
> error still persists.
I'll see if I can try this. I'm not sure how easy this will be as I have to compile it on a different box.
> I'll make the patch available for download. But let me have said this.
> It works for me, but I'll provide no support at all. If you want to try it,
> you are on your own. The patch is against Asterisk version 1.4
Thanks for this, but the problem you describe isn't the one I'm having.
I'm also using Trixbox 2.2.4 which currently uses Asterisk 1.2.23.
I'm happy to capture a full debug dump with debug set to -1 and tcpdumps, but I 'm not happy about posting it anywhere public as stripping the confidential information from them is likely to be difficult.
Cheers,
Keith
A siproxd debug log can be mailed directly to my SF email account. I then will see what I get from it.
The Asterisk issue I desribed *will* become an issue when the ERROR from siproxd has been resolved (as siproxd acts al Application Layer Proxy, all incoming traffic from external SIP services will be proxied by siproxd and Asterisk sees them coming from then inbound IP address of siproxd.
Regards,
/Thomas