10 Aug
2006
10 Aug
'06
12:09 p.m.
Thanks for the response, will try it and see what happens. :-)
While waiting for help, i tried a new config, without fix_nat_contact.
It works (Audio & signalling) for outgoing calls.(private -> public)
Contact header has a private IP but SDP information is correct due to RTPProxy.
At incoming calls the force_rtp_proxy command didn't change anything, meaning that SDP
Information is not correct -> no audio, only signalling.
I tried to start rtpproxy without options and in bridged mode. Also in bridged mode i
tried both possibilities -l private/public & -l public/private, but it didn't
influence the outcome.
Perhaps someone could help me out on this. :-)
Here are the changes to my config.
route[1]
{
if(dst_ip == 10.x.x.x)
{
force_rtp_proxy("","193.x.x.x");
};
if (dst_ip == 193.x.x.x)
{
force_rtp_proxy("","10.x.x.x");
};
t_on_reply("1");
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if (status =~ "(183)|2[0-9][0-9]") {
if(dst_ip == 10.x.x.x)
{
force_rtp_proxy("e");
log(2,"RTP_PROXY: Reply-Route1 dst 10.x.x.x\n");
};
if (dst_ip == 193.x.x.x)
{
force_rtp_proxy("i");
log(2,"RTP_PROXY: Reply-Route1 dst 193.x.x.x\n");
};
};
}
fix_nated_contact() is meant for changing the IP address of the Contact
header when SER has a public address and the UA has a
private (i.e.
behind NAT). This means that it will rewrite Contact to contain the
source ip address:port found in the UDP/TCP header.
This is probably correct, because I assume the UA cannot be reached
from the outside anyway. If you record-route, subsequent requests
should go through your ser.
If you have problems with responses not being returned, have a look at
Via headers as they control how answers to i.e an INVITE are routed
back to the UA. You may want to have a look at the rr module double
record route parameter to make sure that SER creates one record-route
for the internal and one for the external interface.
g-)
Sebastian Gabris wrote:
After reading a bit more mails, I came to two possible problems:
1. fix_nated_contact() needs a registrar to work properly
I dont use a registrar, since i register at the VoIP - Provider.
or
2. fix_nated_contact() is not ment to be used on this scenario
Any ideas on this?
Sebastian
Hi everybody,
need some help on nattraversal.
i use a multihomed SER, one private IP & one public IP.
MyUA(privateIP) <-> (privateIP)SER(publicIP) <-> UA-(VoIP - Provider,
pubicIP)
If i try to make a call from private net to public net, SER doesnt change the contact
address. He changes the sdp - connection field but he, puts in the wrong IP - address.
Instead o writing down his public IP, SER writes his private IP.
Then SER forwards the call on his public interface to the provider, which will get wrong
Contact & SDP information.
After reviewing my logs i saw that SER does the nat_uac_test, but the fix_nat_contact
& fix_sdp dont work dont do what they should do :)
Here are the important bits of my config:
fork=yes
log_stderror=no mhomed=1
listen=10.x.x.x
listen=193.x.x.x
loadmodule "/usr/lib/ser/modules/nathelper.so"
modparam("usrloc", "db_mode", 0)
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 30) # Ping interval 30 s
modparam("nathelper", "ping_nated_only", 1) # Ping only clients
behind NAT
if (nat_uac_test("3")) {
if (method == "REGISTER" || ! search("^Record-Route:")) {
log(2,"LOG: Someone trying to register from private IP, rewriting\n");
fix_nated_contact(); # Rewrite contact with source IP of signalling
if (method == "INVITE") {
fix_nated_sdp("1"); # Add direction=active to SDP
};
force_rport(); # Add rport parameter to topmost Via
setflag(6); # Mark as NATed
};
};
... and so on.
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071