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