[SR-Users] Push and tcpconn_main_timeout

[Kjeld Flarup]

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 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/20180321/44f874c7/attachment.html>