<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>My own fault</p>
<p>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</p>
<p>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.</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">-------------------- 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 - <a class="moz-txt-link-abbreviated" href="http://www.liberalismen.dk">www.liberalismen.dk</a>
</pre>
<div class="moz-cite-prefix">On 03/19/2018 10:09 PM, Kjeld Flarup
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:820537f9-e921-856f-b136-2aea6f95a1a9@liberalismen.dk">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>I got a bit wiser on my problem. <br>
</p>
<p>It seems that the sequence of events matters.</p>
<p>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.</p>
<p>I have two scenarios, this one works:<br>
</p>
<ol>
<li>PBX gets call<br>
</li>
<li>App registers</li>
<li>PBX sends invite</li>
<li>App rings</li>
</ol>
<p>This fails</p>
<ol>
<li>PBX gets call</li>
<li>PBX sends a push</li>
<li>App registers</li>
<li>PBX generates tcpconn_main_timeout or handle_tcpconn_ev on
connect to App</li>
</ol>
<p>I'm using a simple loop to wait for the registration (I got
plenty of ressources!)</p>
The obvious difference is that in the failing scenario, the call
is in progress when the register arrives.<br>
<p>I do not use the technique with t_suspend. Would that make a
difference?<br>
</p>
<p>We are using TCP. We have tried with UDP, and then the Invite
is send to the App.<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">-------------------- 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 - <a class="moz-txt-link-abbreviated" href="http://www.liberalismen.dk" moz-do-not-send="true">www.liberalismen.dk</a>
</pre>
<div class="moz-cite-prefix">On 03/19/2018 05:57 PM, Daniel Tryba
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20180319165720.xqsygr62vcmjy5qb@office.pocos.nl">
<pre wrap="">On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Interesting
Just to be sure that I understand You correctly.
When a Register is done, then an Invite, must create a new TCP connection.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>