19 Mar
2018
19 Mar
'18
9:09 p.m.
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users