<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>then the overtaking is in between reading from the socket and
getting to parsing the call-id value -- the cpu is lost by first
reader after recvfrom() and the second process get enough cpu time
to go ahead further. I haven't encountered this case, but as I
said previously, it is very unlikely, but still possible. I added
the route_locks_size because in the past I had cases when
processing of some messages took longer executing config (e.g.,
due to authentication, accounting, ..) and I needed to be sure
they are processed in the order they enter config execution.<br>
</p>
<p>Then the option is to see if a single process with stateless
sending out (using forward()) gives the capacity, if you don't do
any other complex processing. Or if you do more complex
processing, use a dispatcher process with forwarding to local host
or in a similar manner try to use mqueue+rtimer for dispatching
using shared memory queues.</p>
<p>Of course, it is open source and there is also the C coding way,
to add a synchronizing mechanism to protect against parallel
execution of the code from recvfrom() till call-id lock is
acquired.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 09.04.20 17:37, Luis Rojas G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:975db507-ac1a-64e5-3826-b2db02d063cf@sixbell.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Well, it did not work at all. Exactly
same behavior, with random out of order messages.<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
On 4/9/20 11:28 AM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4dfec4cf-70e9-7a60-276a-96368ff8de7a@gmail.com">
<table
id="msexchangeipsafetytips;8eb82088-a4b2-43f9-d113-08d7dc9a99a4;R:en-US"
style="cellpadding:0;border:0;cellspacing:0;display:table;width:100%;table-layout:fixed;border-collapse:seperate;float:none;"
width="100%" cellspacing="0" cellpadding="0" border="0"
align="left">
<tbody>
<tr>
<td cellpadding="7px 2px 7px 2px" style="padding:7px 2px
7px 2px;background-color:#A6A6A6;valign:middle"
width="1px" valign="middle" bgcolor="#A6A6A6"> <br>
</td>
<td cellpadding="7px 5px 7px 15px" color="#212121"
style="width:100%;background-color:#EAEAEA;padding:7px
5px 7px 15px;font-family:wf_segoe-ui_normal,Segoe
UI,Segoe WP,Tahoma,Arial,
sans-serif;font-size:12px;font-weight:normal;color:#212121;text-align:left;word-wrap:break-word;"
width="100%" valign="middle" bgcolor="#EAEAEA">
<div><a class="moz-txt-link-abbreviated"
href="mailto:MICONDA@GMAIL.COM"
moz-do-not-send="true">MICONDA@GMAIL.COM</a> appears
similar to someone who previously sent you email, but
may not be that person. <a
href="http://aka.ms/LearnAboutSenderIdentification"
moz-do-not-send="true">Learn why this could be a
risk</a></div>
</td>
<td cellpadding="7px 5px 7px 5px" color="#212121"
style="width:75px;background-color:#EAEAEA;padding:7px
5px 7px 5px;font-family:wf_segoe-ui_normal,Segoe
UI,Segoe WP,Tahoma,Arial,
sans-serif;font-size:12px;font-weight:normal;color:#212121;text-align:left;word-wrap:break-word;align:left"
width="75px" valign="middle" bgcolor="#EAEAEA"
align="left"> <a
href="http://aka.ms/SafetyTipsFeedback"
moz-do-not-send="true">Feedback</a></td>
</tr>
</tbody>
</table>
<div>
<p>Hello,</p>
<p>the sip messages belonging to the same dialog have the same
value for Call-Id header. The locking is done based on
hashing the Call-Id, so it doesn't need at all the dialog
module for its purpose.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 09.04.20 14:19, Luis Rojas G.
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:904563be-7e54-f0a0-8f53-e9bd4d84ad41@sixbell.com">
<div class="moz-cite-prefix">Hello, Daniel,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I am not so sure. I first tried
adding that parameter, but it did not work at all. Same
behavior. Then I read the documentation more carefully :</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><a
class="moz-txt-link-freetext"
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894461050&sdata=b0xkSt%2FrLOGMd%2F0PTZCSzarfWW8jc5%2FABbIrNTaappc%3D&reserved=0"
originalsrc="https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size"
shash="fNkxvLTp/wem1JPcSGXJ0b+dVQpcPA8c5H62Geh2DIpIgSKOUtN691BeOSrA8242qNWiLP0YCAGPxbBSxHFHrFGVkYWZM2JuvhNl2ZfmdzRlnS+/Xf0qr8A0nb9LWhK5uFCeRmwDE3XrKMyBUSBZ9F0Qu/z8Sn3GlLgYe6HpdMQ="
moz-do-not-send="true">https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size</a><br>
</div>
<div class="moz-cite-prefix">
<h3 class="sectionedit123" id="route_locks_size">route_locks_size</h3>
<p>Set the number of mutex locks to be used for
synchronizing the execution of messages sharing the same
Call-Id. In other words, enables Kamailio to execute the
config script sequentially for the requests and replies
received <b>within the same dialog</b> – a new message
received <b>within the same dialog</b> waits until the
previous one is routed out. <br>
<br>
Locks to execute sequentially messages belonging to same
dialog. How will Kamailio be aware that messages belong
to same dialog, without the dialog module?. With just
stateless proxy it has no idea about dialogs, it just
forwards messages. I guess that's why just adding that
parameter did not work.<br>
<br>
Am I wrong?<br>
<br>
Luis<br>
<br>
</p>
<br>
<br>
On 4/9/20 3:47 AM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:394e1256-2621-6d2a-2a81-59c6ce6023aa@gmail.com">
<p>Hello,<br>
</p>
<div class="moz-cite-prefix">On 08.04.20 23:03, Luis Rojas
G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9819e88f-a02c-c717-f582-cda45a893b13@sixbell.com">
<div class="moz-cite-prefix">Hello, Daniel,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I looked into that
parameter, but I need to use with the dialog module,
and I'm pretty afraid to use that.</div>
</blockquote>
<p>who said or where is written than you need to load the
dialog module? You definitely don't.</p>
<p>Cheers,<br>
Daniel</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:9819e88f-a02c-c717-f582-cda45a893b13@sixbell.com">
<div class="moz-cite-prefix">I was looking more into the
stateless proxy, because I need to process a lot of
traffic.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">My target is 4200CAPS. with
duration between 90s and 210. Let's say, 150 seconds.
That would mean 630.000 simultaneous dialogs. I don't
think the solution can go that way.<br>
<br>
it would really help me to be able to use completely
stateless proxy plus Async in reply_route(), to
introduce an artificial delay before forwarding 200 OK
to Invite.. As someone mentioned, it would help me on
request_route(), for race conditions between ACK and
Re-Invite.<br>
<br>
Any idea why Async is not allowed in reply_route()?<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/8/20 1:07 PM,
Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6f161b89-4de7-57fc-0955-1b1e70d43991@gmail.com">
<p>Hello,</p>
<p>you have to keep in mind that Kamailio is a SIP
packet router, not a telephony engine. If 180 and
200 replies are part of a call is not something that
Kamailio recognize at its core. Its main goal is to
route out as fast as possible what is received, by
executing the configuration file script. Now, a
matter of your configuration file, processing of
some SIP messages can take longer than processing
other. And the processing is done in parallel, a
matter of children parameter (and tcp_children,
sctp_children).<br>
</p>
<p>With that in mind, a way to try to cope better with
the issue you face is to set route_locks_size
parameter, see:</p>
<p> * <a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894461050&sdata=b0xkSt%2FrLOGMd%2F0PTZCSzarfWW8jc5%2FABbIrNTaappc%3D&reserved=0"
originalsrc="https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size"
shash="fNkxvLTp/wem1JPcSGXJ0b+dVQpcPA8c5H62Geh2DIpIgSKOUtN691BeOSrA8242qNWiLP0YCAGPxbBSxHFHrFGVkYWZM2JuvhNl2ZfmdzRlnS+/Xf0qr8A0nb9LWhK5uFCeRmwDE3XrKMyBUSBZ9F0Qu/z8Sn3GlLgYe6HpdMQ="
moz-do-not-send="true">
https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size</a></p>
<p>Probably is what you look for.</p>
<p>But if you want more tight constraints, like when
receiving a 180 after a 200ok and not route it out,
you have to make the logic in configuration file by
combining modules such as dialog or htable (as
already suggested).</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 08.04.20 16:04, Luis
Rojas G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e11ff53d-108c-4242-6348-b585de118fda@sixbell.com">
<div class="moz-cite-prefix">Hi, Henning,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">No need to be ironic.
As I mentioned on my first post, I tried stateful
proxy and I observed the same behavior. <br>
<br>
<i>"I tried using stateful proxy and I obtained
the same result."</i><br>
<br>
The asynchronous sleep seems promising. I will
look into it.<br>
<br>
Thanks,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
On 4/8/20 9:30 AM, Henning Westerholt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:VI1PR05MB4590AD965F26015D01EF9C09C5C00@VI1PR05MB4590.eurprd05.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15
(filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Vorformatiert Zchn";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLVorformatiertZchn
{mso-style-name:"HTML Vorformatiert Zchn";
mso-style-priority:99;
mso-style-link:"HTML Vorformatiert";
font-family:Consolas;}
span.E-MailFormatvorlage22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">Hi Luis,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">I see. Well, you want to use
Kamailio as a stateless proxy, on the other
hand it should do things that are inherently
stateful. </span><span
style="font-family:"Segoe UI
Emoji",sans-serif;mso-fareast-language:EN-US"
lang="EN-GB">😉</span><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">As mentioned, have a look to
the dialog module to track the state of
dialogs that you process. This will not work
in a stateless mode, though. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">You can also use the htable
module to just store some data about the
processed messages in a shared memory table
and use this to enforce your ordering. There
is also the option to do an asynchronous
sleep (with the async) module on the message
that you want to delay but still processing
other messages during it.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Henning<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">-- <o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Henning Westerholt – </span><span
style="mso-fareast-language:EN-US"><a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894471045&sdata=%2FPz8nYYTRYQUs8P7ssC1VcMCv6DWD6V9fe6IoDF4Bmo%3D&reserved=0"
originalsrc="https://skalatan.de/blog/"
shash="xgEHSKtWXqAVw3Gd1SJuYWDTozWmG5mnnODECRW67H0YQrKr7Q5qh5zyOX/s6IbKYp2/psafiK6ivNN0jtcCIEGlygXmZvgtnXy9abqEWZLmBHy9ZPIIuJqt8GlwNZJDm3xemAgj6U7lp+JfxaUIfnXTBQ96tDxFWb8zQA2J1cE="
moz-do-not-send="true"><span
style="color:#0563C1" lang="EN-GB">https://skalatan.de/blog/</span></a></span><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Kamailio services – </span><span
style="mso-fareast-language:EN-US"><a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894481042&sdata=v6WrHhIxQNEPijRXbqZTB%2Fh%2BFdtrDFsPVn9qDGFUsB4%3D&reserved=0"
originalsrc="https://gilawa.com/"
shash="I518gFt+wZdNI9y8QE35e7Osnxcsl5KYyCmAKIjq/lOd2WtMufWkU/kq82BJvAzdLPlYmVQVh01v+Jz7DK1VrQw1epSUqxkA9H8aGmYqgYQLltQ1pjCUS0KauuQ2sJiHCeVzuPM4RuTf+zpuTNWT/IcwT5124rg1zVGDOzLTdBc="
moz-do-not-send="true"><span
style="color:#0563C1" lang="EN-GB">https://gilawa.com</span></a></span><span
style="mso-fareast-language:EN-US"> <span
lang="EN-GB"><o:p></o:p></span></span></p>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid
#E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"
style="margin-left:35.4pt"><b>From:</b>
Luis Rojas G. <a
class="moz-txt-link-rfc2396E"
href="mailto:luis.rojas@sixbell.com"
moz-do-not-send="true">
<luis.rojas@sixbell.com></a> <br>
<b>Sent:</b> Wednesday, April 8, 2020 3:00
PM<br>
<b>To:</b> Henning Westerholt <a
class="moz-txt-link-rfc2396E"
href="mailto:hw@skalatan.de"
moz-do-not-send="true">
<hw@skalatan.de></a>; Kamailio
(SER) - Users Mailing List <a
class="moz-txt-link-rfc2396E"
href="mailto:sr-users@lists.kamailio.org"
moz-do-not-send="true">
<sr-users@lists.kamailio.org></a><br>
<b>Subject:</b> Re: [SR-Users] Kamailio
propagates 180 and 200 OK OUT OF ORDER<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt">Hello, Henning,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt">I am worried
about this scenario, because it's a symptom
of what may happen in other cases. For
instance, I've seen that this operator
usually sends re-invites immediate after
sending ACK. This may create race
conditions like 3.1.5 of RFC5407<br>
<br>
<a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894481042&sdata=us7z8AaVoVsqprOMW97D6PqF5Bl6C3oBu%2Fp7pCXt7%2Bo%3D&reserved=0"
originalsrc="https://tools.ietf.org/html/rfc5407#page-22"
shash="jFi5WltXKoTF4BRa+YTUMe7odPqCSXrygCL2gZ4hhpfdGrNHmHTsk0zOyVn9DOmAauAG1Datq/p+1EKI1/WZefx9XHiimhstLcgWSOTq5Q/iKOMZy/j9j19rVb2iJCsdBSquVaunVVFv0Q/BhvTsw5Q6yPrzepMNlIL42UKRtGI="
moz-do-not-send="true">https://tools.ietf.org/html/rfc5407#page-22</a><br>
<br>
I'd understand that one happens because of
packet loss, as it's in UDP's nature, but in
this case it would be artificially created
by Kamailio. if there was no problem at
network level (packet loss, packets
following different path on the network and
arriving out of order), why Kamailio creates
it? <br>
<br>
I'd expect that the shared memory is used
precisely for this. If an instance of
kamailio receives a 200 OK, it could check
on the shm and say "hey, another instance is
processing a 180 for this call. Let's wait
for it to finish" (*). I know there could
still be a problem, the instance processing
the 180 undergoes a context switch just
after it receives the message, but before
writing to shm, but it would greatly reduce
the chance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:35.4pt">In
our applications we use a SIP stack that
always sends messages to the application in
the same order it receives them, even though
is multi-threaded and messages from the
network are received by different threads.
So, they really syncronize between them. Why
Kamailio instances don't?<br>
<br>
I am evaluating kamailio to use it as a
dispatcher to balance load against our
several Application Servers, to present to
the operator just a couple of entrance
points to our platform (they don't want to
establish connections to each one of our
servers). This operator is very difficult to
deal with. I am sure they will complain
something like "why are you sending messages
out of order? Fix that". The operator will
be able to see traces and check that
messages entered the Kamailio nodes in order
and left out of order. They will not accept
it.<br>
<br>
(*) Not really "wait", as it would introduce
a delay in processing all messages. it
should be like putting it on a queue,
continue processing other messages, and go
back to the queue later.<br>
<br>
Well, thanks for your answer.<br>
<br>
Luis<br>
<br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt"><br>
On 4/8/20 3:01 AM, Henning Westerholt wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US">Hello
Luis,</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">as the 1xx responses are
usually send unreliable (unless you use
PRACK), you should not make any assumption
on the order or even the arrival of this
messages. It can also happens on a network
level, if send by UDP.</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Can you elaborate why you
think this re-ordering is a problem for
you?</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">One idea to enforce some
ordering would be to use the dialog module
in combination with reply routes and the
textops(x) module.</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">About the shared memory
question – Kamailio implement its own
memory manager (private memory and shared
memory pool).</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Cheers,</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Henning</span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">-- </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Henning Westerholt – </span><span
style="mso-fareast-language:EN-US"><a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894491034&sdata=xGN%2BtLb0lh84qCzNUUZAdqPqW14q7eE03W881jYxXDQ%3D&reserved=0"
originalsrc="https://skalatan.de/blog/"
shash="PnP6Srtb9VrWHvyj9bSg0W+pHmjGzhxqrXz1eCsLsNynm8ZW3NtdWy4LSpped3BGI9WwohONFvJYHjzcP+OjQ9bm5hld5/6+S93L4HNrce4NdHhZAIM8qCIZ8aQHY7uL1Nz5EAriBqpNa7jmSSzNzSRN0n3Jjl6GotzdGRcNGwY="
moz-do-not-send="true"><span
style="color:#0563C1" lang="EN-GB">https://skalatan.de/blog/</span></a></span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">Kamailio services – </span><span
style="mso-fareast-language:EN-US"><a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894501031&sdata=xSoqNmnm%2Bfwv9AP30GyY6BIFLLeNGXPhuJNuStpjBzU%3D&reserved=0"
originalsrc="https://gilawa.com/"
shash="FwBPW3Luw/pSGcqG28hUHQITdWWWBmnSNigT+WTEx9hpqxcFqqc/70goPcN9L8rWGx+O8/eElYcA/3fX+ZR2pEI1uXLAPmqjTS+ry8EXPjpPj7yt7Q95i5+0vkuxXmHQNkdQ78lc5GIN3fI1REoQa+8ibXh3ODfMJ4UHtwYbbd8="
moz-do-not-send="true"><span
style="color:#0563C1" lang="EN-GB">https://gilawa.com</span></a>
</span><o:p></o:p></p>
</div>
<p class="MsoNormal"
style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid
#E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"
style="margin-left:70.8pt"><b>From:</b>
sr-users <a
href="mailto:sr-users-bounces@lists.kamailio.org"
moz-do-not-send="true">
<sr-users-bounces@lists.kamailio.org></a> <b>On Behalf Of </b>Luis
Rojas G.<br>
<b>Sent:</b> Tuesday, April 7, 2020
10:43 PM<br>
<b>To:</b> <a
href="mailto:sr-users@lists.kamailio.org"
moz-do-not-send="true">sr-users@lists.kamailio.org</a><br>
<b>Subject:</b> [SR-Users] Kamailio
propagates 180 and 200 OK OUT OF ORDER<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="margin-left:70.8pt"> <o:p></o:p></p>
<div>
<p style="margin-left:70.8pt">Good day,<o:p></o:p></p>
<p style="margin-left:70.8pt">I am testing
the dispatcher module, using Kamailio as
stateless proxy. I have a pool of UAC
(scripts in SIPP) and a pool of UAS (also
scripts in SIPP) for the destinations.
Kamailio version is
kamailio-5.3.3-4.1.x86_64.<o:p></o:p></p>
<p style="margin-left:70.8pt">Problem I have
is, if UAS responds 180 and 200 OK to
Invite immediately, sometimes they are
propagated out of order. 200 OK before
180, like this :<o:p></o:p></p>
<p
style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:70.8pt"><img
style="width:6.2187in;height:2.177in"
id="_x0000_i1025"
src="cid:part16.0881DDBC.428FADD0@gmail.com"
class="" width="597" height="209"
border="0"><o:p></o:p></p>
<p style="margin-left:70.8pt">UAS is
172.30.4.195:5061. UAC is
172.30.4.195:5080. Kamailio is
192.168.253.4:5070<o:p></o:p></p>
<p style="margin-left:70.8pt">Difference
between 180 and 200 is just about 50
microseconds. <o:p></o:p></p>
<p style="margin-left:70.8pt">My guess is
that both messages are received by
different instances of Kamailio, and then
because of context switches, even though
the 180 is received before, that process
ends after the processing of 200. However,
I had the idea that in order to avoid
these problems the kamailio processes
synchronized with each other using a
shared memory. I tried using stateful
proxy and I obtained the same result.<o:p></o:p></p>
<p style="margin-left:70.8pt">By the way,
anyone has any idea about how Kamailio's
share memory is implemented? It clearly
does not use the typical system calls
shmget(), shmat(), because they are not
shown by ipcs command.<o:p></o:p></p>
<p style="margin-left:70.8pt">Before posting
here I googled, but I couldn't find
anything related to this. I can't believe
I am the only one who ever had this
problem, so I guess I am doing something
wrong...<o:p></o:p></p>
<p style="margin-left:70.8pt">Please, any
help. I'm really stuck on this.<o:p></o:p></p>
<p style="margin-left:70.8pt">Thanks.<o:p></o:p></p>
<pre style="margin-left:70.8pt">-- <o:p></o:p></pre>
</div>
</blockquote>
<p style="margin-left:35.4pt"><o:p> </o:p></p>
<pre style="margin-left:35.4pt">-- <o:p></o:p></pre>
<pre style="margin-left:35.4pt">Luis Rojas<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Software Architect<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Sixbell<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Los Leones 1200<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Providencia<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Santiago, Chile<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Phone: (+56-2) 22001288<o:p></o:p></pre>
<pre style="margin-left:35.4pt"><a href="mailto:luis.rojas@sixbell.com" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a><o:p></o:p></pre>
<pre style="margin-left:35.4pt"><a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894501031&sdata=4V5xZCU4szWuyvrARjPBaaToAmm8eowL7GhYPthkCjQ%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="i1yq1z9hZjZXtnGnNdGIbAyN0DuMBzDG9PsjnR3YLCm3sqyLXyvrJKw2JtRp8GnRKc4ZAO99cZ7FOEJ3Yj58ZfpHJRVZKDuEHaRtOUj5cvygsZFleLDOPm4qXX9PBnyjQqXGd2Z27B8XD1pUgNBLKybK7lrDS0HaKLbfyOHnFTY=" moz-do-not-send="true">http://www.sixbell.com</a><o:p></o:p></pre>
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a class="moz-txt-link-freetext" href="mailto:luis.rojas@sixbell.com" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894511029&sdata=Y8NN4%2FzjqGy3zd5FL6xYDa2rGDrgWArhGoej7GubNUs%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="CIaCcFRz4dy6InVHRaP2lKCn5lT8xZ9gnTzluKmHYof9fZqMkVDXxsEQmox6b/e9lxFOVgfMJDWs8uG1Ye3jfcQpf885KKq5z68LJSaTtYlJAmLTTAMvWdYCr2comV4Ui7K7Mzt+VFaLJEb9ERA/dhHuTT3/4ZmjwLzg3RKMg7I=" moz-do-not-send="true">http://www.sixbell.com</a></pre>
<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" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894521025&sdata=Usmp0ko5S4N6r41z%2B%2Fwt7EzpwmG%2FPivs1qg1pU9rJHE%3D&reserved=0" originalsrc="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" shash="VGTn7tzBEvLk0hvvKJPFj+wCniFl2LB4623UcL/oWqTn4jYtG8vNa6eDErZdENvI3kNhCTHktMnWZwCHWetnYRsWMihn5R/P3eQFPV8QyIe29OtY11EF3WyLOA1riJ2eLzlvBshSE/y8xJVAdNjD4AWUDFXfDK3/Vpx0jHba2FA=" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894521025&sdata=GqbSO6v2A6iM6wJhfx7mW1G1le8tHXsReYb9T%2FrCyxk%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="PgOmr0GuwIAVppkvKsnsLlTbhOZp8gduIIJ3lJqwL2ZQTtu61W34lpgoZwR7ax9uXiS8zz+knREtG8lo0zeb49LYMtpz4XImIyGcvAXSklTJ1iS1SCSPaOtsOY612M5Et3VjUeylnZm2u38S8/DWhxjtNnPUwNjS6dlO9Sak+HM=" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894531024&sdata=A1JYJb5Jw7%2FpP6Op2IU%2FirQSYXwvWaKpKmmF7Q2M4yU%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="rrAIHqIsmiBrQN94oMBY4EHTcjO5Pvzs7gdawYHrNytZHEdo88JwUY9h8QCcnEcV7+OiKaUdGIihU5n51L5cXwj9OITIDTAEk5K6QyYy+v9x/QXMuvEmitpkXrz1+eO1s0MSHuPq/+dgn54UblEB+UHcmcC62yyoioM5L4BVNK4=" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894531024&sdata=wqt09rkaH%2B2eSBJ7g1cf6IATqNQqarrqb9cib9dFjng%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="sw7r7zHRoENZznZR04+KSlBar6nWbz2MyVx3cg0nqq1shR3RXiMtkf0Wr0SXI/cJdEOTonvuMJ3tNf5fm1gE801Gn+VyjEx0ZXdfK0StBzGz0hwdP1QOfLXWuTLLn+cRpzNIbxwsQOAHyynZa99Nl19MARLgLrvkAW4Bhg4tAfI=" moz-do-not-send="true">www.linkedin.com/in/miconda</a></pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a class="moz-txt-link-freetext" href="mailto:luis.rojas@sixbell.com" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894541023&sdata=3EI8zeZdhOUoE425gowBGRjeGYRhDvqbBgZa1%2FOuMCI%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="AhByAUgwrBnuuaxFnMDstx26XRDI2zHutMSw8aY4PuAmTw+S10FQlHaUpXOks2d5DNd4hMbphQl5JPHS6pUTEZqvkBTFb2GXD7hSAhHBpvBUsY78+smm0ZCn7Cn4wUdZi331PnK2Qc2hUPrrhULMkOUQOwmQqNMZ8YE03qjJFcw=" moz-do-not-send="true">http://www.sixbell.com</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894551016&sdata=UD9rVGXZqO98hWshLf3afAkNX3Ntm4c%2FpTpP3JjM1w4%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="htQmz3o7cBQW0HSEGF9xxb/pXOJRIHqXrW8coqBkZAPhkzLNuxKMAR/biBQHAFx64jOGFhuKimfUqHnY70htsJs42cEzrtgOY5XwzlRRjDeVU6WlT+KyWpiY9eQCtDr6+fL3RYTuo0jjvpko7j6a+JeWqMm5/yWO+807H0BwnHw=" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894551016&sdata=FMpW3xfX644xp608%2FDjfNDa3l%2FK2KuEH%2BlKDTv1g7jc%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="T2U6Zh0ns9qLk4sRNW6ffQ7xyM9in3UEiwu6NUjVN2D0lXIr+ZeYJOGuUCqorYrVL0T/Hjth4anab52oaYrTOg4HirlhjXiNwbVJedq2g6sgpAfmi4GTasgTAc0KQfxZbWfR4BmzsxE2tsIlL06neDrosoWc3q89F/CrlHxkyDs=" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894561008&sdata=PjGqbxCaw7OZJTxzbqgo7tY2QWD0waXvwY7rWN5sPos%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="D7X3qZYzsrR7xvw1Ayep1jPQqh89FCIZAIEF2w587RMvigVL+vwvrAi243CFxA7c0DROkju80DR/CgJ9djd3hL4iyjMZiqj535C6j+EFVcB2A5/fVnFsdnaYDhg5mqeRdre+tETSO8YvfPxNnsgXWEDGBs3QBlX6k605azADC9U=" moz-do-not-send="true">www.linkedin.com/in/miconda</a></pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a class="moz-txt-link-freetext" href="mailto:luis.rojas@sixbell.com" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894571005&sdata=WJHWemDHLyT%2FVbSPtxKhdSxNa456A9nG14vYs8Ckysg%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="h3EW02aa7H7kVg4TWxNP7ksgFxy/gCNuow/QY8XBjgIw74jJBuEZGlbmrZVf8W99Ix6/YX/oOha/ipeXBO75owdDRR2j5e+k4GwJZNTlE4Kbos9PR6xronyRCEmXAAI53CE8f8sfCxjRbyTBlf7ZufKH0Li9AT13nft0Vlry1Lc=" moz-do-not-send="true">http://www.sixbell.com</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894571005&sdata=oCrD70XaePKRYQ1bRo5NMfowuTKz1oqHYuJOY8kNuII%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="H9sS/U82yl5RkzjyvfTQY92NzrkcX9i6rAz8Wkxqx1B/STNoVXn9aOdNTkIGo0otN3Uj9EoZvtJ08nThC6/2kPERdOb88MURsqqarnnveUV/K/wsgZit87NbQs93stYNKfu+eO6pDxDyahXR49zfNQ0ZGL1kzhpz9gKV/byXTaU=" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894580996&sdata=Jw8ec499f5RI54i5OCHRIzJTz02g2t%2B7oeq3ND2lhHY%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="J0GjY/ftwCF7d0IarS7bEslMstRn9u9pmqo9q2BBFBtrxoSqnt/WkFA0Yg5gWGLt89Ht3YY6FQ39Lm8lk9Ks/xEHOUeuQeByTblIUw9Lh6z0cWLXDVFmjRaEw3PtIQWWGWNBryFrfrMCn9gynYjghW5LP67p8Nt+k1TPTzn7U9w=" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7C8eb82088a4b243f9d11308d7dc9a99a4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220428894580996&sdata=jBDwDXemGvp6O9vOOjbEt2d4WWY%2BegPHi8eJEO%2FF5Tw%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="eq3muLW9cFaGSpUVbGTKrAbZk8W74IWQNi16yQiMgn7JojGrYd9N8PChj/9ZohonJfrBp9LEOqIGS3lvsAwJkZQp4T338jsnI2Uow2O6tlhoL8spR2d8wT6vbCYgqt7WL6LQL/9jkFpKWn/MizZ0YGdO4NQl/8KBmnkgFRqWbfk=" moz-do-not-send="true">www.linkedin.com/in/miconda</a></pre>
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a class="moz-txt-link-freetext" href="mailto:luis.rojas@sixbell.com" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="http://www.sixbell.com" moz-do-not-send="true">http://www.sixbell.com</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a></pre>
</body>
</html>