Hello all,
I'm trying to find a solution to overcome the NAT issue using only the nathelper module. (I've already successfully worked with 'STUN' & 'MediaProxy' solutions but I'm trying also this).
1. OUTBOUND direction: --- INVITE handler --- ... # NAT Traversal mechanism for INVITEs if (nat_uac_test("19")) { setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; # ...
The solution above works fine for OUTBOUND calls, either on-net (a) or off-net (b). (For off-net calls I use a Cisco GW).
a/ SIP_UA_behind_NAT -------- SER ------- SIP_UA_on_public_IP b/ SIP_UA_behind_NAT -------- SER ------- Cisco_PSTN_GW ------- PSTN
2. INBOUND direction: route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { log(1, " - Cannot RELAY !!!"); sl_reply_error(); }; }
onreply_route[1] { if (nat_uac_test("19")) { log(1, " - Response behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); };
}
Although I have two-way audio between calling and called parties, I get the following logging mesgs :
May 3 17:22:26 server ./ser[13705]: ERROR: extract_body: message body has length zero May 3 17:22:26 server ./ser[13705]: ERROR: fix_nated_sdp: cannot extract body from msg! May 3 17:22:26 server ./ser[13705]: ERROR: on_reply processing failed
My question is : Is the above the correct way for NAT traversal of SIP Responses (200 OK) ? Do I have to add something else somewhere in ser.cfg ? Any idea on the log mesgs above ?
thanks in advance for any help, Kostas
I would add a condition like
if (!search("^Content-Length:[ ]*0")) { fix_mated_sdp() }
So replies without body (180,100,101,...) will not raise the ERROR you have in the logs.
It would be also nice to check wether the reply is not an error (>299) so you do not need to use NAT transversal for error replies. if (status=~"(180)|(183)|2[0-9][0-9]") {
} I recommend you to check www.onsip.org and the discussion about the on_reply route in the getting started and the config files.
Hope it helps,
Samuel.
2006/5/3, Kostas Marneris K.Marneris@otenet.gr:
Hello all,
I'm trying to find a solution to overcome the NAT issue using only the nathelper module. (I've already successfully worked with 'STUN' & 'MediaProxy' solutions but I'm trying also this).
- OUTBOUND direction:
--- INVITE handler --- ... # NAT Traversal mechanism for INVITEs if (nat_uac_test("19")) { setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; # ...
The solution above works fine for OUTBOUND calls, either on-net (a) or off-net (b). (For off-net calls I use a Cisco GW).
a/ SIP_UA_behind_NAT -------- SER ------- SIP_UA_on_public_IP b/ SIP_UA_behind_NAT -------- SER ------- Cisco_PSTN_GW ------- PSTN
- INBOUND direction:
route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { log(1, " - Cannot RELAY !!!"); sl_reply_error(); }; }
onreply_route[1] { if (nat_uac_test("19")) { log(1, " - Response behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); };
}
Although I have two-way audio between calling and called parties, I get the following logging mesgs :
May 3 17:22:26 server ./ser[13705]: ERROR: extract_body: message body has length zero May 3 17:22:26 server ./ser[13705]: ERROR: fix_nated_sdp: cannot extract body from msg! May 3 17:22:26 server ./ser[13705]: ERROR: on_reply processing failed
My question is : Is the above the correct way for NAT traversal of SIP Responses (200 OK) ? Do I have to add something else somewhere in ser.cfg ? Any idea on the log mesgs above ?
thanks in advance for any help, Kostas
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
thanks a lot.
I use the following and everything seems Ok ...
onreply_route[1] { if (status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { if (nat_uac_test("13")) { log(1, " - Reply behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; }; };
}
Kostas
samuel wrote:
I would add a condition like
if (!search("^Content-Length:[ ]*0")) { fix_mated_sdp() }
So replies without body (180,100,101,...) will not raise the ERROR you have in the logs.
It would be also nice to check wether the reply is not an error (>299) so you do not need to use NAT transversal for error replies. if (status=~"(180)|(183)|2[0-9][0-9]") {
} I recommend you to check www.onsip.org and the discussion about the on_reply route in the getting started and the config files.
Hope it helps,
Samuel.
2006/5/3, Kostas Marneris K.Marneris@otenet.gr:
Hello all,
I'm trying to find a solution to overcome the NAT issue using only the nathelper module. (I've already successfully worked with 'STUN' & 'MediaProxy' solutions but I'm trying also this).
- OUTBOUND direction:
--- INVITE handler --- ... # NAT Traversal mechanism for INVITEs if (nat_uac_test("19")) { setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; # ...
The solution above works fine for OUTBOUND calls, either on-net (a) or off-net (b). (For off-net calls I use a Cisco GW).
a/ SIP_UA_behind_NAT -------- SER ------- SIP_UA_on_public_IP b/ SIP_UA_behind_NAT -------- SER ------- Cisco_PSTN_GW ------- PSTN
- INBOUND direction:
route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { log(1, " - Cannot RELAY !!!"); sl_reply_error(); }; }
onreply_route[1] { if (nat_uac_test("19")) { log(1, " - Response behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); };
}
Although I have two-way audio between calling and called parties, I get the following logging mesgs :
May 3 17:22:26 server ./ser[13705]: ERROR: extract_body: message body has length zero May 3 17:22:26 server ./ser[13705]: ERROR: fix_nated_sdp: cannot extract body from msg! May 3 17:22:26 server ./ser[13705]: ERROR: on_reply processing failed
My question is : Is the above the correct way for NAT traversal of SIP Responses (200 OK) ? Do I have to add something else somewhere in ser.cfg ? Any idea on the log mesgs above ?
thanks in advance for any help, Kostas
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
On Thu, 2006-05-04 at 14:52 +0300, Kostas Marneris wrote:
thanks a lot.
I use the following and everything seems Ok ...
onreply_route[1] { if (status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { if (nat_uac_test("13")) { log(1, " - Reply behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; }; };
}
Kostas
samuel wrote:
I would add a condition like
if (!search("^Content-Length:[ ]*0")) { fix_mated_sdp() }
So replies without body (180,100,101,...) will not raise the ERROR you have in the logs.
It would be also nice to check wether the reply is not an error (>299) so you do not need to use NAT transversal for error replies. if (status=~"(180)|(183)|2[0-9][0-9]") {
} I recommend you to check www.onsip.org and the discussion about the on_reply route in the getting started and the config files.
Hope it helps,
Samuel.
2006/5/3, Kostas Marneris K.Marneris@otenet.gr:
Hello all,
I'm trying to find a solution to overcome the NAT issue using only the nathelper module. (I've already successfully worked with 'STUN' & 'MediaProxy' solutions but I'm trying also this).
- OUTBOUND direction:
--- INVITE handler --- ... # NAT Traversal mechanism for INVITEs if (nat_uac_test("19")) { setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); }; # ...
The solution above works fine for OUTBOUND calls, either on-net (a) or off-net (b). (For off-net calls I use a Cisco GW).
a/ SIP_UA_behind_NAT -------- SER ------- SIP_UA_on_public_IP b/ SIP_UA_behind_NAT -------- SER ------- Cisco_PSTN_GW ------- PSTN
- INBOUND direction:
route[1] { # Default Message Handler t_on_reply("1"); if (!t_relay()) { log(1, " - Cannot RELAY !!!"); sl_reply_error(); }; }
onreply_route[1] { if (nat_uac_test("19")) { log(1, " - Response behind NAT..."); setflag(7); force_rport(); fix_nated_contact(); fix_nated_sdp("3"); };
}
Although I have two-way audio between calling and called parties, I get the following logging mesgs :
May 3 17:22:26 server ./ser[13705]: ERROR: extract_body: message body has length zero May 3 17:22:26 server ./ser[13705]: ERROR: fix_nated_sdp: cannot extract body from msg! May 3 17:22:26 server ./ser[13705]: ERROR: on_reply processing failed
My question is : Is the above the correct way for NAT traversal of SIP Responses (200 OK) ? Do I have to add something else somewhere in ser.cfg ? Any idea on the log mesgs above ?
thanks in advance for any help, Kostas
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi O., This will work only with one NAT involved in SIP dialog. If you have both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also, your clients has to support active/passive direction attribute and be able to read source IP:port address from the first RTP packet received.
Regards, Ladislav
O. wrote:
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
thanks, so we have to keep the proxy. In this case when one of the client will be behind nat does the proxy will transfer the RTP? or still the the RTP will be route without proxy involved?
Thanks, O.
On Sat, 2006-05-06 at 23:57 +0200, Ladislav Andel wrote:
Hi O., This will work only with one NAT involved in SIP dialog. If you have both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also, your clients has to support active/passive direction attribute and be able to read source IP:port address from the first RTP packet received.
Regards, Ladislav
O. wrote:
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
This is just the on_reply part of the ser config file to handle replies behind NAT. Obviously you have to check in the route[x] wether the calling UA is behind NAT and apply the appropriate mediaproxy|rtpproxy.
Samuel
2006/5/8, O. ozaarur@gmail.com:
thanks, so we have to keep the proxy. In this case when one of the client will be behind nat does the proxy will transfer the RTP? or still the the RTP will be route without proxy involved?
Thanks, O.
On Sat, 2006-05-06 at 23:57 +0200, Ladislav Andel wrote:
Hi O., This will work only with one NAT involved in SIP dialog. If you have both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also, your clients has to support active/passive direction attribute and be able to read source IP:port address from the first RTP packet received.
Regards, Ladislav
O. wrote:
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Unfortunately, up to version 0.9.6 SER doesn't know if the public client supports symmetric RTP and active/passive direction attribute. So SER will make sure that both clients can hear each other (both way RTP stream between clients) and involves RTP proxy. On the other hand, clients behind NAT has to support symmetric RTP because they would not work behind NAT.
So you have two options: 1) Not use rtpproxy at all in your ser.cfg and then you have to now that your clients support symmetric RTP But if you have two clients behind then it would not work. 2) Use RTPproxy even if one client is behind NAT.. This will work with all scenarios.
Ladislav
O. wrote:
thanks, so we have to keep the proxy. In this case when one of the client will be behind nat does the proxy will transfer the RTP? or still the the RTP will be route without proxy involved?
Thanks, O.
On Sat, 2006-05-06 at 23:57 +0200, Ladislav Andel wrote:
Hi O., This will work only with one NAT involved in SIP dialog. If you have both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also, your clients has to support active/passive direction attribute and be able to read source IP:port address from the first RTP packet received.
Regards, Ladislav
O. wrote:
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
thanks for the clarification. it looks like SER0.9.6 is step ahead or we have to deal with the extra traffic.
thanks, O.
On Mon, 2006-05-08 at 10:45 +0200, Ladislav Andel wrote:
Unfortunately, up to version 0.9.6 SER doesn't know if the public client supports symmetric RTP and active/passive direction attribute. So SER will make sure that both clients can hear each other (both way RTP stream between clients) and involves RTP proxy. On the other hand, clients behind NAT has to support symmetric RTP because they would not work behind NAT.
So you have two options:
- Not use rtpproxy at all in your ser.cfg and then you have to now that
your clients support symmetric RTP But if you have two clients behind then it would not work. 2) Use RTPproxy even if one client is behind NAT.. This will work with all scenarios.
Ladislav
O. wrote:
thanks, so we have to keep the proxy. In this case when one of the client will be behind nat does the proxy will transfer the RTP? or still the the RTP will be route without proxy involved?
Thanks, O.
On Sat, 2006-05-06 at 23:57 +0200, Ladislav Andel wrote:
Hi O., This will work only with one NAT involved in SIP dialog. If you have both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also, your clients has to support active/passive direction attribute and be able to read source IP:port address from the first RTP packet received.
Regards, Ladislav
O. wrote:
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
The CVS version is step ahead.
O. wrote:
thanks for the clarification. it looks like SER0.9.6 is step ahead or we have to deal with the extra traffic.
thanks, O.
On Mon, 2006-05-08 at 10:45 +0200, Ladislav Andel wrote:
Unfortunately, up to version 0.9.6 SER doesn't know if the public client supports symmetric RTP and active/passive direction attribute. So SER will make sure that both clients can hear each other (both way RTP stream between clients) and involves RTP proxy. On the other hand, clients behind NAT has to support symmetric RTP because they would not work behind NAT.
So you have two options:
- Not use rtpproxy at all in your ser.cfg and then you have to now that
your clients support symmetric RTP But if you have two clients behind then it would not work. 2) Use RTPproxy even if one client is behind NAT.. This will work with all scenarios.
Ladislav
O. wrote:
thanks, so we have to keep the proxy. In this case when one of the client will be behind nat does the proxy will transfer the RTP? or still the the RTP will be route without proxy involved?
Thanks, O.
On Sat, 2006-05-06 at 23:57 +0200, Ladislav Andel wrote:
Hi O., This will work only with one NAT involved in SIP dialog. If you have both clients behind NAT then RTPproxy or Mediaproxy is necessary. Also, your clients has to support active/passive direction attribute and be able to read source IP:port address from the first RTP packet received.
Regards, Ladislav
O. wrote:
Hi Kostas and samuel,
In the case you are describing, using nathelper will replace the rtpproxy or medianproxy? It looks to me that in this case the rtp will be route in between the sip client, without any proxy. In the configuration you mentioned the ser is on public IP? if this is the case it looks much better the proxy from the load prospective.
thanks, O.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Kostas Marneris -
Ladislav Andel -
O. -
samuel