Make sure you are not behind a Symmetric NAT. If so, you're dead. STUN does not work with Symmetric NAT.
If a UA is behind Symmetric NAT, and UA use STUN, and SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not configure STUN to it. I'd just led mediaproxy solve the problem.
Regards,
Lucas
But if you have 100 clients, it would be hard to put all clients in one group.
Mohammad
-------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
Make sure you are not behind a Symmetric NAT. If so, you're dead. STUN does not work with Symmetric NAT.
If a UA is behind Symmetric NAT, and UA use STUN, and SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not configure STUN to it. I'd just led mediaproxy solve the problem.
But if you have 100 clients, it would be hard to put all clients in one group.
Good point !
Yes, it is true. If stun can not solve the nat problem, media proxy should fix it with no trouble at all.
Regards,
Lucas
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
Thanks
Lada
Make sure you are not behind a Symmetric NAT. If so, you're dead. STUN does not work with Symmetric NAT.
If a UA is behind Symmetric NAT, and UA use STUN, and SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not configure STUN to it. I'd just led mediaproxy solve the problem.
But if you have 100 clients, it would be hard to put all clients in one group.
LA> Good point !
LA> Yes, it is true. If stun can not solve the nat problem, media proxy LA> should fix it with no trouble at all.
LA> Regards,
LA> Lucas
Make sure you are not behind a Symmetric NAT. If so, you're dead. STUN does not work with Symmetric NAT.
If a UA is behind Symmetric NAT, and UA use STUN, and SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not configure STUN to it. I'd just led mediaproxy solve the problem.
But if you have 100 clients, it would be hard to put all clients in one group.
LA> Good point !
LA> Yes, it is true. If stun can not solve the nat problem, media proxy LA> should fix it with no trouble at all.
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
It is not a matter of priorities. It depends on how you get your mediaproxy configured. You need to be aware that nated clients should use the media proxy, because of the nat problem. But, if your client can find ( using stun for example ) his public ip/port, then, from mediaproxy point of view, this client is not nated, and so, it needs not treatment ( no fixing from part of media proxy ).
You can always do this: Get every traffic proxied along mediaproxy. But, if clients can talk to each other being able to bypass mediaproxy, why should you proxy your communications ???
Hope to be clear
Regards,
Lucas
> Make sure you are not behind a Symmetric NAT. If so, you're > dead. STUN does not work with Symmetric NAT.
If a UA is behind Symmetric NAT, and UA use STUN, and SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not configure STUN to it. I'd just led mediaproxy solve the problem.
But if you have 100 clients, it would be hard to put all clients in one group.
LA> Good point !
LA> Yes, it is true. If stun can not solve the nat problem, media proxy LA> should fix it with no trouble at all.
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
LA> It is not a matter of priorities. It depends on how you get your LA> mediaproxy configured. You need to be aware that nated clients should LA> use the media proxy, because of the nat problem. But, if your client can LA> find ( using stun for example ) his public ip/port, then, from LA> mediaproxy point of view, this client is not nated, and so, it needs not LA> treatment ( no fixing from part of media proxy ).
LA> You can always do this: Get every traffic proxied along mediaproxy. But, LA> if clients can talk to each other being able to bypass mediaproxy, why LA> should you proxy your communications ???
LA> Hope to be clear
LA> Regards,
LA> Lucas
Thank you, it makes sence. It would be the best solution I'd say, but it reminds me JavaRocks statement that STUN makes problems in some circumstances.. Just wondering what problems? Maybe some UA's not supporting STUN?
Lada
> > Make sure you are not behind a Symmetric NAT. If
so, you're
> > dead. STUN does not work with Symmetric NAT. > > If a UA is behind Symmetric NAT, and > UA use STUN, and > SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA > should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not
configure
STUN to it. I'd just led mediaproxy solve the problem.
But if you have 100 clients, it would be hard to put all clients in one group.
LA> Good point !
LA> Yes, it is true. If stun can not solve the nat problem, media proxy LA> should fix it with no trouble at all.
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
LA> It is not a matter of priorities. It depends on how you get your LA> mediaproxy configured. You need to be aware that nated clients LA> should use the media proxy, because of the nat problem. But, if your LA> client can find ( using stun for example ) his public ip/port, then, LA> from mediaproxy point of view, this client is not nated, and so, it LA> needs not treatment ( no fixing from part of media proxy ).
LA> You can always do this: Get every traffic proxied along mediaproxy. LA> But, if clients can talk to each other being able to bypass LA> mediaproxy, why should you proxy your communications ???
LA> Hope to be clear
LA> Regards,
LA> Lucas
Thank you, it makes sence. It would be the best solution I'd say, but it reminds me JavaRocks statement that STUN makes problems in some circumstances.. Just wondering what problems? Maybe some UA's not supporting STUN?
The only circumstances that I know where STUN does not help is when the UA is located behind a symmetric nat. In the othre 3 cases of nat, it should help you just fine. Or if the clients do not implement a good stun-client or the stun server does not implement the protocol correctly. But, let say that every body follows the standars ( JA!, ask cisco ) ... you should not have problems at all.
Regards,
Lucas
Lucas Aimaretto schrieb:
>>>Make sure you are not behind a Symmetric NAT. If >>> >>>
so, you're
>>>dead. STUN does not work with Symmetric NAT. >>> >>> >>If a UA is behind Symmetric NAT, and >>UA use STUN, and >>SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA >>should be fine, right? >> >> >Yes, but, if UA is behind symmetric NAT, I would not > >
configure
>STUN to it. I'd just led mediaproxy solve the problem. > > But if you have 100 clients, it would be hard to put all clients in one group.
LA> Good point !
LA> Yes, it is true. If stun can not solve the nat problem, media proxy LA> should fix it with no trouble at all.
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
LA> It is not a matter of priorities. It depends on how you get your LA> mediaproxy configured. You need to be aware that nated clients LA> should use the media proxy, because of the nat problem. But, if your LA> client can find ( using stun for example ) his public ip/port, then, LA> from mediaproxy point of view, this client is not nated, and so, it LA> needs not treatment ( no fixing from part of media proxy ).
LA> You can always do this: Get every traffic proxied along mediaproxy. LA> But, if clients can talk to each other being able to bypass LA> mediaproxy, why should you proxy your communications ???
LA> Hope to be clear
LA> Regards,
LA> Lucas
Thank you, it makes sence. It would be the best solution I'd say, but it reminds me JavaRocks statement that STUN makes problems in some circumstances.. Just wondering what problems? Maybe some UA's not supporting STUN?
The only circumstances that I know where STUN does not help is when the UA is located behind a symmetric nat. In the othre 3 cases of nat, it should help you just fine. Or if the clients do not implement a good stun-client or the stun server does not implement the protocol correctly. But, let say that every body follows the standars ( JA!, ask cisco ) ... you should not have problems at all.
Regards,
Lucas
Hi everyone!
There's another problem with STUN: If you have two UAs behind the *same* (not symmetric) NAT and the NAT doesn't support hairpinning (i.e. sending data back in the direction of the source in order to reach the target) RTP traffic won't work. Each client tries to send its RTP stream to the external port of the firewall which in this case wouldn't send the packets back into the net. So those 2 UAs wouldn't be able to communicate when traffic isn't handled by an external RTP Relay (e.g. MediaProxy, RTPProxy, etc.)
The WinStun-Client from Vovida can detect if your NAT supports hairpinning.
Talking about priorities: STUN beats Mediaproxy, because SER can't distinguish between a NAT'ed STUN client and a client with a real public IP. That's no problem as long as you don't have two UAs behind the same hairpinning-disabled NAT.
Alex Mack
There's another problem with STUN: If you have two UAs behind the *same* (not symmetric) NAT and the NAT doesn't support hairpinning (i.e. sending data back in the direction of the source in order to reach the target) RTP traffic won't work. Each client tries to send its RTP stream to the external port of the firewall which in this case wouldn't send the packets back into the net. So those 2 UAs wouldn't be able to communicate when traffic isn't handled by an external RTP Relay (e.g. MediaProxy, RTPProxy, etc.)
Well, that's true, but you can test to see if the public IP of caller and callee is the same. Of course, you cannot be completely sure whether there are a couple of other NATs behind the public one, but just in case, you should proxy the call to avoid the hairpinning problem.
The WinStun-Client from Vovida can detect if your NAT supports hairpinning.
Which of course doesn't help much, because you need to rely on the user client's STUN implementation. g-)
Talking about priorities: STUN beats Mediaproxy, because SER can't distinguish between a NAT'ed STUN client and a client with a real public IP. That's no problem as long as you don't have two UAs behind the same hairpinning-disabled NAT.
Alex Mack wrote:
Lucas Aimaretto schrieb:
>>>> Make sure you are not behind a Symmetric NAT. If >>>> >>>>
so, you're
>>>> dead. STUN does not work with Symmetric NAT. >>>> >>>> >>> If a UA is behind Symmetric NAT, and >>> UA use STUN, and >>> SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA >>> should be fine, right? >>> >>> >> Yes, but, if UA is behind symmetric NAT, I would not >> >>
configure
>> STUN to it. I'd just led mediaproxy solve the problem. >> >> > But if you have 100 clients, > it would be hard to put all clients in one group. > > > Good point !
> Yes, it is true. If stun can not solve the nat problem, media proxy > should fix it with no trouble at all.
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
It is not a matter of priorities. It depends on how you get your mediaproxy configured. You need to be aware that nated clients should use the media proxy, because of the nat problem.
But, if your
client can find ( using stun for example ) his public
ip/port, then,
from mediaproxy point of view, this client is not nated,
and so, it
needs not treatment ( no fixing from part of media proxy ).
You can always do this: Get every traffic proxied along
mediaproxy.
But, if clients can talk to each other being able to bypass mediaproxy, why should you proxy your communications ???
Hope to be clear
Regards,
Lucas
Thank you, it makes sence. It would be the best solution I'd say, but it reminds me JavaRocks statement that STUN makes problems in some circumstances.. Just wondering what problems? Maybe some UA's not supporting STUN?
The only circumstances that I know where STUN does not help is when the UA is located behind a symmetric nat. In the othre 3 cases of nat, it should help you just fine. Or if the clients do not implement a good stun-client or the stun server does not implement the protocol correctly. But, let say that every body follows the standars ( JA!, ask cisco ) ... you should not have problems at all.
Regards,
Lucas
Hi everyone!
There's another problem with STUN: If you have two UAs behind the *same* (not symmetric) NAT and the NAT doesn't support hairpinning (i.e. sending data back in the direction of the source in order to reach the target) RTP traffic won't work. Each client tries to send its RTP stream to the external port of the firewall which in this case wouldn't send the packets back into the net. So those 2 UAs wouldn't be able to communicate when traffic isn't handled by an external RTP Relay (e.g. MediaProxy, RTPProxy, etc.) The WinStun-Client from Vovida can detect if your NAT supports hairpinning. Talking about priorities: STUN beats Mediaproxy, because SER can't distinguish between a NAT'ed STUN client and a client with a real public IP. That's no problem as long as you don't have two UAs behind the same hairpinning-disabled NAT.
Alex Mack
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 11:03 PM 4/7/2005, Lucas Aimaretto wrote:
The only circumstances that I know where STUN does not help is when the UA is located behind a symmetric nat. In the othre 3 cases of nat, it should help you just fine. Or if the clients do not implement a good stun-client or the stun server does not implement the protocol correctly. But, let say that every body follows the standars ( JA!, ask cisco ) ... you should not have problems at all.
It is worse than that. The STUN taxonomy is brittle, there are NATs which feature different behaviour than anticipated in RFC3489.
see http://ietfreport.isoc.org/ids/draft-jennings-behave-test-results-00.txt
-jiri
It is worse than that. The STUN taxonomy is brittle, there are NATs which feature different behaviour than anticipated in RFC3489.
Right. There is one we like to call the crap-nat. This nat changes the source UDP port every few seconds. So once the media flow is established it only works for 2-3 seconds until the nat switches to another source port. Needles to say there is absolutely no way to make VoIP work unders these conditions. We encounter one of these every few weeks, and the only solution is to have the customer change the NAT device he is using. (these are usually ADSL modems with inbuilt router)
Andres wrote:
It is worse than that. The STUN taxonomy is brittle, there are NATs which feature different behaviour than anticipated in RFC3489.
Right. There is one we like to call the crap-nat. This nat changes the source UDP port every few seconds. So once the media flow is established it only works for 2-3 seconds until the nat switches to another source port. Needles to say there is absolutely no way to make VoIP work unders these conditions. We encounter one of these every few weeks, and the only solution is to have the customer change the NAT device he is using. (these are usually ADSL modems with inbuilt router)
Wouldnt it be a good idea to document such things, ie create a repository about what NAT devices actually work.
Just an easy list of
Vendor, Modell, NAT type, Work [yes|no], Any special step needed to get it to work etc.
I wouldnt mind help administering it, if it maybe could be hosted on onsip.org or similar sites.
Pedro
Pedro, We have already created a link category called "SER-tested SIP clients" at ONsip.org: http://www.onsip.org/modules/mylinks/viewcat.php?cid=15
I don't know if this is what you and others would like to see, but each of the links to client scan be voted on and people can add comments with their experiences. This way the list of clients can be ever expanding and people can easily add their own opinions and we avoid a static list. I see a problem with the lack of structure, so if you have an idea for how to do it in a better way, but still keep the dynamic aspects, I'm listening :-) g-)
Jan Pedro Tumusok wrote:
Andres wrote:
It is worse than that. The STUN taxonomy is brittle, there are NATs which feature different behaviour than anticipated in RFC3489.
Right. There is one we like to call the crap-nat. This nat changes the source UDP port every few seconds. So once the media flow is established it only works for 2-3 seconds until the nat switches to another source port. Needles to say there is absolutely no way to make VoIP work unders these conditions. We encounter one of these every few weeks, and the only solution is to have the customer change the NAT device he is using. (these are usually ADSL modems with inbuilt router)
Wouldnt it be a good idea to document such things, ie create a repository about what NAT devices actually work.
Just an easy list of
Vendor, Modell, NAT type, Work [yes|no], Any special step needed to get it to work etc.
I wouldnt mind help administering it, if it maybe could be hosted on onsip.org or similar sites.
Pedro
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
sorry I just read your post you sent an hour ago so ignore my last message, thanks.
Lada
> Make sure you are not behind a Symmetric NAT. If so, you're > dead. STUN does not work with Symmetric NAT.
If a UA is behind Symmetric NAT, and UA use STUN, and SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA should be fine, right?
Yes, but, if UA is behind symmetric NAT, I would not configure STUN to it. I'd just led mediaproxy solve the problem.
But if you have 100 clients, it would be hard to put all clients in one group.
LA> Good point !
LA> Yes, it is true. If stun can not solve the nat problem, media proxy LA> should fix it with no trouble at all.
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
LA> It is not a matter of priorities. It depends on how you get your LA> mediaproxy configured. You need to be aware that nated clients should LA> use the media proxy, because of the nat problem. But, if your client can LA> find ( using stun for example ) his public ip/port, then, from LA> mediaproxy point of view, this client is not nated, and so, it needs not LA> treatment ( no fixing from part of media proxy ).
LA> You can always do this: Get every traffic proxied along mediaproxy. But, LA> if clients can talk to each other being able to bypass mediaproxy, why LA> should you proxy your communications ???
LA> Hope to be clear
LA> Regards,
LA> Lucas
Ladislav Andel wrote:
If there is no symmetric NAT and I have installed STUN and Mediaproxy on my server. Which one will have higher priority to handle this call session? Is it always STUN? Of course if I don't need to pass the call to PSTN gateway. Just IP-phone to IP-phone. Can you set the priority in ser.cfg? and how?
This depends on the client. If the client uses STUN and can traverse the NAT, then ser will not detect a NATed client and should not enforce rtpproxy/nathhelper.
regards, klaus
-
Alex Mack -
Andres -
Greger V. Teigre -
infoļ¼ beeplove.com -
Jan Pedro Tumusok -
Jiri Kuthan -
Klaus Darilion -
Ladislav Andel -
Lucas Aimaretto