[SR-Users] Push and tcpconn_main_timeout
kjeld.flarup at liberalismen.dk
Wed Mar 21 19:44:50 CET 2018
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
> 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:
>>> 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
>> 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 at lists.kamailio.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users