[SR-Users] Push and tcpconn_main_timeout

[Kjeld Flarup]

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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180319/7e38462f/attachment.html>