14 Dec
2009
14 Dec
'09
5:24 p.m.
Hi All,
I am trying to setup kamailio 1.5.3-notls for use with rtpproxy 1.2.1. I
have a partially working setup, however, when I have a softphone
configured behind nat it appears that rtpproxy is using the internal ip
(prior to nat) to setup the sdp ports.
I have rtpproxy configured in bridge mode as follows:
rtpproxy -f -F -l public_ip/internal_ip -s udp:*:11211
I have kamailio's nathelper module setup as follows:
modparam("nathelper", "rtpproxy_sock",
"udp:internal_ip:11211")
I then use a softphone (x-lite) behind a nat firewall (ip =
192.168.11.2) to establish a call, and the log of rtpproxy is as follows:
INFO:handle_command: new session
ZmRkNjRlNjM0NzExZjQ5MWUxYjllOTFhZWFmZGZkMjY., tag 8330585e;1 requested,
type strong
INFO:handle_command: new session on a port 52572 created, tag 8330585e;1
INFO:handle_command: pre-filling caller's address with 192.168.11.2:35498
INFO:handle_command: lookup on ports 52572/40380, session timer restarted
INFO:handle_command: pre-filling callee's address with internal_ip:11250
INFO:handle_delete: forcefully deleting session 1 on ports 52572/40380
INFO:remove_session: RTP stats: 906 in from callee, 0 in from caller,
906 relayed, 0 dropped
INFO:remove_session: RTCP stats: 3 in from callee, 0 in from caller, 3
relayed, 0 dropped
INFO:remove_session: session on ports 52572/40380 is cleaned up
In the log above it looks like rtpproxy is using 192.168.11.2:35498 as
the remote ip/port combination to contact for the sdp session of the
x-lite softphone. I would have thought that it would use the IP address
that initial request was received from to establish this connection (via
the fix_nated_contact() function).
My route logic in kamailio is a slightly modified default configuration
that is installed with kamailio :
route{
.
.
.
# NAT detection
route(4);
.
.
.
route(1);
}
route[1]{
if (check_route_param("nat=yes")) {
setbflag(6);
}
# if (isflagset(5) || isbflagset(6)) {
route(5);
# }
/* example how to enable some additional event routes */
if (is_method("INVITE")) {
#t_on_branch("1");
t_on_reply("1");
t_on_failure("1");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[4]{
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(5);
}
return;
}
Would the "fix_nated_contact" function in the "nat detection" route
not
fix the contact before passing over the request to rtpproxy to establish
the sdp session?
route[5] {
if (is_method("BYE")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
# force_rtp_proxy();
if(src_ip==internal_ip_of_media_server)
force_rtp_proxy("ocfaei");
else
force_rtp_proxy("ocfaie");
}
if (!has_totag()) add_rr_param(";nat=yes");
return;
}
onreply_route[1] {
xdbg("incoming reply\n");
# if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])") {
if (status=~"(183)|(2[0-9][0-9])") {
# force_rtp_proxy();
if(src_ip == internal_ip_of_media_server)
force_rtp_proxy("ocfaei");
else
force_rtp_proxy("ocfaie");
}
if (isbflagset(6)) {
fix_nated_contact();
}
}
failure_route[1] {
if (is_method("INVITE")
&& (isbflagset(6) || isflagset(5))) {
unforce_rtp_proxy();
}
if (t_was_cancelled()) {
exit;
}
}
Any pointers would be greatly appreciated.
Thanks
Bruce
14 Dec
14 Dec
7:47 p.m.
Hi All,
Just an update to this, if I use a Cisco 7960 with nat traversal
enabled, the bridging works. It looks like rtpproxy fills the callers
address with the correct ip details of the UA. See the log below:
INFO:handle_command: new session
000f23e7-18db0016-7f899e0c-62e77522(a)188.141.20.76, tag
000f23e718db1a5a307d0789-26be63fe;1 requested, type strong
INFO:handle_command: new session on a port 63638 created, tag
000f23e718db1a5a307d0789-26be63fe;1
INFO:handle_command: pre-filling caller's address with 188.141.20.76:19340
INFO:handle_command: adding strong flag to existing session, new=1/0/0
INFO:handle_command: lookup on ports 63638/0, session timer restarted
INFO:handle_command: lookup on ports 63638/61436, session timer restarted
INFO:handle_command: pre-filling callee's address with 10.7.0.57:10602
INFO:handle_delete: forcefully deleting session 1 on ports 63638/61436
INFO:remove_session: RTP stats: 186 in from callee, 186 in from caller,
372 relayed, 0 dropped
INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
relayed, 0 dropped
INFO:remove_session: session on ports 63638/61436 is cleaned up
Where the following represents:
188.141.20.76 = IP of firewall/UA
10.7.0.57 = media server address.
The call completes successfully.
I can only assume that I am missing something with the nating when I use
the softphone and rtpproxy, as with the log below it shows the internal
IP address of the softphone as apposed to the external ip of my firewall.
Where does rtpproxy extract the source ip from when it is populating the
caller/calle addreses?, is it from the contact address?
Any suggestions would be appreciated.
Thanks
Bruce
Bruce McAlister wrote:
Hi All,
I am trying to setup kamailio 1.5.3-notls for use with rtpproxy 1.2.1. I
have a partially working setup, however, when I have a softphone
configured behind nat it appears that rtpproxy is using the internal ip
(prior to nat) to setup the sdp ports.
I have rtpproxy configured in bridge mode as follows:
rtpproxy -f -F -l public_ip/internal_ip -s udp:*:11211
I have kamailio's nathelper module setup as follows:
modparam("nathelper", "rtpproxy_sock",
"udp:internal_ip:11211")
I then use a softphone (x-lite) behind a nat firewall (ip =
192.168.11.2) to establish a call, and the log of rtpproxy is as follows:
INFO:handle_command: new session
ZmRkNjRlNjM0NzExZjQ5MWUxYjllOTFhZWFmZGZkMjY., tag 8330585e;1 requested,
type strong
INFO:handle_command: new session on a port 52572 created, tag 8330585e;1
INFO:handle_command: pre-filling caller's address with 192.168.11.2:35498
INFO:handle_command: lookup on ports 52572/40380, session timer restarted
INFO:handle_command: pre-filling callee's address with internal_ip:11250
INFO:handle_delete: forcefully deleting session 1 on ports 52572/40380
INFO:remove_session: RTP stats: 906 in from callee, 0 in from caller,
906 relayed, 0 dropped
INFO:remove_session: RTCP stats: 3 in from callee, 0 in from caller, 3
relayed, 0 dropped
INFO:remove_session: session on ports 52572/40380 is cleaned up
In the log above it looks like rtpproxy is using 192.168.11.2:35498 as
the remote ip/port combination to contact for the sdp session of the
x-lite softphone. I would have thought that it would use the IP address
that initial request was received from to establish this connection (via
the fix_nated_contact() function).
My route logic in kamailio is a slightly modified default configuration
that is installed with kamailio :
route{
.
.
.
# NAT detection
route(4);
.
.
.
route(1);
}
route[1]{
if (check_route_param("nat=yes")) {
setbflag(6);
}
# if (isflagset(5) || isbflagset(6)) {
route(5);
# }
/* example how to enable some additional event routes */
if (is_method("INVITE")) {
#t_on_branch("1");
t_on_reply("1");
t_on_failure("1");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[4]{
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(5);
}
return;
}
Would the "fix_nated_contact" function in the "nat detection" route
not
fix the contact before passing over the request to rtpproxy to establish
the sdp session?
route[5] {
if (is_method("BYE")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
# force_rtp_proxy();
if(src_ip==internal_ip_of_media_server)
force_rtp_proxy("ocfaei");
else
force_rtp_proxy("ocfaie");
}
if (!has_totag()) add_rr_param(";nat=yes");
return;
}
onreply_route[1] {
xdbg("incoming reply\n");
# if ((isflagset(5) || isbflagset(6)) &&
status=~"(183)|(2[0-9][0-9])") {
if (status=~"(183)|(2[0-9][0-9])") {
# force_rtp_proxy();
if(src_ip == internal_ip_of_media_server)
force_rtp_proxy("ocfaei");
else
force_rtp_proxy("ocfaie");
}
if (isbflagset(6)) {
fix_nated_contact();
}
}
failure_route[1] {
if (is_method("INVITE")
&& (isbflagset(6) || isflagset(5))) {
unforce_rtp_proxy();
}
if (t_was_cancelled()) {
exit;
}
}
Any pointers would be greatly appreciated.
Thanks
Bruce
_______________________________________________
sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:29 p.m.
Hello,
On 12/14/09 1:24 PM, Bruce McAlister wrote:
Hi All,
I am trying to setup kamailio 1.5.3-notls for use with rtpproxy 1.2.1. I
have a partially working setup, however, when I have a softphone
configured behind nat it appears that rtpproxy is using the internal ip
(prior to nat) to setup the sdp ports.
I have rtpproxy configured in bridge mode as follows:
rtpproxy -f -F -l public_ip/internal_ip -s udp:*:11211
depending on flags, the public or internal IP is used to update the sdp.
If you get it in the wrong order, then change the flags e and i in
force_rtp_proxy() call.
It is ok to have the internal ip in the sdp going to the phone in
internal network.
Cheers,
Daniel
I have kamailio's nathelper module setup as
follows:
modparam("nathelper", "rtpproxy_sock",
"udp:internal_ip:11211")
I then use a softphone (x-lite) behind a nat firewall (ip =
192.168.11.2) to establish a call, and the log of rtpproxy is as follows:
INFO:handle_command: new session
ZmRkNjRlNjM0NzExZjQ5MWUxYjllOTFhZWFmZGZkMjY., tag 8330585e;1 requested,
type strong
INFO:handle_command: new session on a port 52572 created, tag 8330585e;1
INFO:handle_command: pre-filling caller's address with 192.168.11.2:35498
INFO:handle_command: lookup on ports 52572/40380, session timer restarted
INFO:handle_command: pre-filling callee's address with internal_ip:11250
INFO:handle_delete: forcefully deleting session 1 on ports 52572/40380
INFO:remove_session: RTP stats: 906 in from callee, 0 in from caller,
906 relayed, 0 dropped
INFO:remove_session: RTCP stats: 3 in from callee, 0 in from caller, 3
relayed, 0 dropped
INFO:remove_session: session on ports 52572/40380 is cleaned up
In the log above it looks like rtpproxy is using 192.168.11.2:35498 as
the remote ip/port combination to contact for the sdp session of the
x-lite softphone. I would have thought that it would use the IP address
that initial request was received from to establish this connection (via
the fix_nated_contact() function).
My route logic in kamailio is a slightly modified default configuration
that is installed with kamailio :
route{
.
.
.
# NAT detection
route(4);
.
.
.
route(1);
}
route[1]{
if (check_route_param("nat=yes")) {
setbflag(6);
}
# if (isflagset(5) || isbflagset(6)) {
route(5);
# }
/* example how to enable some additional event routes */
if (is_method("INVITE")) {
#t_on_branch("1");
t_on_reply("1");
t_on_failure("1");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[4]{
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(5);
}
return;
}
Would the "fix_nated_contact" function in the "nat detection" route
not
fix the contact before passing over the request to rtpproxy to establish
the sdp session?
route[5] {
if (is_method("BYE")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
# force_rtp_proxy();
if(src_ip==internal_ip_of_media_server)
force_rtp_proxy("ocfaei");
else
force_rtp_proxy("ocfaie");
}
if (!has_totag()) add_rr_param(";nat=yes");
return;
}
onreply_route[1] {
xdbg("incoming reply\n");
# if ((isflagset(5) || isbflagset(6))&&
status=~"(183)|(2[0-9][0-9])") {
if (status=~"(183)|(2[0-9][0-9])") {
# force_rtp_proxy();
if(src_ip == internal_ip_of_media_server)
force_rtp_proxy("ocfaei");
else
force_rtp_proxy("ocfaie");
}
if (isbflagset(6)) {
fix_nated_contact();
}
}
failure_route[1] {
if (is_method("INVITE")
&& (isbflagset(6) || isflagset(5))) {
unforce_rtp_proxy();
}
if (t_was_cancelled()) {
exit;
}
}
Any pointers would be greatly appreciated.
Thanks
Bruce
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
* http://www.asipto.com/
8:54 p.m.
Hi Daniel,
depending on flags, the public or internal IP is used to update the sdp.
If you get it in the wrong order, then change the flags e and i in
force_rtp_proxy() call.
I think I have the flags setup correctly because I am able to get calls
working if I setup a phone to send out its details as having my firewall
ip address. If I change the ei/ie parameters in force_rtpproxy then the
calls dont work at all.
I will try to explain my scenario below.
I have a soft phone (x-lite) on my pc who's internal IP address is
192.168.11.2. When I initiate a call from my softphone the contact
address is setup as 192.168.11.2, kamailio then adds the rport and
received parameters as my external firewall ip and port.
When I force the rtpproxy setup, it looks like rtpproxy is setting up
the correct ports on our publice ip, but it looks like rtpproxy wants to
talk to my softphone using ip address 192.168.11.2 instead of the ip
address that is in the recevied parameter.
INFO:handle_command: pre-filling caller's address with 192.168.11.2:14880
My external IP of my firewall is 188.141.20.76, I would have expected
the rtpproxy line to look like this:
INFO:handle_command: pre-filling caller's address with 188.141.20.76:14880
The media server on the other side of the rtpproxy bridge is able to
send traffic to rtpproxy, but it looks like rtpproxy is not able to
contact the softphone as it is a private address.
If I do the same test using a Cisco 7960 which has "nat-traversal"
enabled in its configuration then the call works, rtpproxy sets up the
correct ports on the internal nic for the media server to talk to and it
sets up a port pair on its external nic to talk to the cisco phone. This
works.
I suspect my problem lies with nat somewhere and telling rtpproxy to use
the "recieved" ip address of my firewall to talk to my x-lite.
I hope I am explaining my scenario better. Any comments suggestions
would be appreciated.
Thanks
Bruce
10:10 p.m.
Hello,
On 12/14/09 4:54 PM, Bruce McAlister wrote:
Hi Daniel,
in order to connect the rtp stream, rtpproxy needs to receive an audio
packet (rtp) from each side. rtpproxy main job is to give addresses and
ports to fill in SDP of INVITE and 200OK reply.
If you can get an ngrep trace with such call, I can give more hits about
whether is ok or not.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
depending on flags, the public or internal IP is
used to update the sdp.
If you get it in the wrong order, then change the flags e and i in
force_rtp_proxy() call.
I think I have the flags setup correctly because I am able to get calls
working if I setup a phone to send out its details as having my firewall
ip address. If I change the ei/ie parameters in force_rtpproxy then the
calls dont work at all.
I will try to explain my scenario below.
I have a soft phone (x-lite) on my pc who's internal IP address is
192.168.11.2. When I initiate a call from my softphone the contact
address is setup as 192.168.11.2, kamailio then adds the rport and
received parameters as my external firewall ip and port.
When I force the rtpproxy setup, it looks like rtpproxy is setting up
the correct ports on our publice ip, but it looks like rtpproxy wants to
talk to my softphone using ip address 192.168.11.2 instead of the ip
address that is in the recevied parameter.
INFO:handle_command: pre-filling caller's address with 192.168.11.2:14880
My external IP of my firewall is 188.141.20.76, I would have expected
the rtpproxy line to look like this:
INFO:handle_command: pre-filling caller's address with 188.141.20.76:14880
The media server on the other side of the rtpproxy bridge is able to
send traffic to rtpproxy, but it looks like rtpproxy is not able to
contact the softphone as it is a private address.
If I do the same test using a Cisco 7960 which has "nat-traversal"
enabled in its configuration then the call works, rtpproxy sets up the
correct ports on the internal nic for the media server to talk to and it
sets up a port pair on its external nic to talk to the cisco phone. This
works.
I suspect my problem lies with nat somewhere and telling rtpproxy to use
the "recieved" ip address of my firewall to talk to my x-lite.
I hope I am explaining my scenario better. Any comments suggestions
would be appreciated.
16 Dec
16 Dec
11:02 p.m.
Hi All,
With the guidance of Daniel, I managed to fix this issue, it had to do
with symmetric vs asymmetric nat.
I had to change the "ofcaie" parameters in the call to force_rtp_proxy
to remove the "a" and replace it with a "w".
See nathelper module for more info on the flags :)
Thanks
Bruce
5247
days inactive
5249
days old
5 comments
2 participants
participants (2)
-
Bruce McAlister -
Daniel-Constantin Mierla