<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have a lot of experience developing
mutithreaded applications, and I don't see it so unlikely at all
that a process loses cpu just after recvfrom(). It's just as
probable as to lose it just before, or when writing on a cache or
just before of after sendto(). If there are many messages going
through, some of them will fall in this scenario. if I try sending
a burst of 100 messages, I see two or three presenting the
scenario.<br>
<br>
Just forward() with a single process does not give the capacity.
I'm getting almost 1000caps. More than that and start getting
errores, retransmissions, etc. And this is just one way. I need to
receive the call to go back to the network (our application is a
B2BUA), so I will be down to 500caps, with a simple scenario, with
no reliable responses, reinvites, updates, etc. I will end up
having as many standalone kamailio processes as the current
servers I do have now.<br>
<br>
I really think the simplest way would be to add a small delay to
200 OK. Very small, like 10ms, should be enough. Simple and it
should work. As Alex Balashov commented he did for the case with
ACK-Re-Invite. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have to figure out how to make
async_ms_sleep() work in reply_route().<br>
<br>
Thanks for all the comments and ideas<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
<br>
. On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite" cite="mid:2e1c8786-a7e2-0487-17f7-66348c91af1b@gmail.com">
<table id="msexchangeipsafetytips;2be8e9d7-86c6-497d-159b-08d7dca18936;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">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>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">
<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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688607541&sdata=1L8X2Nx6h%2BB2Ikj%2B8HTTl2TJj7eMzLRzWM%2FTawbpnY8%3D&reserved=0" originalsrc="https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size" shash="dqU+unFCgFpIytdzuaJAB0EhZWkNgnt0KMxZ11L07whc+cWm70og8WQGDRGpWaTpDjNPPTpucrlGFsJ+4SY3jUB4MS4i2w8ZS+DuRy22YNOfsnvMOPiDQLnI3M4ktkeMnByyltn2ruew+wYWv0s+rHceqrc6qWJEa1MtU3M4bnk=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688617500&sdata=6%2FMFcu9NfJzxmNqGRFppJjaSlm2iSYGhXdKargmv6BM%3D&reserved=0" originalsrc="https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size" shash="Si/CUVZbh0mbzP7VyxfO2kKo/uKVJw6ziCvjE5+RMeZH1l5WM56uDSqMkuaw6Uw4v9LvxBvfKtqb7M2Qaca0lgfFMyK0G1sjl6KzN5sUxc7W6eYTMAub6p9wZwq3mqFZN3nVQNYsIwRrRReNorofbtqvzCDslDGYD8Xpv7jeX+Y=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688617500&sdata=R7VybNsI08Eb61gYPn80iHeHkrIx9wGqcoW%2B4yy%2BGHo%3D&reserved=0" originalsrc="https://skalatan.de/blog/" shash="JYNXC96PpP/12nVgrmmE+/SVTQ+jRyMkQQRmY+TWaVFp6GYyzqf3dowRykQqst33kvT5O3c6qiZGAhK3geQ13pl/Q5wTX2cxSCQIsYZqAqE0y0jH8OcJtBJNN4ZTvqylsiFQziaWfos8VIPX7xnoawJZ8HUsKoyCTRysY7abnCI=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688627448&sdata=j51s%2BxSqhe%2BeM3syV0wda50nkON0FsEuLoKugcqOu3Q%3D&reserved=0" originalsrc="https://gilawa.com/" shash="fTk7SzYs3rLkZVykz/ySsGkAVVuoB/tjlfeiITNAz3k3JQwBMedlE5XiARaUq5S3EWKpTVteXmrl7f3R/oPW400eIfhcnXL1kpouNWm98xcojNKKZ4etLKB0CkkT0y6C/ETHRuaZSzRH9b/jvrBncPp70NSk+Y5Y8kaTMIfKsCQ=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688627448&sdata=QYLEaLP0l36cF9jntgvyrilRakwpWXlPw7kdIMlG%2BpY%3D&reserved=0" originalsrc="https://tools.ietf.org/html/rfc5407#page-22" shash="mw5PMvZyMFClzDxALjohzj/lr5sH4AuinLTUfCESwundFz4ZQ3v41Wo3uaoxpInQ5ehKYbQLf98ExlP2mPGwaL3Hes9ExzAXzTRGaZLGa3LOEqhHMu+IJrm2rdVspqWaYM2QN8h56DyHXhFmpwqERsMsrTaS+pDDWIieN0DEqpw=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688637406&sdata=68oasuEqgZUreKO2Fl3LTEuGedrc5n6lqS4ECPJbgzQ%3D&reserved=0" originalsrc="https://skalatan.de/blog/" shash="UQChMeEO4q1Wj6Vfzoiyz0A72A8n1PjmtTS0HxBfF/FBKyfsdM1UOZrYkmu3Q5ocbnpcXvt0fi+bL0asZQEFBqV5eUdQAVsqozzvWbsJs5kQ4vIkQCh6qcOYxPYyDMLicEDbCzlc2/2q4/NT9IWNj7Jicfd0Ow49z+9+wMBn/sA=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688637406&sdata=6dnbrKgWIlvwDKZycwoDTyjMAlYAGJy1TL3QqSbmHDw%3D&reserved=0" originalsrc="https://gilawa.com/" shash="Lbz0/LO73z214u1rjNMore9T1dlsfHetpmX+IhYKHReuS1ABLGEE2UZou6sH0RnTPeevV/rUQKBR9nyE54Odaz9o8tGDUcR7264kzswpTmv99nv4TZ4/qtyoaJ9en4BpKmrQNxkmuxlEe5K5XIi8Fz5KiRDOTPp4N7G1lrK6wtI=" 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:part18.15D8B23F.14868A85@sixbell.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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688637406&sdata=WZUsCO7APh4dMg6o6D7L0etdFjgrLhFchGMoYipf6HQ%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="xJrKISIqpbgGIhjcQUY7YCIY4vXmUJGsHRF2FLWiw2x7JfV2vTSk/r/wFCh/YUeCk7eAO6FWLqsvCSkyLAC50nkAcioQYSJL6X/syyktATBkJeK9ywrepHsDyN3yuSAWEL1MyjTNPTBKiRfcZj4vjCZTEDoxqJhDdnZBR77PwSI=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688647361&sdata=8c8o3MhRYkxAjnJbt5O7byE5G3h%2B7jOSNzpUluJ9wAk%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="rSK9xhW8CFcbVuO5ehMKJH92s+jRUiKujj4X67T+b4umPq9+5CzTeE6tLr5ZDLjV85RoSgneYnyedwxazJmnPAfwxxMECJc4755V+1HlwKgQpCtG5VZXiUDnhiB+Z1G12m6yAmsB8cx/RXmWcD+MUAZYel/PZyXNy6AJkoEspaY=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688647361&sdata=TKkHDG%2FulOvUHI8qEMBsIdpogyo5lV9WP8NjXAm7ofc%3D&reserved=0" originalsrc="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" shash="u5qW2ZS70kLjrQoMIeAKEXrbscXY1uoIq2yQmkLiE058eKsc+9K3RNvZ8V1//athC5oFe0yVS0TDyXk10l1kOyGwLBnoo3G5D3+F9MORXVmFMGBp4D5w1nvmC7Vh5uqRURLCYlBiFN5LjbBmeRCOpsLuypojDWd/wKutsJQ2K1s=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688657327&sdata=l5jLvPyZVUFAJSUfAQgatHh%2Bms25mQTaweN5elErSs8%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="EOoy5pJjd2XwRx5DxcHoeil8cY2xGW5PC6PWsSwgl1uglhRIsgvP7+Jlj4wkiNUvWYd0O9tW1zrYwqOQC8n2ukmJzDKc/KYgtecUYG6qggHCq1JE1ZFcM3SRU0mGoWLhitlJrBXBfaMEgsU9pLQy9a+iTN6t8SOThQ+brvUzvMs=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688657327&sdata=hWvlc4k8qUjd5GX6wpVOLIYMGkt09ppS6YbtQigb32s%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="0APDUGxg46BPH7QmYGqOofAzdsTX/nte1EBmoDQoh7b8kUaIQPicyccsBMm9wJiZfW9KpTzLOzE2jv+BzXhJSfn6Cq39xGcmgZiZnf4cHfBgQxg281ucP9jI7C3BsQ/Y5kCEQOvZzWgQ84IrlJOICwn6fv9UQBHQf+W6t5Tb8no=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688667271&sdata=JKWBWt8ZKJBlhb3j8poGGJ6WJuc4A1JEUA6jhBGjl1U%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="nscIL05GNgiW92CkKZ8JOyDNqMOa8gWqjgo3ezCManfH2jfWyG5+u3fjlcHiPrbV5Py6ie7WTI3v+BRdHiTemnaXsq/amYnRZ+qjrN+oMh+uevNwA5geF4r9qI7BMZ6pojYjRJVMIuEY9t2ZizGlAgV7GVSRYFYo0rkJD46OZ8E=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688667271&sdata=bhjfS28qaDdQHmcFT4ZIoJh%2Bo5R1Ry1mS6AR5WZv%2BSA%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="cbZJvO335JMpcy3rebE2vuL1nZLBnLkbNPfba+x/rSxgnzlg6I9N9nUgyFe805EuR7CcSnkJg37YalRE7igFlugDQsl3F9aRNs6SnrTDZ5nF/tX3afQy3ffhmtdNJld1vmYyIfKGPNyhDmLHwLnafOhB3We92wWVRLMGKvnwOEs=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688667271&sdata=3VUeKcQYYQXyYXFaeldHv8BwPApfbBOJWxobNVpAAgY%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="nNA+9+kDXWcjWdHrGRFLU+JvUbO0lnWSk9VoptqXFmtGQTSSuLGo0Cvvn5eWNffqcn5AOaFyRjoMuAPKTYsiYUVWaWo01r/+Cd1gJXg1jIVo7ANZX32yrjlhQpz44OebBr3r/TDdjHOcgV5jNwHWsHC6BErEL4RsipiXm2khlGQ=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688677243&sdata=7tC%2F8KInwwWHtNLOOYAGKpuIXyfJ%2FuIryavSPd6px6w%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="WHsV2TTe8YCJGUrRBlGxaUc/dPsN/gSxaYVElsxxG680y+m2TKOULOMNM6kzShRY0jtP2dEROZWyxv8Qm2dP4JQlItVCZ0BR7wFupYIT3K+FYNlNeIJhK9ipIGRvLCueZDN5Y6SwWzQLfOM2R7dq2C8xMKzYq3RmQgUoWNqgICw=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688677243&sdata=ANCvcjS4rqq4KKOnsYoWw%2F07RBpNIGGoc86T6swDTW0%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="Wv8gBhjgn+6HG0ZrlbOa5xO9yRa8b2PkfL3M4TBD1+EY9C++GTsZFutACH/XnNEm5mDdb3IG5YxJvuE9rvjGSF5z3LcxC8ToddRD1bqi/uiThDOGqfRr0eymc4l3wR54Zf7yjcBn5pA/JrYNiI7FHONgmT5HDdWGA+EX9wdvHU4=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688687187&sdata=L1G6kJSQV05C%2BQUWK7S7K4ztwaCsKQQnRkNiVQvw0Qk%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="PQL5WfKkbjqNAcSfIo9VVpD+DC/BDAJFYqmadTCnqN3MLJDjF+kDP3uBUsBRdSA0xrG79hper5YWRnMY/Th/u2YWE/mHHfQPRAiGFfI5JUVU2nz9WjpUMrHNKeFl+w9/gn9xLsY3Vkh0qxdpnx2dGEM98PZemC0JzJGvmvPe4s8=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688687187&sdata=%2B6dt120DM5yj2QuPUjYEe%2FhWvoz5tnRDk8N30ibA1Pc%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="KCXQIW/iy1Fau1OjuZ78V9fxP97Bc08YgjzIB5XhPCz4rK+vWbtZc/COE1Z52HMtB801TAb09/N5GOkCFCFnCmYp61r8y9vo/JBvxfmj5Wz/dvHQTtsfBmIbme93IKtEzD3Cat8SA2Sdxi+Unr5oXVeXHwgIPrXI5A3BaSzwpS4=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688697143&sdata=%2B3Nd%2FZ2CEuy5i3V5jS0nmtlvQWq6Efd%2F%2F%2FJjFsRuFLs%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="Q62r0sdV98r3youztxhSt0nPF2RU2rrReSqTJTVU5ji6QHi1z08CEPrDkVDCo3IZRXdBd84LQxDsDXrFjffz4e/dK8W7mzeCTzoBcCo61OCJMCqCEhmBSMzEissQ1/CaQa2pGQvEYybyxWXnK/jigUqpCZZd/NDf0y1FungQfms=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688697143&sdata=wNH%2FR%2BzFYzCKuT1KIvMmV%2Br1dTYXouHzz3PE4m42rNo%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="r/P9q0gmnQShgc1vvGPywpDHXjbX4vsJd+AW9XGgGAfdFlFTWpaI7k/lQPbSNsFPyULgZLhC3BqtcjXio4zoart1v3OdMsx0o4M8Ad9VMpLpMWSHStVjwaXob4HSmIMQRV85CLsiwFZ8qA/v6SEzA1Ug1IcJOWXKD6vjsyNCZZk=" 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="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688707101&sdata=xG2hpS5YONub55XsmlugJVg%2BZSPnzRklyWRVGdLmZ1M%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="pPukb90LQUq4tsnvPJ3RjsmTKzTHQOF9/rR2XO2kwR6a8AQovX8iz4vwWh0WPlappnGThXlwmG4FKAGiBGRoI91wyazIy7GzfqYHDMiYFfaeYxuP9yPGvqNxs3LgJGs7o6xN3Tkg2mRrqtcsvzb7/xioIVXXWVvVO8cKBDyRjHY=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688707101&sdata=XpPQwmDYb0NA9UQEC657WgfRqKdpimsUDiFMeBOxQEI%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="mKyT9H3X8B25x6F/gtLN6NP61p6HSqnFdxfbE7cyUeLxJ4fWIY2ESDZ+Y15Go7ED/Qdvo+JZrXPDrWhma03owlUOtg8W7aFUP9TT3BvdHP8G/eR9NhasnkN5tWmtQ/5Y5Zng+9vnErvikGL2cZhoZFgIYomOtdzi6uYnv+KEojU=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688717053&sdata=Ptp9ri9xfZ8Q1DbmxCZuqSKvCuY8ZiXI7hqDeWngE2I%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="mug8oErHu3UqtwsQYzOWuXJFIRt1qHAmK8ePjl9wPT8fJNo3aGHNw+z/nXzbpKu7eIybQnkBhMFu7mAU2qT+GQhR+pNT84WrwdMiE85lAx4lN2y/7sQtLa6fPPXvm3lAY667kvWtF4sGVSvJKr6zxsLwFUzYciFXwJugjKmsFaE=" 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%7C2be8e9d786c6497d159b08d7dca18936%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220458688717053&sdata=jZKcrbRzXb7FgKa12j69wIzKk29RtFDA7K%2BKNaYl4aE%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="PvoxDwApzlJZyqC03Z9UXa40hZ9DBRwJcvWhLtFxppw4TzniPefvHJodbLGuuACyWlPbG1D/76rilcGqrRWM/vLSdpJOshF48rgfdE5WHiFGNQCj44Uxp0PF/0uMy8n+SFM1jHCzyjICaHezSL/ByHWMwWS/RvhpiyuXUoSiY9c=" 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">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="http://www.sixbell.com">http://www.sixbell.com</a></pre>
</body>
</html>