[Serusers] How to Minimize rtp proxy usage for all cases including when behind the same NAT
6 Dec
2005
6 Dec
'05
2:45 a.m.
Hello,
I have SER setup to only use the rtpproxy if the client is behind a
symmetric NAT. This is accomplished by using STUN since STUN will not modify
the contact headers if it detects a symmetric NAT. So SER see's the local
address in the contact header and only forces rtpproxy for those types of
call. When users are behind the same NAT then ser detects this using AVP's
and force_rtpproxy is not used for the call. This only works when STUN is
not enabled. Since when STUN succeeds the orignal local address of the phone
is changed to the public address in the sip message. So when two STUN
enabled clients try to call each other from behind the same nat the call
fails. The call fails because the NAT does not support harpin of media as
most don't. The only way this call would work is if the contacts could be
changed back to use their local addresses pre-STUN. How can SER be
instructed to use the local address for calls behind the same NAT when STUN
is enabled? One way I can think of doing this is to change nathelper to
extract the original IP from the VIA header and rewrite the SDP. In the SIP
trace i see only IP's in contact headers and SDP are changed when STUN
succeeds. Is there a simpler way to accomplish this?
Thanks,
Sumeet
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
6 Dec
6 Dec
3:33 a.m.
New subject: [Serusers] How to Minimize rtp proxy usage for all cases including when behind the same NAT
Hi,
Sorry that I cannot answer your question, but this particular issue has
been bothering me the past few days, so I would also like to know wether
this can be accomplished. A solution will cure a lot of ills! :-)
Especially in places where bandwidth comes at huge premiums for hosted
solutions (yes, alas these places still exists). The use of rtpproxy or
similar will then unfortunately mean that bandwidth usage will more than
double (SIP and media stream x2) for each call, which will ensure
massive bandwidth bills (not something you want for a service that is
supposed free for it's users). Does somebody have a possible solution,
please?
On Mon, 2005-12-05 at 16:45 -0800, S G wrote:
Hello,
I have SER setup to only use the rtpproxy if the client is behind a
symmetric NAT. This is accomplished by using STUN since STUN will not modify
the contact headers if it detects a symmetric NAT. So SER see's the local
address in the contact header and only forces rtpproxy for those types of
call. When users are behind the same NAT then ser detects this using AVP's
and force_rtpproxy is not used for the call. This only works when STUN is
not enabled. Since when STUN succeeds the orignal local address of the phone
is changed to the public address in the sip message. So when two STUN
enabled clients try to call each other from behind the same nat the call
fails. The call fails because the NAT does not support harpin of media as
most don't. The only way this call would work is if the contacts could be
changed back to use their local addresses pre-STUN. How can SER be
instructed to use the local address for calls behind the same NAT when STUN
is enabled? One way I can think of doing this is to change nathelper to
extract the original IP from the VIA header and rewrite the SDP. In the SIP
trace i see only IP's in contact headers and SDP are changed when STUN
succeeds. Is there a simpler way to accomplish this?
Thanks,
Sumeet
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Regards,
Jan Henkins
Cell: +27-84-951-4334
5:16 a.m.
New subject: [Serusers] How to Minimize rtp proxy usage for all cases including when behind the same NAT
The tricky part of such a modification to store pre-STUN addresses lies in
determining what's local.
For instance.... if I'm on a 192.168.1.X subnet behind a NAT at my home, and
my friend is on a 192.168.1.X subnet behind a NAT at HIS home, it becomes very
tricky to determine if we're both local to each other or not. Now, you could
do some fancy tricks where you check the NAT AND the rewritten IPs and try and
match... but then, when you toss in multiple NATs, it gets impossible to even
do that.
Imagine I'm behind a NAT at my home on a 192.168.1.X network, and my friend is
behind a NAT at his home on a 192.168.1.X network. Together, we both use the
same internet service provider who has us BOTH given 'external' IPs which are
really 10.1.1.X numbers behind a large NAT in their subnet.
Now, SER, off on some other network, sees the external IP from the ISP's NAT,
and maps it back to our 10.1.1.X numbers. But if it stores our original IPs,
it will still have 192.168.1.X numbers that APPEAR to be on the same subnet
but which in fact are not.
The problem is that SIP is inherently NAT unfriendly, and there are hacks and
kludges to get around these inherent inabilities, but they remain just that --
hacks and kludges.
Strangely, I noticed this evening that, using WinSTUN, my Linksys gateway is
reported as not supporting Hairpinning... and yet it clearly does. What are
the sort of tests done to check that in a test program like WinSTUN?
N.
On Mon, 05 Dec 2005 16:45:06 -0800, S G wrote
Hello,
I have SER setup to only use the rtpproxy if the client is behind a
symmetric NAT. This is accomplished by using STUN since STUN will
not modify the contact headers if it detects a symmetric NAT. So SER
see's the local address in the contact header and only forces
rtpproxy for those types of call. When users are behind the same NAT
then ser detects this using AVP's and force_rtpproxy is not used for
the call. This only works when STUN is not enabled. Since when STUN
succeeds the orignal local address of the phone is changed to the
public address in the sip message. So when two STUN enabled clients
try to call each other from behind the same nat the call fails. The
call fails because the NAT does not support harpin of media as most
don't. The only way this call would work is if the contacts could be
changed back to use their local addresses pre-STUN. How can SER be
instructed to use the local address for calls behind the same NAT
when STUN is enabled? One way I can think of doing this is to change
nathelper to extract the original IP from the VIA header and rewrite
the SDP. In the SIP trace i see only IP's in contact headers and SDP
are changed when STUN succeeds. Is there a simpler way to accomplish
this?
Thanks,
Sumeet
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's
FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7 Dec
7 Dec
8:23 p.m.
New subject: [Serusers] How to Minimize rtp proxy usage for all cases including when behind the same NAT
It's pretty simple actually, to determine if your behind the same NAT. You
just check if the request for both parties are coming from the same external
public IP. Sure, this might not account for every case, multiple subnets,
multiple NAT setups, but it takes care of a great deal of them. I would say
most home users and offices have a simple single NAT setup. The problem is
when using STUN how to set the SDP's to use the pre-STUN local ip's. Without
STUN it works just fine, but you of course end up rtpproxying ever call.
-Sumeet
From: "sip" <sip(a)arcdiv.com>
To: "S G" <skg1010(a)hotmail.com>om>, serusers(a)lists.iptel.org
Subject: Re: [Serusers] How to Minimize rtp proxy usage for all cases
including when behind the same NAT
Date: Mon, 5 Dec 2005 22:16:02 -0500
The tricky part of such a modification to store pre-STUN addresses lies in
determining what's local.
For instance.... if I'm on a 192.168.1.X subnet behind a NAT at my home,
and
my friend is on a 192.168.1.X subnet behind a NAT at HIS home, it becomes
very
tricky to determine if we're both local to each other or not. Now, you
could
do some fancy tricks where you check the NAT AND the rewritten IPs and try
and
match... but then, when you toss in multiple NATs, it gets impossible to
even
do that.
Imagine I'm behind a NAT at my home on a 192.168.1.X network, and my friend
is
behind a NAT at his home on a 192.168.1.X network. Together, we both use
the
same internet service provider who has us BOTH given 'external' IPs which
are
really 10.1.1.X numbers behind a large NAT in their subnet.
Now, SER, off on some other network, sees the external IP from the ISP's
NAT,
and maps it back to our 10.1.1.X numbers. But if it stores our original
IPs,
it will still have 192.168.1.X numbers that APPEAR to be on the same subnet
but which in fact are not.
The problem is that SIP is inherently NAT unfriendly, and there are hacks
and
kludges to get around these inherent inabilities, but they remain just that
--
hacks and kludges.
Strangely, I noticed this evening that, using WinSTUN, my Linksys gateway
is
reported as not supporting Hairpinning... and yet it clearly does. What are
the sort of tests done to check that in a test program like WinSTUN?
N.
On Mon, 05 Dec 2005 16:45:06 -0800, S G wrote
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Hello,
I have SER setup to only use the rtpproxy if the client is behind a
symmetric NAT. This is accomplished by using STUN since STUN will
not modify the contact headers if it detects a symmetric NAT. So SER
see's the local address in the contact header and only forces
rtpproxy for those types of call. When users are behind the same NAT
then ser detects this using AVP's and force_rtpproxy is not used for
the call. This only works when STUN is not enabled. Since when STUN
succeeds the orignal local address of the phone is changed to the
public address in the sip message. So when two STUN enabled clients
try to call each other from behind the same nat the call fails. The
call fails because the NAT does not support harpin of media as most
don't. The only way this call would work is if the contacts could be
changed back to use their local addresses pre-STUN. How can SER be
instructed to use the local address for calls behind the same NAT
when STUN is enabled? One way I can think of doing this is to change
nathelper to extract the original IP from the VIA header and rewrite
the SDP. In the SIP trace i see only IP's in contact headers and SDP
are changed when STUN succeeds. Is there a simpler way to accomplish
this?
Thanks,
Sumeet
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's
FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:36 p.m.
New subject: [Serusers] How to Minimize rtp proxy usage for all cases including when behind the same NAT
On Wed, 07 Dec 2005 10:23:38 -0800, S G wrote
It's pretty simple actually, to determine if your
behind the same
NAT. You just check if the request for both parties are coming from
the same external public IP. Sure, this might not account for every
case, multiple subnets, multiple NAT setups, but it takes care of a
great deal of them. I would say most home users and offices have a
simple single NAT setup. The problem is when using STUN how to set
the SDP's to use the pre-STUN local ip's. Without STUN it works just
fine, but you of course end up rtpproxying ever call.
Multiple NATs are pretty commonplace these days. To discount them as being
unimportant is really a bad idea. MOST big home network providers give NATted
addresses to their customers... many of whom NAT their own subnets.
N.
8:44 p.m.
New subject: [Serusers] How to Minimize rtp proxy usage for all cases including when behind the same NAT
So you're saying 2 users at 2 different physical locations with seperate ISP
accounts on the same "Big" internet provider will have the same external
public IP? I have never seen this. Can anyone verify this?
-Sumeet
From: "sip" <sip(a)arcdiv.com>
To: "S G" <skg1010(a)hotmail.com>om>, serusers(a)lists.iptel.org
Subject: Re: [Serusers] How to Minimize rtp proxy usage for all cases
including when behind the same NAT
Date: Wed, 7 Dec 2005 13:36:37 -0500
On Wed, 07 Dec 2005 10:23:38 -0800, S G wrote
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
It's pretty simple actually, to determine if
your behind the same
NAT. You just check if the request for both parties are coming from
the same external public IP. Sure, this might not account for every
case, multiple subnets, multiple NAT setups, but it takes care of a
great deal of them. I would say most home users and offices have a
simple single NAT setup. The problem is when using STUN how to set
the SDP's to use the pre-STUN local ip's. Without STUN it works just
fine, but you of course end up rtpproxying ever call.
Multiple NATs are pretty commonplace these days. To discount them as being
unimportant is really a bad idea. MOST big home network providers give
NATted
addresses to their customers... many of whom NAT their own subnets.
N.
6926
days inactive
6927
days old
5 comments
3 participants
participants (3)
-
Jan Henkins -
S G -
sip