[SR-Users] Open separate TCP streams to the same destination

[Sebastian Damm]

Hi Daniel,

thanks for the clarification. I read RfC5923 again, and I guess we will use that for arguing with the peer. Implementing an "accounting per TCP session" method seems to be just dead wrong.

Regards,
Sebastian

----- Ursprüngliche Mail -----
Von: "Daniel-Constantin Mierla" <miconda at gmail.com>
An: "sr-users" <sr-users at lists.kamailio.org>, "Sebastian Damm" <sdamm at pascom.net>
Gesendet: Freitag, 12. März 2021 09:27:03
Betreff: Re: [SR-Users] Open separate TCP streams to the same destination

Hello,

that is not possible at this moment, SIP does not associate the sessions
or the users with the transport layer connections, that's more the xmpp
c2s design. SIP relies on headers for matching.

Furthermore the connection reuse between two nodes comes from SIP specs.
Think also about record-routing which is given with server listen
ip:port, because it is not mandatory to have persistent connections, so
a node can close the connection and reconnect later when needs to the
address in record route.

Anyhow, being open source, you can extend kamailio to work as you need
(with configuration options to enable/disable). I haven't thought much,
but it should require some C code changes in the core to open new client
connections without binding for local socket, then keep the relation
between this client connections and the users/sessions. Here is probably
not easy how to do it, because SIP has a lot of flexibility in terms of
many devices per user, and many contacts/connections per device (e.g.,
see outbound specs, or devices with support for many transports at the
same time).

On the other hand, I haven't seem any such constraints from SIP systems
that work with proxy (support record-route, which is requirement in
RFC3261) or even with SBCs.

Cheers,
Daniel

On 11.03.21 17:00, Sebastian Damm wrote:
> Hi,
>
> I have a peer that requests separate TCP connections for each registration to their server. Those registrations run through the same Kamailio instance on my side. 
>
> Now what I tried is to use tcpops and the tcp_set_otcpid function, supplying a previously nonexistant TCP connection ID before relaying the register request. The command itself returns true, however, it does not do anything. The content of $conid of the reply is something totally different. So I guess, this function only works for already existing connections.
>
> Is there another way to explicitly tell Kamailio to open up another connection to a peer even though a connection to that peer is already open?
>
> Thanks in advance.
>
> Regards,
> Sebastian
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla