[OpenSER-Devel] [ openser-Feature Requests-1732039 ] tcp_send() routine tries to connect to UA

Mon Dec 10 13:48:05 UTC 2007

Feature Requests item #1732039, was opened at 2007-06-06 13:31
Message generated for change (Comment added) made by a_olehnovich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743023&aid=1732039&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kovalevich Victor (vkc1974)
Assigned to: Nobody/Anonymous (nobody)
Summary: tcp_send() routine tries to connect to UA

Initial Comment:
int tcp_send(struct socket_info* send_sock, int type, char* buf, unsigned len, union sockaddr_union* to, int id) (tcp_main.c:680) tries to restore TCP connection with UA site if there are no valid and actual connections in USRLOC. Is good behavior?
This operation is senseless especially in the case of an UA working behind a NAT. Furthermore this operation blocks openser service for a while and eventually causes it to be unavailable.

----------------------------------------------------------------------

Comment By: a.olehnovich (a_olehnovich)
Date: 2007-12-10 13:48

Message:
Logged In: YES 
user_id=1956662
Originator: NO

Hi,
Please, have a look at rfc3261 "18.1.1 Sending Requests".
The only thing I've found about the opening new tcp connections from the
server side is:
"   For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.  ***Under error conditions, the
   server may attempt to open a new connection to send the response.*** 
To
   handle this case, the transport layer MUST also be prepared to
   receive an incoming connection on the source IP address from which
   the request was sent and port number in the "sent-by" field.  It also
   MUST be prepared to receive incoming connections on any address and
   port that would be selected by a server based on the procedures
   described in Section 5 of [4]."
You see, server may attempt to open a new tcp connection to send the
***response***. There is no word about
the requests, but OpenSER attempts to open new connection on requests: for
example, Notify.
Please, tell me, where can I find in RFC's the information about "new tcp
connections for requests from the 
server side"? If there is no such info, it seems to be a bug.

Best Regards
Alexander Olekhnovich

----------------------------------------------------------------------

Comment By: Klaus Darilion (klaus_darilion)
Date: 2007-11-14 10:42

Message:
Logged In: YES 
user_id=1318360
Originator: NO

Hi!

IMO this should feature request should be extended. E.g. Openser should
not create new TCP connections if a certain flag is set. E.g. if after
lookup() a TCP contact is found, but no corresponding open TCP connection I
do not want openser to even try to establish one as at 99,99 percent it
wont work as the client is behind NAT.

More problematic would be the routing of in-dialog requests - here we have
to try.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2007-11-14 08:52

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi,

I move this report as a feature request - it is not a bug, but rather an
enhancement.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Kovalevich Victor (vkc1974)
Date: 2007-06-07 11:50

Message:
Logged In: YES 
user_id=490489
Originator: YES

Discussed situation is occurred while NOTIFY request is sent to a UA site
(coursed by PUBLISH request processing) but there is no valid (not
expired!) contact (connection) for UA site NOTIFY message is going to be
sent to.

A dialog instance is created while appropriate SUBSCRIBE request is
processed. So that all NOTIFY requests related to given subscribe are sent
within given dialog. There is a tree of calls how NOTIFY request is sent:

notify()
 req_within()
  send_pr_buffer()
   msg_send()
    tcp_send()

tcpconn_get() routine is called within tcp_send() to look for actual
connection instance - it returns NULL (existed connection to appropriate UA
site has expired and cannot be considered as actual one). So that flags
field of a connection instance (struct tcp_connection) is not accessible to
be analyzed. So that new connection is tried to be established via
tcpconn_connect() that blocks openser service and makes it unavailable to
process new request!

This scenario takes place in both cases UDP/TCP or TLS/TCP (secure
communication) transport protocols are used. In the first case this
described block an denied of service situation can be avoided as udp_send()
routine does not try to establish new communication to UA site a request is
going to be sent. In the second case (TLS/TCP transport)
given situation tcp_send() routine is used only.

Really I am surprised why openser tries to establish new TCP
communication. In my point of view there is very bad way to try do it every
time no valid TCP communication to send a request/answer is available (the
better way could be to try to establish new communication once or twice and
no to try it again and again).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-06-06 17:35

Message:
Logged In: NO 

regarding initial request, if standard nat flag is set, it makes no sense
try to establish tcp session.

regarding in-dialog request, a custom flag could be used.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-06-06 17:26

Message:
Logged In: NO 

Hi Victor!

Funny - at the same time of your report we dicussed this topic on the
openser programming course.

Yes - there should be an option to avoid TCP connection establishment to
clients behind NAT. Some ideas were to:
- no TCP connection establishment attempt if nat flag is set
- no TCP connection establishment attempt after lookup()
- no TCP connection establishment attempt if a certain flag is set

For in-dilalog it is not that easy to distinguish between destination to
which a connection establishment should be done (gateway, proxy) and to
others (user agents)

Klaus

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743023&aid=1732039&group_id=139143