Re: [SR-Users] Push and tcpconn_main_timeout
On Thu, Mar 22, 2018 at 09:26:02PM +0100, Kjeld Flarup wrote: > Thanks for Your suggestion. I'm however not sure that it will solve the > problem which is a TCP connection problem. > > I solved the issue by sending the call back to the kamailio which handles > the registrations, and just let the other kamailio's do the topoh module. That is exactly what Path does. My setup is a little different having 2 edge proxies/loadbalancers infront of 3 registrars, but the edge adds a Path header with source/transport (path_add_received), this gets stored in the location table. Now any backend knows which edge proxy to use, that proxy uses the already established TCP connection to the endpoint. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Push and tcpconn_main_timeout
Thanks for Your suggestion. I'm however not sure that it will solve the problem which is a TCP connection problem. I solved the issue by sending the call back to the kamailio which handles the registrations, and just let the other kamailio's do the topoh module. Med Liberalistiske Hilsner -- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk On 03/22/2018 10:24 AM, Daniel Tryba wrote: On Wed, Mar 21, 2018 at 07:44:50PM +0100, Kjeld Flarup wrote: My own fault Because I needed to be able to forward the call to multiple GSM numbers at the same voip provider, I split the call onto several instances of Kamalio to be able to create new call id's As a result, the registers were made on one instance, and the invites on another. That apparently worked fine most of the time, because Kamailio is a proxy. You maybe could fix this by using the Path module by storing the proxy/registrar that received the call. If the endpoint registers directly you might have to create your on path headers before save() (atleast that was my conclusion for 4.3). ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Push and tcpconn_main_timeout
On Wed, Mar 21, 2018 at 07:44:50PM +0100, Kjeld Flarup wrote: > My own fault > > Because I needed to be able to forward the call to multiple GSM numbers at > the same voip provider, I split the call onto several instances of Kamalio > to be able to create new call id's > > As a result, the registers were made on one instance, and the invites on > another. That apparently worked fine most of the time, because Kamailio is a > proxy. You maybe could fix this by using the Path module by storing the proxy/registrar that received the call. If the endpoint registers directly you might have to create your on path headers before save() (atleast that was my conclusion for 4.3). ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Push and tcpconn_main_timeout
My own fault Because I needed to be able to forward the call to multiple GSM numbers at the same voip provider, I split the call onto several instances of Kamalio to be able to create new call id's As a result, the registers were made on one instance, and the invites on another. That apparently worked fine most of the time, because Kamailio is a proxy. Med Liberalistiske Hilsner -- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk On 03/19/2018 10:09 PM, Kjeld Flarup wrote: I got a bit wiser on my problem. It seems that the sequence of events matters. I have a PBX which should send the call to the App. If the App does not respond within three seconds, the call should be forwarded to a GSM number. I have two scenarios, this one works: 1. PBX gets call 2. App registers 3. PBX sends invite 4. App rings This fails 1. PBX gets call 2. PBX sends a push 3. App registers 4. PBX generates tcpconn_main_timeout or handle_tcpconn_ev on connect to App I'm using a simple loop to wait for the registration (I got plenty of ressources!) The obvious difference is that in the failing scenario, the call is in progress when the register arrives. I do not use the technique with t_suspend. Would that make a difference? We are using TCP. We have tried with UDP, and then the Invite is send to the App. Med Liberalistiske Hilsner -- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk On 03/19/2018 05:57 PM, Daniel Tryba wrote: On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote: Interesting Just to be sure that I understand You correctly. When a Register is done, then an Invite, must create a new TCP connection. That is not what I tried to say. All I wanted to say was: uac ipA:portX -> syn -> server ipB:5060 uac ipA:portX <- syn-ack <- server ipB:5060 uac ipA:portX -> ack -> server ipB:5060 uac ipA:portX <-> server ipB:5060 Whether the uac is behind NAT or not, it is impossible to recreate the connection between ipA:portX and ipB:5060 if there is ever a network interruption. Atleast that used to be true before SO_REUSEPORT support in kernels so maybe the uac may be capable to reconnect with the same port, but it is definitly impossible for the server to do this since there is simply no listener to connect to. I agree, that a perfect implementetion would be to keep the TCP stream up while the client is connected, and use that connection for all communication between the two stacks. How about reregisters can they reuse the connection? Or should the connection be closed once the packet is consumed? This is all up to the endpoint, but having a DNS based loadbalancing setup (SRV records, round robin A records) may have an influence. Most clients I have seen sofar will simply reuse an existing TCP connection for both INVITEs and re-REGISTERs. Clients with decend NAPTR/SRV implementation will probably query DNS and iterate over the available servers (with hopefuly 1 per server). Kamailio will just reuse an existing connection as far as I have seen. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Push and tcpconn_main_timeout
I got a bit wiser on my problem. It seems that the sequence of events matters. I have a PBX which should send the call to the App. If the App does not respond within three seconds, the call should be forwarded to a GSM number. I have two scenarios, this one works: 1. PBX gets call 2. App registers 3. PBX sends invite 4. App rings This fails 1. PBX gets call 2. PBX sends a push 3. App registers 4. PBX generates tcpconn_main_timeout or handle_tcpconn_ev on connect to App I'm using a simple loop to wait for the registration (I got plenty of ressources!) The obvious difference is that in the failing scenario, the call is in progress when the register arrives. I do not use the technique with t_suspend. Would that make a difference? We are using TCP. We have tried with UDP, and then the Invite is send to the App. Med Liberalistiske Hilsner -- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk On 03/19/2018 05:57 PM, Daniel Tryba wrote: On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote: Interesting Just to be sure that I understand You correctly. When a Register is done, then an Invite, must create a new TCP connection. That is not what I tried to say. All I wanted to say was: uac ipA:portX -> syn -> server ipB:5060 uac ipA:portX <- syn-ack <- server ipB:5060 uac ipA:portX -> ack -> server ipB:5060 uac ipA:portX <-> server ipB:5060 Whether the uac is behind NAT or not, it is impossible to recreate the connection between ipA:portX and ipB:5060 if there is ever a network interruption. Atleast that used to be true before SO_REUSEPORT support in kernels so maybe the uac may be capable to reconnect with the same port, but it is definitly impossible for the server to do this since there is simply no listener to connect to. I agree, that a perfect implementetion would be to keep the TCP stream up while the client is connected, and use that connection for all communication between the two stacks. How about reregisters can they reuse the connection? Or should the connection be closed once the packet is consumed? This is all up to the endpoint, but having a DNS based loadbalancing setup (SRV records, round robin A records) may have an influence. Most clients I have seen sofar will simply reuse an existing TCP connection for both INVITEs and re-REGISTERs. Clients with decend NAPTR/SRV implementation will probably query DNS and iterate over the available servers (with hopefuly 1 per server). Kamailio will just reuse an existing connection as far as I have seen. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
