I failed to link this to the original post. So I'll begin anew. Here was my post.
Hi Kamailio Community, When testing rtpengine_manage and websockets, I noticed that if the rtpengine table in the database is not used, a new websocket is created for every call for a given dialog. That is, when an INVITE is received, an offer is sent to rtpengine. When the 200 OK or 18[3|0] is received, an answer is sent. However, the WS identifier often changes and as a result the request is not sent over the same websocket. This is problematic particularly when using FQDNs in the Kamailio configuration. When a load balancer is used between Kamailio and rtpengine, the answer may arrive at a different rtpengine in the cluster. After tracing through the source, I could not find a configuration parameter or set of triggers that I could manipulate to fix this. It leads me to believe it is only possible to reuse the websocket when the rtpengine table is used. Does anybody have more experience than I in this area that may be able to point me in the right direction, making load balancers for rtpengine_manage calls possible?
Alex then responded with
Hi, Without wishing to dismiss the salience of your problem: do you actually need WS?
Henning then responded with
Hello, so, you are saying that the connection handling behaviour of Kamailio with rtpengine changes, if you are using database mode compared to not using the database? I’ve might missed some side-effects, but I think that using rtpengine_manage() should not affect the handling of Websocket connection (or in fact any other connection) operation that Kamailio is doing on the SIP level. The rtpengine_manage() should affect the SDP content of the SIP message body only. Can you reproduce this behaviour? Cheers, Henning
I would like to continue this. I'll detall more in my next post.
On Wed, Jan 8, 2025 at 11:47 AM Knserbrave knserbrave@gmail.com wrote:
test
I simplified my Kamailio configuration to have a statically defined socket to ws://<RFC 1918 addr>:12211
I then captured PCAP using tcpdump on my media proxy with rtpengine and found a new websocket is created for the offer, answer, and delete.
To answer the first question, we would like to use websocket to ensure the offer, answer, and delete all go to the same media proxy node for a given dialog. The idea was if we were to use a network load balancer, we could anchor the path to a single media proxy for the life of the websocket.
However, since a new websocket is created for every offer, answer, and delete message, it's no different than using UDP.
I'm not quite sure why websocket is even a viable transport for rtpengine if a new websocket is created for every request. I suspect I am missing configuration that would achieve the functionality I seek.
On Wed, Jan 8, 2025 at 11:50 AM Knserbrave knserbrave@gmail.com wrote:
I failed to link this to the original post. So I'll begin anew. Here was my post.
Hi Kamailio Community, When testing rtpengine_manage and websockets, I noticed that if the rtpengine table in the database is not used, a new websocket is created for every call for a given dialog. That is, when an INVITE is received, an offer is sent to rtpengine. When the 200 OK or 18[3|0] is received, an answer is sent. However, the WS identifier often changes and as a result the request is not sent over the same websocket. This is problematic particularly when using FQDNs in the Kamailio configuration. When a load balancer is used between Kamailio and rtpengine, the answer may arrive at a different rtpengine in the cluster. After tracing through the source, I could not find a configuration parameter or set of triggers that I could manipulate to fix this. It leads me to believe it is only possible to reuse the websocket when the rtpengine table is used. Does anybody have more experience than I in this area that may be able to point me in the right direction, making load balancers for rtpengine_manage calls possible?
Alex then responded with
Hi, Without wishing to dismiss the salience of your problem: do you actually need WS?
Henning then responded with
Hello, so, you are saying that the connection handling behaviour of Kamailio with rtpengine changes, if you are using database mode compared to not using the database? I’ve might missed some side-effects, but I think that using rtpengine_manage() should not affect the handling of Websocket connection (or in fact any other connection) operation that Kamailio is doing on the SIP level. The rtpengine_manage() should affect the SDP content of the SIP message body only. Can you reproduce this behaviour? Cheers, Henning
I would like to continue this. I'll detall more in my next post.
On Wed, Jan 8, 2025 at 11:47 AM Knserbrave knserbrave@gmail.com wrote:
test
I should add it does not matter if I used the rtpengine database table or use a socket config in the Kamailio configuration. A new websocket is created for every request.
On Wed, Jan 8, 2025 at 12:27 PM Knserbrave knserbrave@gmail.com wrote:
I simplified my Kamailio configuration to have a statically defined socket to ws://<RFC 1918 addr>:12211
I then captured PCAP using tcpdump on my media proxy with rtpengine and found a new websocket is created for the offer, answer, and delete.
To answer the first question, we would like to use websocket to ensure the offer, answer, and delete all go to the same media proxy node for a given dialog. The idea was if we were to use a network load balancer, we could anchor the path to a single media proxy for the life of the websocket.
However, since a new websocket is created for every offer, answer, and delete message, it's no different than using UDP.
I'm not quite sure why websocket is even a viable transport for rtpengine if a new websocket is created for every request. I suspect I am missing configuration that would achieve the functionality I seek.
On Wed, Jan 8, 2025 at 11:50 AM Knserbrave knserbrave@gmail.com wrote:
I failed to link this to the original post. So I'll begin anew. Here was my post.
Hi Kamailio Community, When testing rtpengine_manage and websockets, I noticed that if the rtpengine table in the database is not used, a new websocket is created for every call for a given dialog. That is, when an INVITE is received, an offer is sent to rtpengine. When the 200 OK or 18[3|0] is received, an answer is sent. However, the WS identifier often changes and as a result the request is not sent over the same websocket. This is problematic particularly when using FQDNs in the Kamailio configuration. When a load balancer is used between Kamailio and rtpengine, the answer may arrive at a different rtpengine in the cluster. After tracing through the source, I could not find a configuration parameter or set of triggers that I could manipulate to fix this. It leads me to believe it is only possible to reuse the websocket when the rtpengine table is used. Does anybody have more experience than I in this area that may be able to point me in the right direction, making load balancers for rtpengine_manage calls possible?
Alex then responded with
Hi, Without wishing to dismiss the salience of your problem: do you actually need WS?
Henning then responded with
Hello, so, you are saying that the connection handling behaviour of Kamailio with rtpengine changes, if you are using database mode compared to not using the database? I’ve might missed some side-effects, but I think that using rtpengine_manage() should not affect the handling of Websocket connection (or in fact any other connection) operation that Kamailio is doing on the SIP level. The rtpengine_manage() should affect the SDP content of the SIP message body only. Can you reproduce this behaviour? Cheers, Henning
I would like to continue this. I'll detall more in my next post.
On Wed, Jan 8, 2025 at 11:47 AM Knserbrave knserbrave@gmail.com wrote:
test
On 08/01/2025 13.27, Knserbrave via sr-users wrote:
I'm not quite sure why websocket is even a viable transport for rtpengine if a new websocket is created for every request. I suspect I am missing configuration that would achieve the functionality I seek.
I don't think so. The WS transport is a simple wrapper over the same request/response mechanism that is also used for the UDP transport. What you're asking for would require persistent connections across multiple requests, and tracking which connection belongs to which call, which isn't implemented. Furthermore it would require sharing connections between the multiple processes that Kamailio is using, which poses and entirely new challenge due to the multi-process nature of Kamailio.
Cheers
-
Knserbrave -
Richard Fuchs