The problem seems to be something to do with sip_registrar sending messages...
I don't quite understand how mdump() works... because when admin logs off/logs in.. I see in the log that msilo is trying to send messages to test1 as well? And of course this user is still offline... surely mdump() should only send the messages for the user who has just registered...
Any ideas?
-----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] Sent: 22 July 2004 14:10 To: Dave Bath Cc: serusers@lists.iptel.org Subject: Re: [Serusers] mdump() errors
you may need to filter the messages coming from msilo (ser host) and not
call failure route for those (if src_ip==127.0.0.1 or src_ip==ser_ip skip failure route).
Daniel
On 7/22/2004 2:51 PM, Dave Bath wrote:
does
d
NOT
d
-c61d, code=503
It seems that mdump() somehow doesn't pick up the fact that admin is
now
what
does
d
NOT
d
messages
are
call_id=1bcf7e00-23427@161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54
e
n
F
got one which does support it right now..) I get the following:
Jul 22 11:29:20 sip /usr/sbin/ser[23423]: MESSAGING: Offline messages
e
which
-
You find relevant information about how the msilo methods behave and the impact of module's parameters on them, in the README file of the module.
When the user goes offline, mdump() returns immediately. When the user goes online, mdump() dumps all messages stored for user which is found in URI of To header.
When a message is stored (calling mstore()), msilo is able to notify the sender that the destination is offline -- that happens only if you set registrar parameter. If you don't filter out the messages sent by mdump() and you process them in a failure route where you call mstore() then, of course, you will get the message stored and a notification message.
If you send me the config file, I will take a look.
Daniel
On 7/22/2004 3:47 PM, Dave Bath wrote:
[...]
Dave,
In my opinion (just opinion), store the message or proxy back the response depending on the situation you have.
If the callee is not login, store the message. There is a chance that the callee's UA MIGHT support MESSAGE method for later delivery. However, there is no guarantee as you don't know whether the callee's UA support this method or not.
Otherwise, proxy the response back to the caller, especially if you receive "405 Method Not Allowed". There is no point of storing the message. I don't anticipate the callee will support the MESSAGE method, not until (s)he change the UA. It's better to let the caller know about the fact and stop sending IM message again. In other word, do not put a failure route for MESSAGE method.
To be proactive, you can send an OPTION request to the UA before issuing m_dump(). You have to call some external script or write a module for that.
A not so recommended but feasible way is check for "Allow" header or MESSAGE method in "Contact" header. Note that the test is not conclusive as most UA does not include these headers. Use at your own risk.
if (search("^Contact:(.*);method(.*)MESSAGE(.*)") || search("^Allow:(.*)MESSAGE(.*)")) { log("Client indicate support of MESSAGE method, dump offline message\n"); m_dump(); } else { log("Client does not indicate support of MESSAGE method, do nothing\n"); };
Zeus