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

SourceForge.net noreply at sourceforge.net
Wed Nov 14 08:52:19 UTC 2007


Feature Requests item #1732039, was opened at 2007-06-06 16:31
Message generated for change (Comment added) made by bogdan_iancu
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: Bogdan (bogdan_iancu)
Date: 2007-11-14 10: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 14: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 20: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 20: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



More information about the Devel mailing list