[reSIProcate] Changes to resiprocate needed to support outbound-only connections

[Rohan Mahy]

Hi,

I went through the stack today looking at what will be needed to add 
support for outbound-only connections to the stack.  This functionality 
will be needed by repro and other TUs that want to occasionally forward 
traffic only over a connection/session already established to it.  This 
is important for firewall traversal for TCP and TLS connections, but 
also for TLS and DTLS sessions (even if there are no NAT or firewall 
issues) if the TLS client doesn't have a suitable certificate.

At a high level, we need a new method in the SipMessage class to send 
only over an existing connection or session. This would be similar to 
the existing sendTo methods, but wouldn't try to open a new 
connection/session if one doesn't exist.  The prototypes for sendTo are 
below:

void sendTo(const SipMessage& msg, const Uri& uri, TransactionUser* 
tu=0);
void sendTo(const SipMessage& msg, const Tuple& tuple, TransactionUser* 
tu=0);

we need something like this (but possibly less verbose):

SipMessage.hxx
void sendOverExistingConnection(const SipMessage& msg, const Uri& uri, 
TransactionUser* tu=0);
void sendOverExistingConnection(const SipMessage& msg, const Tuple& 
tuple, TransactionUser* tu=0);

SipMessage::sendOverExistingConnection()
In order to implement this, sendOverExistingConnection needs to force 
the target like sendTo and also set a new flag to only use existing 
connections.

TransactionController::send() can remain as is.

TransactionState::sendToWire() can probably remain as is.

TransactionSelector::transmit() will probably need some work

TcpBaseTransport::processAllWriteRequests() needs to fail/return early 
if the connection we want doesn't exist

Connection.cxx probably also needs something a bit more granular than 
isGood(), the TcpBaseTransport can use when it finds a connection to 
verify it isn't in FIN_WAIT or some other transitional state

DtlsTransport.cxx will also need some some of failure if the DTLS 
session doesn't exist.

Anyone want to take a crack at implementing this?

thanks,
-rohan