| reply to OZO
Re: Is SIP ALG a good solution for NAT? said by OZO:It's very rare to see someone runs its own STUN server. I didn't mean that I would run my own STUN server, rather whether Asterisk is now able to act as a STUN client to be able to find its public address and punch holes in the NAT router just like FreeSwitch can (if I'm correct).
As a reminder, here's the setup I have in mind:
»img46.imageshack.us/img46/6264/sipalg.png
One thing I find puzzling, though, is:
1. With the two SIP clients sitting on either side of the NAT (one local, one on the Internet), should I configure the local SIP client to use STUN, or will the SIP server handle rewriting the IP address in the SIP packets and opening the RTP port on the router?
2. UPnP only opens holes, but doesn't know anything about SIP/RTP so UPnP only solves part of the problem while STUN handles both issues. So I don't see the point of using UPnP for VoIP
3. Direct media mode: In which case is it not a good idea and should we have RTP packets go through the SIP server instead?
Thank you. |
|
OZOPremium
join:2003-01-17
kudos:2 | 1. If you use direct media mode (DMM), and your SIP server doesn't touch SDP part of the INVITE message (FreeSWITCH e.g. doesn't change it in DMM), then you have to make sure that your local SIP client uses STUN (or UPnP) to get and use the WAN IP. My advise, watch INVITE message and particularly its SDP part. Without STUN it will contain c=IN IP4 LAN.LAN.LAN.LAN attribute. While with STUN it's c=IN IP4 WAN.WAN.WAN.WAN. That IP will be used by remote SIP client to send RTP stream to your local client. Again, if your local client is behind NAT, it's better to make sure that the 'o=' attribute contains WAN IP.
Without DMM SIP server rewrites that attribute to point to its own WAN address (which in general case could be not the same as your local SIP client's WAN).
2. Here is example - PhonerLite SIP client doesn't need STUN to work properly. It uses only UPnP (and quite successfully, I might add)
3. Only in case if one of your clients doesn't support it. If SIP server doesn't watch for it (LAN address is used in SDP instead of WAN) and doesn't forcefully change that IP for other client it may break the correct two way audio support. Otherwise, I don't see why don't use DMM all the time (presuming that you don't want to record conversations by SIP server).
DMM always provides a better quality of voice - less latency, less packet losses, etc.
--
Keep it simple, it'll become complex by itself... |
|
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Clear Wireless
| reply to Mango
said by Mango:With SIP Helper turned on, the router will not respect the Assured UDP Timeout and instead uses 3600 seconds. This means that your phone has one hour to re-register and will possibly make Linksys devices workish with their default settings. Is that really a problem?
I think the longest refresh interval I've seen a provider use is maybe 10 minutes. The majority are in the 60-120 second ballpark. |
|
|
|
Reviews:
 ·TekSavvy Cable
 ·voip.ms
