Hello
I have following use case:
Endpoint1 <------> NAT <------> SER <------> NAT <------> Endpoint2 10.0.0.10 TCP TCP 192.168.0.4
Both enpoints are behind a NAT, connected via TCP transport to SER. The problem is that no message can be routed between them. It looks like SER connot find open tcp connection. Here are the error messages copied from the log:
11(13977) build_req_from_req: id added: <;i=e71>, rcv proto=2 11(13977) parse_headers: flags=2048 11(13977) parse_headers: flags=2048 11(13977) parse_headers: flags=-1 11(13977) clen_builder: content-length: 281 (281) 11(13977) check_via_address(63.64.165.70, 10.0.0.10, 0) 11(13977) tcp_send: no open tcp connection found, opening new one 11(13977) ERROR: tcp_blocking_connect: SO_ERROR (113) No route to host 11(13977) ERROR: tcpconn_connect: tcp_blocking_connect failed 11(13977) ERROR: tcp_send: connect failed 11(13977) msg_send: ERROR: tcp_send failed 11(13977) ERROR: t_forward_nonack: sending request failed
The records for TCP subscribers behind a NAT contains local address like: Contact: 'sip:10.0.0.10:12451;transport=tcp' even if the function fix_contact() is called in registration.
So, how to configure SER for serving the TCP endpoints behind a NAT?
Martin
NAT traversal with TCP is only possible, if you configure port forwarding at the NAT boxes, and configure your endpoints to use the configured ports and the public IP in the contact header.
Maybe another solution would be to establish the TCP session always from the endpoint to the SIP proxy. The problem is, as soon as the sip proxy finishes the TCP session, the endpoint has to re-connect again, to be able to receive SIP messages. This also depends on the way ser re-uses existing sessions.
regards klaus
Martin Rusnak wrote:
Hello
I have following use case:
Endpoint1 <------> NAT <------> SER <------> NAT <------> Endpoint2 10.0.0.10 TCP TCP 192.168.0.4
Both enpoints are behind a NAT, connected via TCP transport to SER. The problem is that no message can be routed between them. It looks like SER connot find open tcp connection. Here are the error messages copied from the log:
11(13977) build_req_from_req: id added: <;i=e71>, rcv proto=2 11(13977) parse_headers: flags=2048 11(13977) parse_headers: flags=2048 11(13977) parse_headers: flags=-1 11(13977) clen_builder: content-length: 281 (281) 11(13977) check_via_address(63.64.165.70, 10.0.0.10, 0) 11(13977) tcp_send: no open tcp connection found, opening new one 11(13977) ERROR: tcp_blocking_connect: SO_ERROR (113) No route to host 11(13977) ERROR: tcpconn_connect: tcp_blocking_connect failed 11(13977) ERROR: tcp_send: connect failed 11(13977) msg_send: ERROR: tcp_send failed 11(13977) ERROR: t_forward_nonack: sending request failed
The records for TCP subscribers behind a NAT contains local address like: Contact: 'sip:10.0.0.10:12451;transport=tcp' even if the function fix_contact() is called in registration.
So, how to configure SER for serving the TCP endpoints behind a NAT?
Martin
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On May 22, 2004 at 19:34, Martin Rusnak mafo@cyberspace.sk wrote:
Hello
I have following use case:
Endpoint1 <------> NAT <------> SER <------> NAT <------> Endpoint2 10.0.0.10 TCP TCP 192.168.0.4
First of all try to use UDP. NAT traversal works with UDP. Nobody really tested it with TCP. Theoretically you could get it working with unstable ser, special options and a well behaved UA (one that will always reuse the tcp connections and will keep the nat bindings open).
Both enpoints are behind a NAT, connected via TCP transport to SER. The problem is that no message can be routed between them. It looks like SER connot find open tcp connection. Here are the error messages copied from the log:
Yes, ser cannot find an open tcp connection and tries to open a new one. To get arround this you should force tcp aliases and use a very high timeout for the tcp connections (if a connection is not used, ser will close it after some time): - use tcp_accept_aliases=yes in your ser.cfg if you have compliant UAs (I think only kphone knows about them) - use force_tcp_alias(); if your UAs don't know about tcp alias. - edit tcp_conn.h and change TCP_CON_TIMEOUT and TCP_CON_SEND_TIMEOUT to a very high value
Andrei