[Serusers] NAT: minimise media proxying whilst maximising usability

[Greger V. Teigre]

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 at domain.com >;tag=4cdc1208fa650916o0..To: 
> <sip:6435488773 at domain.com>..Call-ID: 
> 1143f50-45857c6e at 192.168.0.14..CSeq: 1 REGISTER..Max-Forwards:  
> 70..Contact: 
> <sip:6435488773 at 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 at domain.com>;tag=dede17c9405d4e0e..To: 
> <sip:5551234 at domain.com>..Contact: 
> <sip:5551234 at 60.234.nnn.nnn:32483>.. Call-ID: 
> fc200867c9a03268 at 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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>