4 May
2013
4 May
'13
4:37 p.m.
Hi,
I can configure kamailio + rtpproxy to enable calling between user behind the NAT. Thanks
for the example config, it is very easy to did it.
Do we need rtprpoxy for all kind of NAT?
From what i have read, only symmetric NAT that hard to be traversal-ed. While other type
of NAT can be traversaled using STUN.
But my device that behind openwrt router can't work without rtpproxy. Is it expected
behaviour?
Or i'm doing something wrong in the config?
Thanks
6 May
6 May
9:49 a.m.
On 04.05.2013 16:37, John Chen wrote:
Hi,
I can configure kamailio + rtpproxy to enable calling between user
behind the NAT. Thanks for the example config, it is very easy to did it.
Do we need rtprpoxy for all kind of NAT?
From what i have read, only symmetric NAT that hard to be traversal-ed.
While other type of NAT can be traversaled using STUN.
But my device that behind openwrt router can't work without rtpproxy. Is
it expected behaviour?
Or i'm doing something wrong in the config?
Yes, there are cases where NATs can be traversed without a media relay.
But it turned out that NATs can not be separated into
symmetric/coned/... as there are many more different types, and some
NATs even change there NAT-behavior during operation (e.g. when port
overloading starts).
Therefore, if the setup is only for NAT devices you are operating und
you know that STUN works, then you can omit the rtpproxy. But if you
need to have NAT traversal working in ALL cases for ALL NATs, then the
pragmatic approach is to enable rtpproxy for all cases.
Further, STUN-based NAT traversal is more or less obsolete. The
successor of STUN is ICE (RFC 5245 and 5768). It is also client-based
but much more advanced (and complicated). And Kamailio supports adding
rtpproxy as additional ICE candidates to avoid usage of TURN relays.
But of course ICE can only be used if the user agent suports it.
regards
Klaus
9:53 a.m.
6 maj 2013 kl. 09:49 skrev Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
On 04.05.2013 16:37, John Chen wrote:
If you have a server on a public IP running behind Kamailio you might not need RTPproxy
relaying for calls to and from that server. Asterisk will handle NAT by itself and
doesn't need help if you turn on NAT support in Asterisk. In that case, RTPproxy just
adds delay to your calls.
/O
Hi,
I can configure kamailio + rtpproxy to enable calling between user
behind the NAT. Thanks for the example config, it is very easy to did it.
Do we need rtprpoxy for all kind of NAT?
From what i have read, only symmetric NAT that hard to be traversal-ed.
While other type of NAT can be traversaled using STUN.
But my device that behind openwrt router can't work without rtpproxy. Is
it expected behaviour?
Or i'm doing something wrong in the config?
Yes, there are cases where NATs can be traversed without a media relay. But it turned out
that NATs can not be separated into symmetric/coned/... as there are many more different
types, and some NATs even change there NAT-behavior during operation (e.g. when port
overloading starts).
Therefore, if the setup is only for NAT devices you are operating und you know that STUN
works, then you can omit the rtpproxy. But if you need to have NAT traversal working in
ALL cases for ALL NATs, then the pragmatic approach is to enable rtpproxy for all cases.
Further, STUN-based NAT traversal is more or less obsolete. The successor of STUN is ICE
(RFC 5245 and 5768). It is also client-based but much more advanced (and complicated). And
Kamailio supports adding rtpproxy as additional ICE candidates to avoid usage of TURN
relays.
But of course ICE can only be used if the user agent suports it.
7 May
7 May
9:26 a.m.
I don't have asterisk/freeswitch now. But i'm considering it now.
How is rtpproxy performance compared to asterisk/freeswitch for handling media relay.
I only need the media relay capability. Don't need conference, ivr, transcoding,
etc...
----- Pesan Asli -----
Dari: Olle E. Johansson <oej(a)edvina.net>
If you have a server on a public IP running behind Kamailio you might not need RTPproxy
relaying for calls to and from that server. Asterisk will handle NAT by itself and
doesn't need help if you turn on NAT support in Asterisk. In that case, RTPproxy just
adds delay to your calls.
/O
8 May
8 May
4:49 a.m.
@Olle
"If you have a server on a public IP running behind Kamailio you might not
need RTPproxy relaying for calls to and from that server. Asterisk will
handle NAT by itself and doesn't need help if you turn on NAT support in
Asterisk. In that case, RTPproxy just adds delay to your calls."
Can you explain it a little more? Please show us the guide to do that.
How can we not use rtpproxy in case of symmetric NAT ?
On Tue, May 7, 2013 at 2:26 PM, John Chen <johnchen56(a)yahoo.com> wrote:
I don't have asterisk/freeswitch now. But i'm
considering it now.
How is rtpproxy performance compared to asterisk/freeswitch for handling
media relay.
I only need the media relay capability. Don't need conference, ivr,
transcoding, etc...
----- Pesan Asli -----
Dari: Olle E. Johansson <oej(a)edvina.net>
If you have a server on a public IP running behind Kamailio you might not
need RTPproxy relaying for calls to and from that server. Asterisk will
handle NAT by itself and doesn't need help if you turn on NAT support in
Asterisk. In that case, RTPproxy just adds delay to your calls.
/O
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Khoa Pham
HCMC University of Science
Faculty of Information Technology
11:37 a.m.
On 08.05.2013 04:49, Khoa Pham wrote:
@Olle
"If you have a server on a public IP running behind Kamailio you might
not need RTPproxy relaying for calls to and from that server. Asterisk
will handle NAT by itself and doesn't need help if you turn on NAT
support in Asterisk. In that case, RTPproxy just adds delay to your calls."
Can you explain it a little more? Please show us the guide to do that.
How can we not use rtpproxy in case of symmetric NAT ?
The thing is: you do not need a media relay if one of the call
participants has a public IP address.
For example, if you have calls from SIP clients to the PSTN via a PSTN
gateway, the PSTN gateway usually has a public IP address and therefore
there is no need for a media relay. You only have to instruct the
gateway to send RTP not to the IP:port announced in the SDP, but send
RTP to the same IP:port from which the client's RTP stream is received.
If you use Asterisk as PSTN gateway, just set nat=yes in sip.conf.
regards
Klaus
7 May
7 May
9:23 a.m.
New subject: Bls: Do we need rtpproxy for all kind of NAT?
Hi Klaus,
Thanks for your detailed explanation. Really appreciate it.
----- Pesan Asli -----
Dari: Klaus Darilion <klaus.mailinglists(a)pernau.at>
Kepada: John Chen <johnchen56(a)yahoo.com>om>; Kamailio (SER) - Users Mailing List
<sr-users(a)lists.sip-router.org>
Cc:
Dikirim: Senin, 6 Mei 2013 14:49
Judul: Re: [SR-Users] Do we need rtpproxy for all kind of NAT?
On 04.05.2013 16:37, John Chen wrote:
Hi,
I can configure kamailio + rtpproxy to enable calling between user
behind the NAT. Thanks for the example config, it is very easy to did it.
Do we need rtprpoxy for all kind of NAT?
From what i have read, only symmetric NAT that hard to be traversal-ed.
While other type of NAT can be traversaled using STUN.
But my device that behind openwrt router can't work without rtpproxy. Is
it expected behaviour?
Or i'm doing something wrong in the config?
Yes, there are cases where NATs can be traversed without a media relay.
But it turned out that NATs can not be separated into
symmetric/coned/... as there are many more different types, and some
NATs even change there NAT-behavior during operation (e.g. when port
overloading starts).
Therefore, if the setup is only for NAT devices you are operating und
you know that STUN works, then you can omit the rtpproxy. But if you
need to have NAT traversal working in ALL cases for ALL NATs, then the
pragmatic approach is to enable rtpproxy for all cases.
Further, STUN-based NAT traversal is more or less obsolete. The
successor of STUN is ICE (RFC 5245 and 5768). It is also client-based
but much more advanced (and complicated). And Kamailio supports adding
rtpproxy as additional ICE candidates to avoid usage of TURN relays.
But of course ICE can only be used if the user agent suports it.
regards
Klaus
4028
days inactive
4032
days old
6 comments
4 participants
participants (4)
-
John Chen -
Khoa Pham -
Klaus Darilion -
Olle E. Johansson