19 Mar
2012
19 Mar
'12
10:48 a.m.
Thanks Daniel.
I also found one more issue with msilo module. When the messages are
dumped, transactions (using uac) for all messages
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.
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.
What I want to do is to apply following algorithm in msilo:
1. get first message (ordered by id)
2. send the message
3. receive the response.
4. IF the response is 200 OK
i. remove the sent message
ii. get first message again
iii. sent the message
5. IF the response is anything other than 200 OK
i abort the process.
Not only this will ensure FIFO delivery, I think, but it will also scale
better.
Any suggestions on how to get the first message using the db_api?
Thanks
Krish Kura
On Mon, Mar 19, 2012 at 3:35 AM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
On 3/15/12 2:58 PM, Krishna Kurapati wrote:
Hi,
I am using msilo module to store offline message. I am sending back "202
pending" when the message is stored (m_store)
However, when I message delivered (m_dump), how do I inform the sender
that the message is successfully
delivered?
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.
Also, how do I handle if the sender if offline when I try to inform about
the delivery of the message.
I think I need
offline notify store to handle this condition. Instead of removing the
message from the silo table upon receipt of 200 OK
from the receiver, I am thinking keep the message there until the NOTIFY
is successfully delivered to the sender. In effect,
the silo table in the database function as offline message and notify
store.
I reviewed module_k/msilo source code, and the functionality that I need
seems missing. I am thinking of two
approaches.
1) Extend the msilo module to implement the feature, if more people need
it, then I can submit the changes.
2) Write sqlops + lua script to address the missing function.
In either case, I am thinking of storing the callid of the original
message (possibly in silo table?) in the database
and sending the NOTIFY with the callid to the sender.
I would like to extend the silo table with two columns:
1. the callid of the message
2. flags to indicate status of the delivery of the message.
Appreciate your comments, suggestions and alternatives.
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.
If you send a patch to msilo, it will be reviewed and applied.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.**php/kamailio-advanced-**training/<http://w…