Am 20.02.2014 22:20, schrieb Rusty Newton:
To force RFC3581 support for outbound REGISTER messages, you can set
"nat=force_rport" in the general section of your sip.conf. (This also
forces RFC3581 compliance for inbound messages, for any peers that
inherit this general option)
[...]
Thank you for the suggestion, I just tried that. Unfortunately it
doesn't help in my case. The problem remains that my hosting provider is
rewriting ports:
Packets on the hosted VM (1.1.1.1) where Asterisk "client" is running:
IP 1.1.1.1.5060 > 2.2.2.2.5060: UDP, length 428
IP 2.2.2.2.5060 > 1.1.1.1.16025: UDP, length 544
IP 1.1.1.1 > 2.2.2.2: ICMP 1.1.1.1 udp port 16025
unreachable, length 556
And on 2.2.2.2, the remote SIP server (another Asterisk box for testing):
IP 1.1.1.1.16025 > 2.2.2.2.5060: UDP, length 428
IP 2.2.2.2.5060 > 1.1.1.1.16025: UDP, length 544
IP 1.1.1.1 > 2.2.2.2: ICMP 1.1.1.1 udp port 16025
unreachable, length 556
The initial REGISTER received from 1.1.1.1 without force_rport:
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK1780c521
And with force_rport enabled:
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK279a0a9b;rport
But of course, Asterisk on 2.2.2.2 will reply on the port where the
request originated, in the above case, port 16025 which was rewritten
from 5060 to 16052 by the evil hosting provider. This is what the Via
header looks like when 2.2.2.2 answers to 1.1.1.1:
Via: SIP/2.0/UDP
1.1.1.1:5060;branch=z9hG4bK279a0a9b;received=1.1.1.1;rport=16025
So, if there would be some kind of implementation that said "Ignore the
actual port that the request originated from, instead force answer on a
port that is transmitted via some header setting", that would help me.
Some fantasy option in sip.conf:
nat_rport_forced=5060
Could generate a header in the initial REGISTER from 1.1.1.1 to 2.2.2.2
like this:
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK279a0a9b;rport_forced=5060
And now, even though 2.2.2.2 received the request originating from port
16025, it would honor the "rport_forced" setting and reply back on port
5060 instead of 16025.
Maybe such an option exists, I just haven't found it yet? :)
Thank you!
Markus
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
