<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Yuriy</p>
<p>Thanks for Your suggestions. I looked at them, and it seems to me
that they all are supposed to be on the receiving side.<br>
My side is the client side behind NAT, and only does INVITE, I
never receives INVITES.<br>
</p>
<p>The alias concept looks interesting but I doubt that I can
convince the provider to use is, as the documentation states it to
be dangerous. <br>
</p>
<p>When looking up the force_tcp_alias I noticed that
fix_natted_contact was recomended for NAT traversal. I do not know
if the provider uses, this function. Could that be the cause?<br>
<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">www.liberalismen.dk</a></pre>
<div class="moz-cite-prefix">On 1/12/21 8:59 AM, Yuriy Gorlichenko
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABSP_Vc8sqH1mC94D4-DYf6Xstiuj-gdNKd5xv3FMQGyMiSN8A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div dir="auto">It doesn't matter whet port used by provider
when it sent initial INVITE to you.</div>
<div dir="auto"><br>
</div>
Record-route and Route headers are Proxy headers. They are
announce addresses of the proxy for the listening. That means
when UA sends the request it has to use port mentioned in the
first of the Route headers or in the Request URI header.
<div dir="auto">That means that your kamailio has to create new
connection to this host port pair or reuse it if it already
exists to reach provider's server. So there is nothing bad if
you will create new connection for BYE to port 7071.</div>
<div dir="auto"><br>
</div>
<div dir="auto">However, If provider initiated INVITE to you and
sent it from the different port ( which is true because for
that transaction provider has to behave atleast as TCP client
) and connection still alive ( socket still exists ) - you can
try to use $du variable and put here existing address used for
the connection to provider.</div>
<div dir="auto">But remember it is a hack. </div>
<div dir="auto"><br>
</div>
<div dir="auto">This is also can be achieved via as mentioned
above global param</div>
<div dir="auto"><br>
</div>
<div dir="auto">tcp_accept_aliases =yes</div>
<div dir="auto"><br>
</div>
<div dir="auto">And functions wich has to be called on initial
invite:</div>
<div dir="auto">tcp_keepalive_enable</div>
<div dir="auto">force_tcp_alias</div>
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Tue, 12 Jan 2021,
07:15 Kjeld Flarup, <<a
href="mailto:kjeld.flarup@liberalismen.dk"
target="_blank" rel="noreferrer"
moz-do-not-send="true">kjeld.flarup@liberalismen.dk</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Hi Daniel</p>
<p>The Record route in the INVITE from 194.247.61.26
sets this pair<br>
</p>
<p>Record-Route:
<a rel="noreferrer noreferrer"
moz-do-not-send="true"><sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a><br>
Record-Route: <a rel="noreferrer noreferrer"
moz-do-not-send="true"><sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a></p>
<p>The Bye requests this route<br>
</p>
<p>Route:
<a rel="noreferrer noreferrer"
moz-do-not-send="true"><sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a><br>
Route: <a rel="noreferrer noreferrer"
moz-do-not-send="true"><sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1></a><br>
</p>
<p>But the real port on 194.255.22.44 is 36059</p>
<p>It is my invite to 194.247.61.26 that sets the
7071 port, which automatically comes from the
listen statement.<br>
I suspect that it might work if the invite was
using 36059, but how can I know this port, if the
NAT router decides to map it to another port.</p>
<p><br>
</p>
<p>What is the correct behaviour. Should my Kamailio
somehow set the correct port?</p>
<p>Should the providers Kamailio rewrite the route
information?</p>
<p>Or something else?<br>
</p>
<p><br>
</p>
<p><br>
</p>
<pre 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 href="http://www.liberalismen.dk" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.liberalismen.dk</a></pre>
<div>On 1/11/21 10:18 AM, Daniel-Constantin Mierla
wrote:<br>
</div>
<blockquote type="cite">
<p>The From/To/Call-ID are not used to match the
connection. The connection is matched based on
target IP and port. For BYE, these are taken
from Route header, if there is one for next hop,
otherwise it is the request URI. Check these two
to see if something is not as expected.
Otherwise, you have to discuss with the provider
and see the reason it returns back the 477
response.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 08.01.21 20:36, Kjeld Flarup wrote:<br>
</div>
<blockquote type="cite">
<p>Happy New Year everyone.</p>
<p><br>
</p>
<p>I haven't solved this problem yet. Although
is it not critical, it is a bit annoying.</p>
<p>I have tried to simplify things, and have a
reference setup that works. <br>
My linphone sends a TCP call and my Asterisk
answers, plays a speak and hangs up. <br>
</p>
<p><br>
</p>
<p>If I instead sends the call to my PBX, which
handles the authentication via UAC, it fails
with this error, which the customer site also
generated. </p>
<blockquote>
<p>Status-Line: SIP/2.0 477 Unfortunately
error on sending to next hop occurred
(477/SL)<br>
</p>
</blockquote>
<p>Unfortunately the error is not generated by
my Kamailio, but by a Kamailio at the
provider, when it gets a Bye forwarded via
their SBC. <br>
</p>
<p><br>
</p>
<p>I have attached a capture which the provider
send me. This is the setup</p>
<blockquote>
<p>linphone -> My Kamailio PBX (<a
href="http://194.255.22.44:36089"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">194.255.22.44:36089</a>)
-> provider Kamailio(194.247.61.26) ->
SBC(194.247.61.32) -> provider
Kamailio(194.247.61.26) -> my Asterisk (<a
href="http://194.255.22.44:45075"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">194.255.22.44:45075</a>)</p>
</blockquote>
<p>A note on the providers Kamailio. It listens
on both port 5060 and 5070, and both UDP/TCP.
<br>
It is also used as access point for both my
PBX and my Asterisk, thus the trace may be a
little confusing to read.<br>
</p>
<p>As far as I can see, the provider Kamailio
gets the correct To/From and CallID in the
bye. Thus it should be able to match the TCP
connection. <br>
The flow is also clean, there is no change of
ports etc. <br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>I have this reference setup which works</p>
<blockquote>
<p>linphone -> provider Kamailio -> SBC
-> provider Kamailio -> my Asterisk</p>
</blockquote>
The only differences towards the reference I can
see these. I do not have a capture from the
provider on this. <br>
<ul>
<li>There is an extra Via step.</li>
<li>Contact points to the Linphone IP, not the
Kamailio IP</li>
</ul>
<p>Any hint will be appreciated.</p>
<p><br>
</p>
<p><br>
</p>
<pre 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 href="http://www.liberalismen.dk" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.liberalismen.dk</a></pre>
<div>On 11/9/20 12:06 PM, Daniel-Constantin
Mierla wrote:<br>
</div>
<blockquote type="cite">
<p>Hello,</p>
<p>there is no association between a SIP call
and a TCP connection. SIP is not designed on
TCP streams, the forwarding is based on the
headers. It doesn't matter if there are
messages belonging to same call or not, they
can share same connection, or can open a new
one...<br>
</p>
<p>The BYE from caller gets to <a
href="http://194.247.61.32:5040"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">194.247.61.32:5040</a>,
which cannot deliver it further based on
Route header. The system at <a
href="http://194.247.61.26:5070"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">194.247.61.26:5070</a>
must be able to accept connections on
advertised port of the Route address. Again,
connection interruption can happen from
various cases, it cannot rely on ephemeral
ports, but on what the SIP system advertises
as "listen" address.</p>
<p>One can play with tcp port aliases, look at
Kamailio core cookbook, in case <a
href="http://194.247.61.32:5040"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">194.247.61.32:5040</a>
can do that. But that is not the proper way
for server to server communication, there
will be cases when the connection will be
cut for various reasons (can be also the IP
routes in the path that get congested).</p>
<p>Otherwise, you can follow the code of
tcp_send() function in the tcp_main.c from
core to see how tcp connection is matched,
there are various cases there, also a matter
of the config parameters.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 09.11.20 10:13, Kjeld Flarup wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello<br>
<br>
I have attached a pcap received from the
provider.<br>
<br>
It is quite informative as it shows bits
of how they forward the call.<br>
<br>
We send to 194.247.61.26 which is a
Kamailio proxy, that forwards the call to
a SBC 194.247.61.32<br>
<br>
My guess is that the 194.247.61.26
kamailio gets confused, and does not match
the BYE with the ongoing TCP session.<br>
Instead it sees it as a new session, and
forwards it according to the route
information.<br>
<br>
Can anybody help explaining what fields
Kamailio uses to match an ongoing TCP
session.<br>
<br>
Regards Kjeld<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Den fre.
6. nov. 2020 kl. 10.50 skrev
Daniel-Constantin Mierla <<a
href="mailto:miconda@gmail.com"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">miconda@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<div>Hello,</div>
<div><br>
</div>
<div>from SIP specs point of view, can
be any port -- ACK and BYE do not
have to follow same path as INVITE,
so they can even come from a
different IP.<br>
</div>
<div><br>
</div>
<div>Then, the call can be closed
after 30secs because also the ACK
has the same problems with the
header as the BYE. Your pcap didn't
include all the traffic, you have to
capture both directions on your
kamailio server to see what happens
on each side.</div>
<div><br>
</div>
<div>Cheers,<br>
Daniel<br>
</div>
<div> </div>
<div><br>
</div>
<div><br>
</div>
<div>On 06.11.20 10:35, Kjeld Flarup
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Daniel
<div><br>
</div>
<div>The Unknown Dialog comes
because the server hang up the
call 30 seconds earlier. We
never gets these BYE messages,
thus the door phone hangs
times out and hangs up.</div>
<div><br>
</div>
<div>My question is still, which
port is the BYE from the
server supposed to be sent to?</div>
<div><br>
</div>
<div>The original 37148</div>
<div>The new 37150</div>
<div>or the advertised 5071</div>
<div><br>
</div>
<div>Regards Kjeld</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr"
class="gmail_attr">Den fre. 6.
nov. 2020 kl. 10.18 skrev
Daniel-Constantin Mierla <<a
href="mailto:miconda@gmail.com" rel="noreferrer noreferrer"
target="_blank"
moz-do-not-send="true">miconda@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hello,</p>
<p>I think you hunt a mirage
problem here by looking at
the ports of tcp
connections, if you think
that being different ports
is the cause of BYE
failure. The ACK fpr 200ok
is independent of the
INVITE transaction and can
have a completely
different path than
INVITE, thus is completely
valid to use another
connection. Of course, if
follows the same path as
INVITE, if the connection
is still open, it should
be reused. But is a matter
of matching, it can be
that the INVITE uses
different destination
identifiers or the
connection gets cut from
different reasons. But the
point is that even if
there is a different
connection, it should
work.</p>
<p>So, I actually looked at
the pcap capture you sent
in one of your previous
emails and the BYE is sent
out, but gets back:</p>
<p>SIP/2.0 481 Unknown
Dialog.</p>
<p>Therefore it gets to the
end point, which doesn't
match it with any of its
active calls. Looking at
the headers, the
200ok/INVITE has:</p>
<p>From: "Front Door" <a
rel="noreferrer
noreferrer"
moz-do-not-send="true"><sip:32221660@194.255.22.44:5071></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
To: <a rel="noreferrer
noreferrer"
moz-do-not-send="true"><sip:004540294149@127.0.0.1:5071></a>;tag=12003375157297.<br>
Call-ID:
***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.</p>
<p>And the BYE:</p>
<p>From: "Front Door" <a
rel="noreferrer
noreferrer"
moz-do-not-send="true"><sip:u0@192.168.2.9></a>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.<br>
To: <a rel="noreferrer
noreferrer"
moz-do-not-send="true">sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297</a>.<br>
Call-ID:
***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.</p>
<p>While the dialog should
be matched on call-id,
from/to-tags, the From/To
URI should be the same to
be strict conformant with
RFC3261 (that mandates
unchanged From/To for
backward compatibility
with RFC2543). Likely you
do some From/To header
changes that are not done
correctly to
update/restore the values
for traffic within dialog.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 06.11.20 09:31,
Kjeld Flarup wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Thanks Juha
<div><br>
</div>
<div>That makes it
somehow easier to
understand my capture.
My Kamailio must then
have detected a broken
TCP connection, though
I cannot see why in
the capture, neither
in the log, but I only
run on debug level 2.</div>
<div>It receives a 200
OK on port 37148, and
then establishes 37150
to reply with an ACK. </div>
<div><br>
</div>
<div>However two seconds
before receiving the
200 OK, there are some
spurious
retransmissions and
out of order on 37148.
Perhaps this has
caused Kamailio to
deem the connection
bad, but it still
receives data on it.</div>
<div>Now I assume that
the providers server
(Which also is flying
Kamailio) should
detect the new port,
and continue using
that. I got a trace
from the provider,
where there is no
disturbance. Thus the
server thinks that the
connection is OK. </div>
<div><br>
</div>
<div>Now my next
question is, what
makes a Kamailio
detect this change?</div>
<div>Is it a problem
that I only rewrite To
and From in the
INVITE, thus the ACK
contains some other
values. <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>It is also a bit
strange that I get
this error exactly,
the same place in the
conversation every
time I make a call.
Somehow I suspect some
NAT timeout in the
router. (it is not
carrier grade NAT).</div>
<div>Can I do anything
to prevent a NAT
timeout from the
client side?</div>
<div><br>
</div>
<div><br>
</div>
<div>Another thing. I
assume that sending my
internal port in the
From field, or any
kind of advertising,
should be ignored by
the server.</div>
<div><br>
</div>
<div>Regards Kjeld</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr"
class="gmail_attr">Den
fre. 6. nov. 2020 kl.
07.45 skrev Juha
Heinanen <<a
href="mailto:jh@tutpro.com"
rel="noreferrer
noreferrer"
target="_blank"
moz-do-not-send="true">jh@tutpro.com</a>>:<br>
</div>
<blockquote
class="gmail_quote"
style="margin:0px 0px
0px
0.8ex;border-left:1px
solid
rgb(204,204,204);padding-left:1ex">Kjeld
Flarup writes:<br>
<br>
> How is TCP SIP
actually supposed to
handle a BYE, when the
client is <br>
> behind NAT.<br>
<br>
Client behind NAT is
supposed to keep its
TCP connection to SIP
Proxy<br>
alive and use it for
all requests of the
call. If the
connection breaks<br>
for some reason, the
client sets up a new
one for the remaining<br>
requests.<br>
<br>
-- Juha<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users
Mailing List<br>
<a
href="mailto:sr-users@lists.kamailio.org"
rel="noreferrer
noreferrer"
target="_blank"
moz-do-not-send="true">sr-users@lists.kamailio.org</a><br>
<a
href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users"
rel="noreferrer
noreferrer
noreferrer"
target="_blank"
moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<p>---------------------
Med Liberalistiske
Hilsner
----------------------</p>
<pre cols="72"> 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 href="http://www.liberalismen.dk" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.liberalismen.dk</a>
</pre>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<p>--------------------- Med
Liberalistiske Hilsner
----------------------</p>
<pre cols="72"> 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 href="http://www.liberalismen.dk" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.liberalismen.dk</a>
</pre>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<p><br>
</p>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<p>--------------------- Med
Liberalistiske Hilsner
----------------------</p>
<pre cols="72"> 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 href="http://www.liberalismen.dk" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.liberalismen.dk</a>
</pre>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
</blockquote>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
</blockquote>
</div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">sr-users@lists.kamailio.org</a><br>
<a
href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
</body>
</html>