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
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Dave Bath Sent: Thursday, 22 July 2004 11:48 PM To: daniel@iptel.org Cc: serusers@lists.iptel.org Subject: RE: [Serusers] mdump() errors
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:
As a follow up to this, it seems theres some bizarre looping going on....
Now that I've had a UA sign on and off a few times, the number of messages to offline users in the syslog is increasing
exponentially...
If I just start with one message sent from test1-->admin
while admin is
(online-but-doesn't-support-MESSAGE) then I see the message stored correctly. If I go to Serweb I see:
sip:test1@sip.dev.inmarsat.com today 13:42 test
correctly.
When admin's UA signs off and back on again, I see the
following... in
serweb
sip:test1@sip.dev.inmarsat.com today 13:42 test
sip:test1@sip.dev.inmarsat.com today 13:43 [Offline message - Thu Jul 22 13:42:58 2004] test
And the following in the error log:
Jul 22 13:43:29 sip /usr/sbin/ser[30426]: MESSAGING: Offline
messages
dumped Jul 22 13:43:29 sip /usr/sbin/ser[30431]: MESSAGING:
Destination
UA
does
not support MESSAGE requests. Message Stored. Jul 22 13:43:29 sip /usr/sbin/ser[30431]: ACC: transaction answered: method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com, o-uri=sip:admin@81.86.136.86:5060,
call_id=769feac0-30426@161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf7686
1cbb9ed54e d
-7963, code=202 Jul 22 13:43:29 sip /usr/sbin/ser[30427]: MESSAGING: Message
to offline
user received -> storing using msilo... Jul 22 13:43:30 sip /usr/sbin/ser[30427]: MESSAGING: offline message
NOT
stored Jul 22 13:43:30 sip /usr/sbin/ser[30427]: ACC: transaction answered: method=MESSAGE, i-uri=sip:test1@sip.dev.inmarsat.com, o-uri=sip:test1@sip.dev.inmarsat.com, call_id=769feac1-30431@161.30.94.68, from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf7686
1cbb9ed54e d
-c61d, code=503
It seems that mdump() somehow doesn't pick up the fact that admin is
now
not an offline user, so it generates a new message... any ideas?! (*begs*)!
Very best regards,
Dave
-----Original Message----- From: serusers-bounces@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Dave Bath Sent: 22 July 2004 12:58 To: serusers@lists.iptel.org Subject: RE: [Serusers] mdump() errors
Ok! Well... adding in the server name to hosts file solved that problem.. thanks for pointing me in the right direction!
However... now there's some more weirdness... as you can
see, when the
registration happens, mdump() tries to send all the currently stored messages.. but, my failure_route picks it up and enters the
next line
"Destination UA does not support... ". However, I don't understand
what
happens after that... I don't understand why I then get a
"Message to
offline user received.." - that should only appear when
sending to a
user which doesn't have a current location...
When not using mdump().. i.e. I'm just sending IMs using
serweb to (1)
offline UAs and (2) Unsupported UAs I do not see this
problem... only
the correct entries are in the log.
Perhaps I do not understand the way mdump() works?
Any thoughts gratefully receieved...
D
Jul 22 12:49:40 sip /usr/sbin/ser[23423]: MESSAGING: Offline
messages
dumped Jul 22 12:49:40 sip /usr/sbin/ser[23424]: MESSAGING:
Destination
UA
does
not support MESSAGE requests. Message Stored. Jul 22 12:49:40 sip /usr/sbin/ser[23424]: ACC: transaction answered: method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com, o-uri=sip:admin@81.86.136.86:5060,
call_id=1bcf7e01-23423@161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf7686
1cbb9ed54e d
-322f, code=202 Jul 22 12:49:40 sip /usr/sbin/ser[23427]: MESSAGING: Message
to offline
user received -> storing using msilo... Jul 22 12:49:40 sip /usr/sbin/ser[23427]: MESSAGING: offline message
NOT
stored Jul 22 12:49:40 sip /usr/sbin/ser[23427]: ACC: transaction answered: method=MESSAGE, i-uri=sip:test1@sip.dev.inmarsat.com, o-uri=sip:test1@sip.dev.inmarsat.com, call_id=1bcf7e01-23424@161.30.94.68, from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf7686
1cbb9ed54e d
-4a28, code=503