Hi everyone,
I doing some tests using calls originated from many IP address, but using a same IP address at the Via header of the SIP message. However, Asterisk has ignoring the Via header and sends the responses to IP address from which the request came. How to force Asterisk to use the address contained in the Via header?
Thanks in advance.
In the case of chan_sip you would need to set nat=no or in the case of chan_pjsip then force_rport=no on the endpoint.
Defining the peers as on the local network should also disable the forced rport behaviour. NB, if the via header contains rport, I’m not sure that you can override it.
Also note that the handling of maddr, in chan_sip, is flakey.
Thanks for the reply. I set “nat=no” on the sip.conf file but this not resolve my issue 
What is the complete configuration, and what is the result of “sip set debug on” with a call coming in?
My sip.conf:
[general]
bindport = 5060
bindaddr = 0.0.0.0
disallow = all
allow = alaw,ulaw,gsm
context = seven
nat=no
insecure = port,invite
[2001]
type=friend
host=dynamic
secret=2001
context=seven
All calls are made from unregistered user agents and these calls are intended to 2001 extension.
When a call arrives, the sip debug result is:
<— SIP read from UDP:192.168.106.149:21076 —>
INVITE sip:1001@192.168.25.197:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.25.197:8833;branch=z9hG4bK-7710-1-1
From: sipp-uac sip:sipp-uac@192.168.25.197:8833;tag=7710SIPpTag091
To: sipp-uas sip:1001@192.168.25.197:5060
Call-ID: 1-7710@192.168.25.197
CSeq: 1 INVITE
Contact: sip:sipp-uac@192.168.25.197:8833
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 297
v=0
o=user1 53655765 2353687637 IN IP4 192.168.25.197
s=-
c=IN IP4 192.168.25.197
t=0 0
m=audio 6001 RTP/AVP 0 3 4 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11,16
<— Transmitting (no NAT) to 192.168.106.149:8833 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.25.197:8833;branch=z9hG4bK-7710-1-1;received=192.168.106.149
From: sipp-uac sip:sipp-uac@192.168.25.197:8833;tag=7710SIPpTag091
To: sipp-uas sip:1001@192.168.25.197:5060
Call-ID: 1-7710@192.168.25.197
CSeq: 1 INVITE
Server: Asterisk PBX 13.7.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:1001@192.168.25.197:5060
Content-Length: 0
As you may notice, Asterisk responds to the address from which the request came.
Looking at what RFC 3261 says, you are actually asking Asterisk to violate a mandatory requirement of the protocol!
When the server transport receives a request over any transport, it
MUST examine the value of the “sent-by” parameter in the top Via
header field value. If the host portion of the “sent-by” parameter
contains a domain name, or if it contains an IP address that differs
from the packet source address, the server MUST add a “received”
parameter to that Via header field value. This parameter MUST
contain the source address from which the packet was received. This
is to assist the server transport layer in sending the response,
since it must be sent to the source IP address from which the request
came.
…
Otherwise (for unreliable unicast transports), if the top Via
has a “received” parameter, the response MUST be sent to the
address in the “received” parameter, using the port indicated
in the “sent-by” value, or using port 5060 if none is specified
explicitly. If this fails, for example, elicits an ICMP “port
unreachable” response, the procedures of Section 5 of [4]
SHOULD be used to determine where to send the response.
The only way of overriding this is with maddr, but Asterisk support of maddr is weak.
Thank you for maddr tip, it works like a charm 
Sorry to resuscitate such an old post…But i’m quite interested to know how to implementate maddr.
For a test with a cluster which gave me troubles.
Anyone could explain better?