3 May
2006
3 May
'06
2:31 p.m.
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
4 May
4 May
7:56 a.m.
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(a)otenet.gr>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).
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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:52 a.m.
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(a)otenet.gr>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).
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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6 May
6 May
9:13 p.m.
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(a)otenet.gr>gr>:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:57 p.m.
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.
8 May
8 May
2:22 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:31 a.m.
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(a)gmail.com>om>:
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:
_______________________________________________
Serusers mailing list
serusers(a)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.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:45 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9 May
9 May
2:57 a.m.
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:
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:
_______________________________________________
Serusers mailing list
serusers(a)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.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:34 a.m.
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:
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:
_______________________________________________
Serusers mailing list
serusers(a)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.
>
>
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6643
days inactive
6649
days old
9 comments
4 participants
participants (4)
-
Kostas Marneris -
Ladislav Andel -
O. -
samuel