RE: [reSIProcate] Changes to resiprocate needed to supportoutbound-only connections

["Derek MacDonald" <derek@xxxxxxxx>]

I've been looking into this as repro will not handle tls on a lan unless ppl
have their connect port as a contact.  My take on it was to have an opaque
token we could set on the SipMessage(for outgoing requests, via should work
for responses) which would be used by the ConnectionManager if it was
present.  The ConnectionManager would have another map for these gruu
tokens; this would avoid changes to intermediate methods.

--Derek

CONFIDENTIALITY NOTICE

This email and any files transmitted with it contains proprietary
information and, unless expressly stated otherwise, all contents and
attachments are confidential. This email is intended for the addressee(s)
only and access by anyone else is unauthorized. If you are not an addressee,
any disclosure, distribution, printing or copying of the contents of this
email or its attachments, or any action taken in reliance on it, is
unauthorized and may be unlawful. If you are not an addressee, please inform
the sender immediately and then delete this email and any copies of it.
Thank you for your co-operation.

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Rohan Mahy
> Sent: Saturday, June 04, 2005 12:55 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Rohan Mahy
> Subject: [reSIProcate] Changes to resiprocate needed to supportoutbound-
> only connections
> 
> 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
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel