[reSIProcate] New TCP connection

[Scott Godin]

The stack does not support anything other than using an ephemeral port for
outbound TCP based connections.  For inbound TCP connections they are
performed on the configured transport port (non-ephemeral).  RFC3261 does
not mandate that non-ephemeral ports be used.  This is from section 18 of
RFC3261:

The transport layer is responsible for managing persistent
   connections for transport protocols like TCP and SCTP, or TLS over
   those, including ones opened to the transport layer.  This includes
   connections opened by the client or server transports, so that
   connections are shared between client and server transport functions.
   These connections are indexed by the tuple formed from the address,
   port, and transport protocol at the far end of the connection.  When
   a connection is opened by the transport layer, this index is set to
   the destination IP, port and transport.  When the connection is
   accepted by the transport layer, this index is set to the source IP
   address, port number, and transport.  Note that, because the source
   port is often ephemeral, but it cannot be known whether it is
   ephemeral or selected through procedures in [4], connections accepted
   by the transport layer will frequently not be reused.  The result is
   that two proxies in a "peering" relationship using a connection-
   oriented transport frequently will have two connections in use, one
   for transactions initiated in each direction.


Scott


On Wed, Jun 8, 2016 at 10:03 AM, Mohan Muniswamy <mohantek at gmail.com> wrote:

> Hello,
>
>
>
> I have problem wherein we can’t specify the source port while making an
> outgoing TCP connection. The port is chosen dynamically as allotted by the
> Linux system.
>
> But there are several cases where we need to specify the source port,
> which is required by the application to know beforehand.
>
> One such example is the IPSec where we need to create the IPSec
> associations using the source, destination IP and port.
>
>
>
> Right now it’s not possible to know this information at all using
> resiprocate. There is a call-back received when the “AftersocketFn”
> pointer. But it’s not the right way to do and also its not suitable in
> certain instances.
>
> With UDP protocol the stack uses the port specified as source by many
> mechanisms.
>
>
>
> Could you please look into this. This is using resip 1.9
>
>
>
> Many Thanks,
>
> Muni
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20160610/c1eade43/attachment.htm>