19 Sep
2006
19 Sep
'06
8:16 p.m.
I am trying to reach a suitable trade-off between minimising the amount of
proxied media and minimising one-way/no audio for all clients including
NATed ones.
When a UA that has been configured to use STUN sends a register message to
SER the behaviour differs depending on the device. Some, such as a Sipura
device, send the private address in the Via and the public address in the
Contact:
U 60.234.nnn.nnn:5060 -> 147.202.nnn.nnn:5060 REGISTER sip:domain.com
SIP/2.0..Via: SIP/2.0/UDP 192.168.0.14:5060;branch=z9hG4bK-64d76b15..From:
<sip:6435488773@domain.com >;tag=4cdc1208fa650916o0..To:
<sip:6435488773@domain.com>..Call-ID: 1143f50-45857c6e@192.168.0.14..CSeq: 1
REGISTER..Max-Forwards: 70..Contact:
<sip:6435488773@60.234.nnn.nnn:5060>;expires=60..User-Agent:
Sipura/SPA3000-2.0.13(GWg)..Content-Length: 0..Allow: ACK, BYE, CANCEL,
INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura....
Others, such as a Grandstream device, send the public address in both the
Via and Contact:
U 60.234.nnn.nnn:32483 -> 147.202.nnn.nnn:5060 REGISTER sip:domain.com
SIP/2.0..Via: SIP/2.0/UDP
60.234.nnn.nnn:32483;branch=z9hG4bK113cfc09c6acd189..From: "User" <sip:
5551234@domain.com>;tag=dede17c9405d4e0e..To:
<sip:5551234@domain.com>..Contact: <sip:5551234@60.234.nnn.nnn:32483>..
Call-ID: fc200867c9a03268@192.168.0.10..CSeq: 100 REGISTER..Expires:
60..User-Agent: Grandstream BT100 1.0.6.7..Max-Forwards: 70..Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length:
0....
I am using the opsip.org configuration file together with mediaproxy. In the
case of the Sipura, flag(6) is set in route[2] since client_nat_test("7")
evaluates to true and so any calls with this device will be proxied. From
ready various posts on the topic I understand this is a very safe
configuration since it will deal with virtually every scenario. However it
is also very expensive since it will proxy audio in situations where it is
not really required. For example a call between two Sipura devices will be
proxied when, due to STUN, it is unecessary in most cases. As I understand
it the cases when it would be necessary are:
- both UAs behind the same NAT with the SER proxy outside the NAT and router
doesn't support hairpinning
- devices behind symmetric NATs
On the other hand, flag(6) will not be set with the Grandstream and so audio
will not be proxied when this device calls another device that is either not
behind NAT or is another NATed Grandstream. This is great in most cases but
audio problems could arise in the cases described above.
What I am therefore thinking is that by default I will not proxy media for
devices where a public IP address has been determined. But I will create an
avp that specifies by user whether to enable the standard onsip.org config.
Also there could even be a dial prefix (e.g. *666) that turns proxying on.
route[2]
#Do this by default
if (!search("^Contact: [ ]*\*") && client_nat_test("1") {
etc
#Do this if avp set or prefix dialled
if (!search("^Contact: [ ]*\*") && client_nat_test("7") {
etc
I would appreciate any comments on the above. Have I understood the issues
correctly? Will this type of configuration work? What are the disadvantages?
Regards
Cameron
20 Sep
20 Sep
9:04 a.m.
New subject: [Serusers] NAT: minimise media proxying whilst maximising usability
Yes, you are most definitely on to something. NAT-handling is complex
and it takes some work to fine-tune it the way you want. I few comments:
- Look at nathelper's nat_uac_test. It has more options and better
control, look at option 16, which is very good for detecting symmetric
NATs where STUN or an ALG has tried to fix the message
- If you are doing pstn, your gw supporting active media will reduce
your proxied calls to none
- sipura has many nat-handling options and takes some tweaking to get
them right for your config
- The behavior of the UAs will differ depending on the type of NAT they
are behind. When behind a symmetric NAT, they should not try to fix the
ip:port, but some do. nat_uac_test("16") will in most cases reveal this
Good luck! (and I'm sure others would appreciate a how-to on optimizing
NAT at iptel.org
http://www.iptel.org/node/add/flexinode-4
If you create one, I'll help out in making it accurate)
Also, make sure you have a look at the new NAT-handling document:
http://www.iptel.org/ser/howtos/optimizing_the_use_of_rtp_proxy
g-)
kjcsb wrote:
I am trying to reach a suitable trade-off between
minimising the
amount of proxied media and minimising one-way/no audio for all
clients including NATed ones.
When a UA that has been configured to use STUN sends a register
message to SER the behaviour differs depending on the device. Some,
such as a Sipura device, send the private address in the Via and the
public address in the Contact:
U 60.234.nnn.nnn:5060 -> 147.202.nnn.nnn:5060 REGISTER sip:domain.com
SIP/2.0..Via: SIP/2.0/UDP
192.168.0.14:5060;branch=z9hG4bK-64d76b15..From:
<sip:6435488773@domain.com >;tag=4cdc1208fa650916o0..To:
<sip:6435488773@domain.com>..Call-ID:
1143f50-45857c6e@192.168.0.14..CSeq: 1 REGISTER..Max-Forwards:
70..Contact:
<sip:6435488773@60.234.nnn.nnn:5060>;expires=60..User-Agent:
Sipura/SPA3000-2.0.13(GWg)..Content-Length: 0..Allow: ACK, BYE,
CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura....
Others, such as a Grandstream device, send the public address in both
the Via and Contact:
U 60.234.nnn.nnn:32483 -> 147.202.nnn.nnn:5060 REGISTER sip:domain.com
SIP/2.0..Via: SIP/2.0/UDP
60.234.nnn.nnn:32483;branch=z9hG4bK113cfc09c6acd189..From: "User"
<sip: 5551234@domain.com>;tag=dede17c9405d4e0e..To:
<sip:5551234@domain.com>..Contact:
<sip:5551234@60.234.nnn.nnn:32483>.. Call-ID:
fc200867c9a03268@192.168.0.10..CSeq: 100 REGISTER..Expires:
60..User-Agent: Grandstream BT100 1.0.6.7..Max-Forwards: 70..Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length:
0....
I am using the opsip.org configuration file together with mediaproxy.
In the case of the Sipura, flag(6) is set in route[2] since
client_nat_test("7") evaluates to true and so any calls with this
device will be proxied. From ready various posts on the topic I
understand this is a very safe configuration since it will deal with
virtually every scenario. However it is also very expensive since it
will proxy audio in situations where it is not really required. For
example a call between two Sipura devices will be proxied when, due to
STUN, it is unecessary in most cases. As I understand it the cases
when it would be necessary are:
- both UAs behind the same NAT with the SER proxy outside the NAT and
router doesn't support hairpinning
- devices behind symmetric NATs
On the other hand, flag(6) will not be set with the Grandstream and so
audio will not be proxied when this device calls another device that
is either not behind NAT or is another NATed Grandstream. This is
great in most cases but audio problems could arise in the cases
described above.
What I am therefore thinking is that by default I will not proxy media
for devices where a public IP address has been determined. But I will
create an avp that specifies by user whether to enable the standard
onsip.org config. Also there could even be a dial prefix (e.g. *666)
that turns proxying on.
route[2]
#Do this by default
if (!search("^Contact: [ ]*\*") && client_nat_test("1") {
etc
#Do this if avp set or prefix dialled
if (!search("^Contact: [ ]*\*") && client_nat_test("7") {
etc
I would appreciate any comments on the above. Have I understood the
issues correctly? Will this type of configuration work? What are the
disadvantages?
Regards
Cameron
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
25 Sep
25 Sep
8:29 a.m.
New subject: [Serusers] NAT: minimise media proxying whilst maximising usability
Yes, you are most definitely on to something.
NAT-handling is complex and
it takes some work to fine-tune it the way you want. I few comments:
- Look at nathelper's nat_uac_test. It has more options and better
control, look at option 16, which is very good for detecting symmetric
NATs where STUN or an ALG has tried to fix the message
- If you are doing pstn, your gw supporting active media will reduce your
proxied calls to none
- sipura has many nat-handling options and takes some tweaking to get them
right for your config
- The behavior of the UAs will differ depending on the type of NAT they
are behind. When behind a symmetric NAT, they should not try to fix the
ip:port, but some do. nat_uac_test("16") will in most cases reveal this
Good luck! (and I'm sure others would appreciate a how-to on optimizing
NAT at iptel.org
http://www.iptel.org/node/add/flexinode-4
If you create one, I'll help out in making it accurate)
Also, make sure you have a look at the new NAT-handling document:
http://www.iptel.org/ser/howtos/optimizing_the_use_of_rtp_proxy
g-)
Many thanks. I've read and reread "Optimizing the use of rtp proxy".
I've
also done a lot more reading on SDP & RTP which is most relevant to the
audio issue. Signalling is not the problem i.e. the messages are passed back
and forward through the proxy and I'm happy with that. It's the audio I want
to offload.
I think the key unanswered question I have is this: in the (seemingly) most
common scenario of two symmetric (signalling and RTP) UAs behind two
different (port) restricted cone NATs, can two-way audio be established
without the use of a media proxy? I had previously thought that was possible
but the latest reading I have done indicates not. Why? Because one side must
initiate the audio part of the call and the other side's NAT device will not
know where to send that audio on the LAN side of the network. Could someone
put me out of my misery and confirm one way or the other?
I had thought another alternative was to map the RTP ports on the NAT
device. This would mean forwarding ranges of ports to specific IP addresses
(each different port range relating to a specific UA) on the NAT device.
Each UA would then be configured to send RTP traffic on the port range
relating to its IP address. But if both sides are behind NAT then am I right
in thinking that this won't work either because the callees NAT device still
doesn't know where to send it?
Regarding me documenting my solution it looks to me like it's already been
done in "Optimizing the use of rtp proxy"! I'm currently using media proxy
so the main difference would be that the media proxy selection would be
based on the domain rather than an avp.e.g. west.domain.com goes to one
proxy and east.domain.com goes to another.
Cameron
10:20 a.m.
New subject: [Serusers] NAT: minimise media proxying whilst maximising usability
AFAIK, two UAs (symm) behind two different port restricted cone NATs
can talk to each
other without the mediaproxy, try to fix the SDP using fix_nated_sdp("2").
If the NAT is hairpin enabled then UAs behind the same port restricted NAT
can talk to each other.
~Vamsi
On 9/25/06, kjcsb <kjcsb(a)orcon.net.nz> wrote:
Yes, you are most definitely on to something.
NAT-handling is complex
and
it takes some work to fine-tune it the way you
want. I few comments:
- Look at nathelper's nat_uac_test. It has more options and better
control, look at option 16, which is very good for detecting symmetric
NATs where STUN or an ALG has tried to fix the message
- If you are doing pstn, your gw supporting active media will reduce
your
proxied calls to none
- sipura has many nat-handling options and takes some tweaking to get
them
right for your config
- The behavior of the UAs will differ depending on the type of NAT they
are behind. When behind a symmetric NAT, they should not try to fix the
ip:port, but some do. nat_uac_test("16") will in most cases reveal this
Good luck! (and I'm sure others would appreciate a how-to on optimizing
NAT at iptel.org
http://www.iptel.org/node/add/flexinode-4
If you create one, I'll help out in making it accurate)
Also, make sure you have a look at the new NAT-handling document:
http://www.iptel.org/ser/howtos/optimizing_the_use_of_rtp_proxy
g-)
Many thanks. I've read and reread "Optimizing the use of rtp proxy".
I've
also done a lot more reading on SDP & RTP which is most relevant to the
audio issue. Signalling is not the problem i.e. the messages are passed
back
and forward through the proxy and I'm happy with that. It's the audio I
want
to offload.
I think the key unanswered question I have is this: in the (seemingly)
most
common scenario of two symmetric (signalling and RTP) UAs behind two
different (port) restricted cone NATs, can two-way audio be established
without the use of a media proxy? I had previously thought that was
possible
but the latest reading I have done indicates not. Why? Because one side
must
initiate the audio part of the call and the other side's NAT device will
not
know where to send that audio on the LAN side of the network. Could
someone
put me out of my misery and confirm one way or the other?
I had thought another alternative was to map the RTP ports on the NAT
device. This would mean forwarding ranges of ports to specific IP
addresses
(each different port range relating to a specific UA) on the NAT device.
Each UA would then be configured to send RTP traffic on the port range
relating to its IP address. But if both sides are behind NAT then am I
right
in thinking that this won't work either because the callees NAT device
still
doesn't know where to send it?
Regarding me documenting my solution it looks to me like it's already been
done in "Optimizing the use of rtp proxy"! I'm currently using media proxy
so the main difference would be that the media proxy selection would be
based on the domain rather than an avp.e.g. west.domain.com goes to one
proxy and east.domain.com goes to another.
Cameron
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:56 a.m.
New subject: [Serusers] NAT: minimise media proxying whilst maximising usability
Mon, Sep 25, 2006 at 17:29:39, kjcsb wrote about "Re: [Serusers] NAT: minimise media
proxying whilst maximising usability":
I think the key unanswered question I have is this: in
the (seemingly) most
common scenario of two symmetric (signalling and RTP) UAs behind two
different (port) restricted cone NATs, can two-way audio be established
without the use of a media proxy? I had previously thought that was
possible but the latest reading I have done indicates not. Why? Because one
side must initiate the audio part of the call and the other side's NAT
device will not know where to send that audio on the LAN side of the
network. Could someone put me out of my misery and confirm one way or the
other?
Creating working stream without mediaproxy or rtpproxy is possible
with all cone NATs if UA is able to use STUN, interpret the NAT is
cone-like and update its SDP announces appropriately. Otherwise
it begins to be chicken-and-egg problem: UA2 needs external
address of UA1's RTP port to send packets to UA1; OTOH, UA1 needs
external address of UA2's RTP port to send packets to UA2. If SDP
announces contain external address of RTP port (with SER, it's
possible only when UAs use STUN), this will work. If SDP announces
contain address of intermediate port (of rtpproxy or possible
mediaproxy), this will work. But SER can't fix only SDP because
real RTP stream begins after exchanging announces, but SDP shall
be sent in this exchanging. A kind of B2BUA could fix it, but an
approach with such special B2BUA is toooooo complex as to be used
in production.
Additional complication is that cone-like NATs are inapproproate
for large networks and almost inappropriate for commercial
production. To work, they shall map internal addresses (address as
pair <host, port>) to external ones statically. But internal
address set size is much more than external one (except for
marginal cases) and such mapping will definitely cause conflicts.
That's why symmetric NATs are preferred in large networks, opposed
to cone NATs. And with symmetric NAT, no technique will give you
external address for particular connection; so only real connect
will give such address.
That's why I say STUN in its form according to RFC3489 (as
separate server) is generally useless for SIP+RTP. A bunch of
other techniques can help to detect external address stably;
rtpproxy (1); ICE (which is IETF draft now and, in general, is
adding of STUN capability to each UA's port, either signaling or
media one) (2); of course SOCKS or similar approach will help, but
it is too expensive for large networks (3).
I had thought another alternative was to map the RTP
ports on the NAT
device. This would mean forwarding ranges of ports to specific IP addresses
(each different port range relating to a specific UA) on the NAT device.
Each UA would then be configured to send RTP traffic on the port range
relating to its IP address. But if both sides are behind NAT then am I
right in thinking that this won't work either because the callees NAT
device still doesn't know where to send it?
Your idea is good, but useless:) If you have such mapping (from
internal address to external one independently of remote address)
it's identical to cone NAT. If you have cone NAT, it's much simple
to use STUN than invent some home-grown algorithm for port range
selection and patch UAs to support it.
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com
6640
days inactive
6646
days old
4 comments
4 participants
participants (4)
-
Greger V. Teigre -
kjcsb -
Valentin Nechayev -
Vamsi Pottangi