[OpenSIPS-Devel] [ opensips-Bugs-3178242 ] Reuse Transport socket

[SourceForge.net]

Bugs item #3178242, was opened at 2011-02-11 14:24
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3178242&group_id=232389

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: modules
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Reuse Transport socket

Initial Comment:
Hi,
This is not really a bug report, but a thought:
I'm reading the TM source code, and specifically the t_uac function. This function tries to find the right socket to send the request with the next hop URI.
In my case, I created a dialog using TCP, the connection is up, Request is sent, but the peer replies with a Contact header URI that looks like: <sip:user at ip>. So every next request will be sent to this URI. But Transport argument is not set. In your source code, parse_uri (called in uri2sock) will set proto of this uri to PROTO_NONE. But sip_resolvehost function (called in urisock via mk_proxy) will set default protocol to UDP when URI is not SIPS type. So every next request will be sent on UDP.

There are 2 ways to explain this bug:
 - the peer is wrong so it has to add transport argument to its Contact header;
 - You choose explicitly to use UDP by default, but RFC seems to recommend reuse of socket;

RFC 3261 (18 Transport):
   ....
   It is RECOMMENDED that connections be kept open for some
   implementation-defined duration after the last message was sent or
   received over that connection.  This duration SHOULD at least equal
   the longest amount of time the element would need in order to bring a
   transaction from instantiation to the terminated state.  This is to
   make it likely that transactions are completed over the same
   connection on which they are initiated (for example, request,
   response, and in the case of INVITE, ACK for non-2xx responses).
   ....


What is your point of view about this problem ?

Thanks for your answer,
Regards,

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-06-28 10:59

Message:
This is definitely a bug in the client - if it wants to keep TCP up, it
must add the transport param to the contact URI, As per RFC3261, default
protocol is UDP.
Here it is not about re-usage - re-usage is about keeping a connection up
(after being done with it) as it may be used later for some following
messages; In your case is about selecting the socket, not re-using.

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3178242&group_id=232389