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@gmail.com An: "sr-users" sr-users@lists.kamailio.org, "Sebastian Damm" sdamm@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users