Thanks Daniel.<div><br></div><div>I also found one more issue with msilo module. When the messages are dumped, transactions (using uac) for all messages</div><div>are getting created with a random callid and cseq=10. These are stored in a hash table (in tm) and scheduled to be delivered to outbound proxy. The order of delivery of messages is non deterministic. I have seen many times the messages are delivered in the wrong order though they were saved in the silo table in correct order. So when sender and receiver compare the messages, they are in totally different order.</div>
<div><br></div><div>I am thinking instead of delivering all messages at once, instead deliver one at a time. However, I ran into an issue with db.query. It does not seem to support "LIMIT 1" to just get the first message. </div>
<div><br></div><div>What I want to do is to apply following algorithm in msilo:</div><div><br></div><div>1. get first message (ordered by id)</div><div>2. send the message</div><div>3. receive the response. </div><div>4. IF the response is 200 OK</div>
<div> i. remove the sent message</div><div> ii. get first message again</div><div> iii. sent the message</div><div>5. IF the response is anything other than 200 OK</div><div> i abort the process.</div><div><br></div>
<div>Not only this will ensure FIFO delivery, I think, but it will also scale better.</div><div><br></div><div>Any suggestions on how to get the first message using the db_api?</div><div><br></div><div>Thanks</div><div>Krish Kura</div>
<div><br></div><div><br><div class="gmail_quote">On Mon, Mar 19, 2012 at 3:35 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<div class="im"><br>
<br>
On 3/15/12 2:58 PM, Krishna Kurapati wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am using msilo module to store offline message. I am sending back "202 pending" when the message is stored (m_store)<br>
However, when I message delivered (m_dump), how do I inform the sender that the message is successfully<br>
delivered?<br>
</blockquote></div>
there is no such spec in SIP -- when a message is gatewayed, 202 is sent to tell that it was received by intermediary point, but delivery to final destination is not guaranteed.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, how do I handle if the sender if offline when I try to inform about the delivery of the message.<br>
I think I need<br>
offline notify store to handle this condition. Instead of removing the message from the silo table upon receipt of 200 OK<br>
from the receiver, I am thinking keep the message there until the NOTIFY is successfully delivered to the sender. In effect,<br>
the silo table in the database function as offline message and notify store.<br>
<br>
I reviewed module_k/msilo source code, and the functionality that I need seems missing. I am thinking of two<br>
approaches.<br>
<br>
1) Extend the msilo module to implement the feature, if more people need it, then I can submit the changes.<br>
<br>
2) Write sqlops + lua script to address the missing function.<br>
<br>
In either case, I am thinking of storing the callid of the original message (possibly in silo table?) in the database<br>
and sending the NOTIFY with the callid to the sender.<br>
<br>
I would like to extend the silo table with two columns:<br>
<br>
1. the callid of the message<br>
2. flags to indicate status of the delivery of the message.<br>
<br>
Appreciate your comments, suggestions and alternatives.<br>
</blockquote></div>
These are the options I thought of - extend msilo module or do it in config with sqlops, rtimer, uac .... You may have to store the cseq number, just in case the sender UA keeps the same callid for messages sent in a raw, although it should not.<br>
<br>
If you send a patch to msilo, it will be reviewed and applied.<br>
<br>
Cheers,<br>
Daniel<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Daniel-Constantin Mierla<br>
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany<br>
<a href="http://www.asipto.com/index.php/kamailio-advanced-training/" target="_blank">http://www.asipto.com/index.<u></u>php/kamailio-advanced-<u></u>training/</a><br>
<br>
</font></span></blockquote></div><br></div>