Hi,
I am trying to force incoming calls destined for a UA behind a symmetric NAT through rtpproxy. In order to distinguish between those agents behind a NAT and those out in the open, I saved their location in two different tables upon registration. It now appears that even though I set db_mode to '1' to force usrloc to immediately write-back all data to the db, ser remembers a successful registration in the regular location tables.
A REGISTER request is immediately written into my NAT tables while the regular tables follows only a little later. When I call the UA in question ser will find the agent in my regular location table. When I manually delete the UA entry from the location table (and restart ser!) my configuration will force the rtp stream just as expected.
Can anybody enlighten my whether this is a bug or a feature? Also I would be very interested in learning how to handle UAs behind symmetric NATs or how to keep state learned at registration time.
I attached parts of my configuration hoping to clarify what I am trying to do.
Thilo
P.S.: this is ser 0.8.12
if (method=="REGISTER") { if ("header indicates symmetric NAT") { save("natlocation"); } else { save("location"); }; };
[...]
if ((method==INVITE)) { if(lookup("location")) { xlog("L_ERR", "UA found in 'location'\n"); } else { if(lookup("natlocation")) { xlog("L_ERR", "UA found in 'natlocation'\n"); force_rtp_proxy(); t_on_reply("2"); } else { sl_send_reply("404", "Not Found"); break; }; }; };
[...]
onreply_route[2] { if (status=~"2[0-9][0-9]"){ xlog("L_ERR", "forcing rtp stream back from NATed UA through localhost\n"); force_rport(); force_rtp_proxy(); }; }
Turns out I tripped over my ser.cfg which is clattered with comments. I just found an uncommented second save command later in my configuration.
Please, take my Email as a sample solution for calling UAs behind symmetric NATs rather and a problem description ;-)
Sorry, again.
Thilo
Looks quite useful. It would probably work great with the Grandstream phones since they do include a Header Field which will say if the NAT is Symmetric or not.
What other UA's are you using that include this header field?
Andres.
On Monday 29 December 2003 11:10, Thilo Salmon wrote:
Turns out I tripped over my ser.cfg which is clattered with comments. I just found an uncommented second save command later in my configuration.
Please, take my Email as a sample solution for calling UAs behind symmetric NATs rather and a problem description ;-)
Sorry, again.
Thilo
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
The UA in question is indeed a Grandstream phone and I have not seen any others showing this behaviour. On a quest for such agents you can probably skip any agents without STUN support, I guess. Afaik, that does not leave you with too many options. I personally only know about Grandstream, X-ten and Snom. If you know others, I would be very interesting to learn which ones.
On a side: A good start would also to avoid symmetric NATs. I would love to compile a list of routers which operate symmetric NATs to tell my customers to avoid them. I tried a number of residential routers, but all of them did some sort of coned NAT. Who could name symmetric NATs?
Thilo
On Mon, 2003-12-29 at 18:22, Andres wrote:
Looks quite useful. It would probably work great with the Grandstream phones since they do include a Header Field which will say if the NAT is Symmetric or not.
What other UA's are you using that include this header field?
On Monday 29 December 2003 12:57, Thilo Salmon wrote:
The UA in question is indeed a Grandstream phone and I have not seen any others showing this behaviour. On a quest for such agents you can probably skip any agents without STUN support, I guess. Afaik, that does not leave you with too many options. I personally only know about Grandstream, X-ten and Snom. If you know others, I would be very interesting to learn which ones.
ATA186(fw 3.0.0) and Sipura SPA2000 both have STUN Support. I have asked for this "Header" feature to Sipura and they are thinking about it.
On a side: A good start would also to avoid symmetric NATs. I would love to compile a list of routers which operate symmetric NATs to tell my customers to avoid them. I tried a number of residential routers, but all of them did some sort of coned NAT. Who could name symmetric NATs?
Linux NAT is symmetric and is quite common with small businesses. We use the RTPProxy in these cases.
Andres.
Thilo
On Mon, 2003-12-29 at 18:22, Andres wrote:
Looks quite useful. It would probably work great with the Grandstream phones since they do include a Header Field which will say if the NAT is Symmetric or not.
What other UA's are you using that include this header field?
Hi,
On a side: A good start would also to avoid symmetric NATs. I would love to compile a list of routers which operate symmetric NATs to tell my customers to avoid them.
Yupp, i thought about that too.
I tried a number of residential routers, but
all of them did some sort of coned NAT. Who could name symmetric NATs?
Linux NAT is symmetric and is quite common with small businesses. We use the RTPProxy in these cases.
freeBSD is per default symetric too. There is a small patch though which makes it into a full cone NAT.
We have currently cisco ATA's 186 and the grandstream working with the current CVS release and the NAT support/RTP Proxy.
Great software btw!
regards,
Arnd
On Mon, 2003-12-29 at 20:41, Andres wrote: [Detecting UAC behind symmetric NAT based on Header fields]
ATA186(fw 3.0.0) and Sipura SPA2000 both have STUN Support. I have asked for this "Header" feature to Sipura and they are thinking about it.
Thinking about a general solution the following came to my mind: How about setting up a 2nd UAS listening at a 2nd IP address and configure the registrar to forward REGISTER messages from UACs found to be behind a NAT to this 2nd UAS. This other UAS could then test whether or not it can "ping" the UAC. Unless this 2nd server would receive a reply from the UAC, we could assume that the UAC is behind a symmetric NAT. On success this second UAS would then notify the registrar to not force UAC's rtp stream through a local proxy.
Such as
UAS A --------> UAS B <------- /\ \ 6. / /\ \ \ / / \ \ / / \ \ 2. 4. / / \ \ / / 1. \ \ / / \ \ / / 5. \ \ / / \ \ / / \ \ / / \ / / /
UAC
with UAS A being the "real" registrar and UAS B being the UAS testing for the type of NAT.
1. REGISTER 2. 200 OK 3. same message as 1.) 4. OPTIONS 5. 200 OK or 486 BUSY 6. ???
However, setting this up I ran into two issues.
I configured UAS B to issue an OPTIONS message by calling exec_msg("serctl ping"). I have no idea to do this stateful and did not find any mandatory header fields in the reply ("contact" appears not to be mandatory according to RFC 3261), which would reveal the identity of the UAC.
Also, I wonder what message one could use for the 6th message. '200 OK' as a reply to the 3rd message seems to make the most sense, but I noticed that one cannot use usrloc's save command inside onreply_route[]. Is there a message type that can be used for this sort of notification?
Thilo
That's too complex and I couldn't see what is this good for. There is no way of notifying the registrar. Registrar can only receive REGISTER requests, process them and send a reply.
If I understand it correctly you try to mimic STUN with SIP, but that will result in unwanted overhead.
If you want to eliminate the RTP proxy when two UAs are behind the same NAT then you could use Via and Request-URI of the INVITE message to find out whether they are behind the same NAT.
Jan.
On 05-01 18:03, Thilo Salmon wrote:
On Mon, 2003-12-29 at 20:41, Andres wrote: [Detecting UAC behind symmetric NAT based on Header fields]
ATA186(fw 3.0.0) and Sipura SPA2000 both have STUN Support. I have asked for this "Header" feature to Sipura and they are thinking about it.
Thinking about a general solution the following came to my mind: How about setting up a 2nd UAS listening at a 2nd IP address and configure the registrar to forward REGISTER messages from UACs found to be behind a NAT to this 2nd UAS. This other UAS could then test whether or not it can "ping" the UAC. Unless this 2nd server would receive a reply from the UAC, we could assume that the UAC is behind a symmetric NAT. On success this second UAS would then notify the registrar to not force UAC's rtp stream through a local proxy.
Such as
UAS A --------> UAS B <------- /\ \ 6. / /\ \ \ / / \ \ / / \ \ 2. 4. / / \ \ / / 1. \ \ / / \ \ / / 5. \ \ / / \ \ / / \ \ / / \ / / /
UACwith UAS A being the "real" registrar and UAS B being the UAS testing for the type of NAT.
- REGISTER
- 200 OK
- same message as 1.)
- OPTIONS
- 200 OK or 486 BUSY
- ???
However, setting this up I ran into two issues.
I configured UAS B to issue an OPTIONS message by calling exec_msg("serctl ping"). I have no idea to do this stateful and did not find any mandatory header fields in the reply ("contact" appears not to be mandatory according to RFC 3261), which would reveal the identity of the UAC.
Also, I wonder what message one could use for the 6th message. '200 OK' as a reply to the 3rd message seems to make the most sense, but I noticed that one cannot use usrloc's save command inside onreply_route[]. Is there a message type that can be used for this sort of notification?
Thilo
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Quoting Jan Janak jan@iptel.org:
That's too complex and I couldn't see what is this good for. There is no way of notifying the registrar. Registrar can only receive REGISTER requests, process them and send a reply.
If I understand it correctly you try to mimic STUN with SIP, but that will result in unwanted overhead.
That is exactly what I am trying to do and here is why: In a network with only STUN-enabled UACs I want to proxy rtp soley for clients behind symmetric NATs as all other NATs can be traversed without external help. Trouble is, the UAS has no way of knowing which type of NAT a STUN enabled UAC is located behind, unless the UAC submits this information (e.g. Grandstream UAs append a 'warning' header field). To the best of my knowledge there is no defined standard to transmit this information and Grandstream is the only UA to carry it in a header field.
Hence, the idea of setting up a STUN like mechanism to test for the type of NAT a UAC is behind and store it in the registrar's location database.
Thilo
Well, if the UAs use STUN properly, that means they use STUN only when they detect a NAT that can be traversed with STUN, then it should work.
STUN will make the messages to look like they were coming from a UA in the public internet and thus the nathelper will not force the RTP proxy.
UAs behind symmetric NAT should not use STUN-obtained IP addresses (because it would be useless anyway) and send private IP addresses. In this case the nathelper module will detect that the UA is behind a NAT and force RTP proxy.
Jan.
On 05-01 23:40, salmon@netzquadrat.de wrote:
Quoting Jan Janak jan@iptel.org:
That's too complex and I couldn't see what is this good for. There is no way of notifying the registrar. Registrar can only receive REGISTER requests, process them and send a reply.
If I understand it correctly you try to mimic STUN with SIP, but that will result in unwanted overhead.
That is exactly what I am trying to do and here is why: In a network with only STUN-enabled UACs I want to proxy rtp soley for clients behind symmetric NATs as all other NATs can be traversed without external help. Trouble is, the UAS has no way of knowing which type of NAT a STUN enabled UAC is located behind, unless the UAC submits this information (e.g. Grandstream UAs append a 'warning' header field). To the best of my knowledge there is no defined standard to transmit this information and Grandstream is the only UA to carry it in a header field.
Hence, the idea of setting up a STUN like mechanism to test for the type of NAT a UAC is behind and store it in the registrar's location database.
Thilo
On Tue, 2004-01-06 at 01:39, Jan Janak wrote:
Well, if the UAs use STUN properly, that means they use STUN only when they detect a NAT that can be traversed with STUN, then it should work.
STUN will make the messages to look like they were coming from a UA in the public internet and thus the nathelper will not force the RTP proxy.
UAs behind symmetric NAT should not use STUN-obtained IP addresses (because it would be useless anyway) and send private IP addresses. In this case the nathelper module will detect that the UA is behind a NAT and force RTP proxy.
You are right. I was only looking at the call-id header field. The Grandstream UAs I was testing with (firmware 1.0.3.81 and 1.0.4.26) used RFC 1918 addresses in that field no matter what type of NAT they were behind. They fix the contact header field, though, _unless_ you they are behind a symmetric NAT.
Thanks for pointing this out to me.
Thilo
At 06:57 PM 12/29/2003, Thilo Salmon wrote:
The UA in question is indeed a Grandstream phone and I have not seen any others showing this behaviour. On a quest for such agents you can probably skip any agents without STUN support, I guess. Afaik, that does not leave you with too many options. I personally only know about Grandstream, X-ten and Snom. If you know others, I would be very interesting to learn which ones.
iptel will have such soon, I will be happy to take any inquiries off-line.
On a side: A good start would also to avoid symmetric NATs. I would love to compile a list of routers which operate symmetric NATs to tell my customers to avoid them. I tried a number of residential routers, but all of them did some sort of coned NAT. Who could name symmetric NATs?
sipphone.com maintains a list of such NATs. for example, linux nats are symmetric.
-jiri
Thilo Salmon wrote:
The UA in question is indeed a Grandstream phone and I have not seen any others showing this behaviour. On a quest for such agents you can probably skip any agents without STUN support, I guess. Afaik, that does not leave you with too many options. I personally only know about Grandstream, X-ten and Snom. If you know others, I would be very interesting to learn which ones.
Check here for a list, but as of now, it's the same as yours: http://www.voip-info.org/tiki-index.php?page=STUN
On a side: A good start would also to avoid symmetric NATs. I would love to compile a list of routers which operate symmetric NATs to tell my customers to avoid them. I tried a number of residential routers, but all of them did some sort of coned NAT. Who could name symmetric NATs?
Someone started a list here: http://www.voip-info.org/wiki-NAT+survey
It would be great if we could add to that list.
Regards, /Olle
At 06:22 PM 12/29/2003, Andres wrote:
Looks quite useful. It would probably work great with the Grandstream phones since they do include a Header Field which will say if the NAT is Symmetric or not.
What other UA's are you using that include this header field?
I agree that's a great help for diagnosis, I would just appreciate if it done using SIP-compliant syntax. I'm not aware of other SIP phone doing so.
-jiri
-
Andres -
Arnd Vehling -
Jan Janak -
Jiri Kuthan -
Olle E. Johansson -
salmon＠netzquadrat.de -
Thilo Salmon