| reply to PX Eliezer
said by PX Eliezer:said by erfans:Since we're on this topic, I was wondering if you guys could help me with my DLINK DIR-625 settings.
On the UDP Endpoint Filtering, and also the TCP Endpoint Filtering, try changing both of those to "Address Restricted" instead of "Port and Address Restricted". That works for me on my D-Link DGL 4100 routers. Thanks! voip.ms have advised me to change both of those settings to "Endpoint Independent" because it is the "least restrictive option." I will give your suggestion a try and if that doesn't work out, then I will try what voip.ms has suggested. Thanks once again. |
|
| reply to OZO
said by OZO:1. If you use direct media mode (DMM), and your SIP server doesn't touch SDP part of the INVITE message (FreeSWITCH e.g. doesn't change it in DMM), then you have to make sure that your local SIP client uses STUN (or UPnP) to get and use the WAN IP. [...] Without DMM SIP server rewrites that attribute to point to its own WAN address (which in general case could be not the same as your local SIP client's WAN). Thanks for the clarification. I'm just uneasy about an SIP client registered with an SIP server, both located in the LAN behind the NAT router, while the SIP client uses STUN on its own, but I guess it's irrational.
Am I correct in understanding that those are the issues that must be solved when both the SIP client and the SIP server are located in a LAN behind a NAT router and we want to use DMM so that RTP sound flows directly between the two SIP clients?
1. SIP: In the reply to an incoming INVITE (ie. the remote SIP client is trying to call the local SIP client), the local SIP client's LAN IP address in the SIP reply must be replaced with a WAN IP address as available on the NAT router. This task can be accomplished either by the server or the client
2. RTP: Either the client or the server must reconfigure the NAT router on the fly to open a UDP port for RTP and route those packets to the SIP client, or the SIP client won't hear the remote caller's voice (one-way audio)
said by OZO:2. Here is example - PhonerLite SIP client doesn't need STUN to work properly. It uses only UPnP (and quite successfully, I might add) I've never used UPnP although the NAT router/modem provided by my ISP is supposed to support it:
- Does UPnP support finding out the NAT router's WAN IP(s), which would explain why PhonerLite's doesn't need to support STUN
- With UPnP, does it mean that any application running on any device on the LAN is allowed to open ports on the router? Sounds pretty dangerous, as any virus could then open up the firewall.
said by OZO:Otherwise, I don't see why don't use DMM all the time (presuming that you don't want to record conversations by SIP server). The reason I haven't used DMM yet is that I remember reading that there were cases where it wasn't a good idea. I guess being able to have the server record the conversation is one case, although the client could take care of this. Do you know of other cases where DMM would break things?
Or maybe it works fine, and it's specifically Asterisk that's not supporting DMM as well as other IP PBX's.
Thanks. |
|
| I know why I was uneasy about configuring the LAN SIP client to use STUN instead of letting the SIP server replace the LAN IP with the WAN IP: What about the case where there are other SIP clients in the LAN?
»img528.imageshack.us/img528/6264/sipalg.png
If the SIP clients use STUN, they'll report the WAN IP in the SIP INVITE instead of their LAN IP: In this case, is there another solution than not using STUN for the clients and let the server rewrite IP's when necessary (ie. when the SIP client is on the WAN side)? |
|
| reply to vincentdelpo
Here is an example of a problem caused by SIP ALG in Verizon Wireless router.
»[Asterisk] re-invites fail Verizon Wireless 3G or 4G
--
Lifespeed |
|
OZOPremium
join:2003-01-17
kudos:2 | reply to vincentdelpo
said by vincentdelpo:Am I correct in understanding that those are the issues that must be solved when both the SIP client and the SIP server are located in a LAN behind a NAT router and we want to use DMM so that RTP sound flows directly between the two SIP clients?
1. SIP: In the reply to an incoming INVITE (ie. the remote SIP client is trying to call the local SIP client), the local SIP client's LAN IP address in the SIP reply must be replaced with a WAN IP address as available on the NAT router. This task can be accomplished either by the server or the client
2. RTP: Either the client or the server must reconfigure the NAT router on the fly to open a UDP port for RTP and route those packets to the SIP client, or the SIP client won't hear the remote caller's voice (one-way audio)
Answers to your questions:
1. Yes
2. Yes
said by OZO:2. Here is example - PhonerLite SIP client doesn't need STUN to work properly. It uses only UPnP (and quite successfully, I might add) I've never used UPnP although the NAT router/modem provided by my ISP is supposed to support it: - Does UPnP support finding out the NAT router's WAN IP(s), which would explain why PhonerLite's doesn't need to support STUN - With UPnP, does it mean that any application running on any device on the LAN is allowed to open ports on the router? Sounds pretty dangerous, as any virus could then open up the firewall.
- Yes, it does. But the same (uncontrolled communications) could be achieved without UPnP. Any program on your computer may open new connection to any host on the Internet and download anything and then run it. The only solution is local outbound firewall that blocks all your applications from opening any connections without your consent.
BTW, ironically you don't need a local firewall to protect your computer from inbound connections (your NAT routed does that). But you need "outbound" firewall to keep your computers secure...
said by OZO:Otherwise, I don't see why don't use DMM all the time (presuming that you don't want to record conversations by SIP server). The reason I haven't used DMM yet is that I remember reading that there were cases where it wasn't a good idea. I guess being able to have the server record the conversation is one case, although the client could take care of this. Do you know of other cases where DMM would break things?
DMM should always work fine, even in case when both your SIP clients are on the same LAN. The only problem that I know of could come from a cheap NAT router, that doesn't support loopback correctly. Any decent router can easily handle connection made to its WAN address and redirect it to local LAN IP.
--
Keep it simple, it'll become complex by itself... |
|
OZOPremium
join:2003-01-17
kudos:2 | reply to vincentdelpo
said by vincentdelpo:If the SIP clients use STUN, they'll report the WAN IP in the SIP INVITE instead of their LAN IP: In this case, is there another solution than not using STUN for the clients and let the server rewrite IP's when necessary (ie. when the SIP client is on the WAN side)?
SIP server could do it, if ... it supports the feature. I'd not bet on it though. I prefer my clients always set WAN IP for media stream, in case they're behind the NAT (and it's same LAN for SIP server or other SIP clinet) or not. And one of the reasons why I do it - I set it and I forget it... It's especially beneficial for clients, that are mobile (can easily change their location - one moment it's on LAN, then next time - it's on a remote location).
--
Keep it simple, it'll become complex by itself... |
|
| reply to OZO
said by OZO:DMM should always work fine, even in case when both your SIP clients are on the same LAN. The only problem that I know of could come from a cheap NAT router, that doesn't support loopback correctly. Any decent router can easily handle connection made to its WAN address and redirect it to local LAN IP. But this (loopback) would have to be specifically configured by the user, correct? Otherwise a mobile SIP client currently registered on the LAN, for example, that is configured to use the WAN Fully Qualified Domain Name (dynamic IP, so WAN IP use is impractical) would go out on the net, and then loopback to the router, adding 10s of milliseconds of ping, right?
--
Lifespeed |
|
OZOPremium
join:2003-01-17
kudos:2 | You don't need to do anything with your router in order to use the loopback. It's either implemented in the router or not. Some cheap routers do not offer that support, but majority of more or less sophisticated routers do.
The idea behind it is very simple. SIP client sends IP packet to WAN address and the router, instead of sending it any further, recognizes that it contains its own WAN IP as destination address. After that everything goes the way it usually go when a packet arrives on the WAN port. If there is NAT forwarding rule - it's applied to that packet as usual and router sends the packet to appropriate host (and not to the Internet). It happens immediately and of cause you'll not see any 10ms delay.
--
Keep it simple, it'll become complex by itself... |
|
| said by OZO:You don't need to do anything with your router in order to use the loopback. It's either implemented in the router or not. Some cheap routers do not offer that support, but majority of more or less sophisticated routers do.
The idea behind it is very simple. SIP client sends IP packet to WAN address and the router, instead of sending it any further, recognizes that it contains its own WAN IP as destination address. After that everything goes the way it usually go when a packet arrives on the WAN port. If there is NAT forwarding rule - it's applied to that packet as usual and router sends the packet to appropriate host (and not to the Internet). It happens immediately and of cause you'll not see any 10ms delay. Any way I can confirm this behavior on my router? It is not a cheapie - Draytek 2130. It is not mentioned in the 240+ page user guide. I assume this works for any type of packet, not just SIP.
--
Lifespeed |
|
OZOPremium
join:2003-01-17
kudos:2 | Just start using it - it's the simplest way to confirm, f it works (or not)...
If you have any service, that opens one of your WAN ports, try to use it from LAN. For example, HTTP server, running on LAN and is accessible form the Internet. Any service will help you to check. If you do have one, make a connection from host running on LAN to that service using your WAN IP (and not LAN IP). If it works, then the loopback is supported. If it's not - investigate why. The reason could be - your router doesn't have that loopback support.
--
Keep it simple, it'll become complex by itself... |
|
1 edit | A service that is not exposed by port forwarding . . .
Edit: I don't understand how this would work. If I have port 21 open for my FTP server, for example, and I go to my.dyndns.org from my LAN it will work.
How do I know it was routed internally rather than went out on the internet and 'came back in', so to speak. I would expect both examples to work, the only difference being 10s of milliseconds delay. |
|
Reviews:
·TekSavvy Cable
·voip.ms
| reply to PX Eliezer
said by PX Eliezer:said by erfans:Since we're on this topic, I was wondering if you guys could help me with my DLINK DIR-625 settings.
On the UDP Endpoint Filtering, and also the TCP Endpoint Filtering, try changing both of those to "Address Restricted" instead of "Port and Address Restricted". That works for me on my D-Link DGL 4100 routers. You know what, this might have fixed my problem! Thank you so much! |
|
