[Serusers] Serweb and messaging - have i mixed up my logic!

Dave Bath dave at fuuz.com
Wed Jul 21 19:06:40 CEST 2004


Many thanks Daniel,

That is about where I had finally decided the problem must be - when
serweb tried to send the message (as you say, from daemon@) the same
processing I was using to work out if the use was offline was saying
that daemon was offline.. which is of course correct - daemon will never
be online.  As this is normal and correct, I will try and figure out
some code to put before the offline message storage which checks if the
message came from daemon@ and ignore it. 

Many thanks again, and I will let you know :-) 

D

-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel at iptel.org] 
Sent: 21 July 2004 18:02
To: Dave Bath
Cc: serusers at lists.iptel.org
Subject: Re: [Serusers] Serweb and messaging - have i mixed up my logic!

Hello,
it seems that you have configured msilo to notice the sender that the 
destination is offline. If the contact used by serweb points to server 
itself (I guess is daemon@), then there will be a loop that will get 
accounted but msilo will ignore messages coming from/going to registrar 
address (so you get: MESSAGING: offline message NOT stored). You should 
have some specific processing logic for these special addresses (if uri 
== daemon@ || sip_registrar@ => drop) in your config file.

Daniel

On 7/21/2004 6:45 PM, Dave Bath wrote:

> Hey list,
>
> Think I'm finally making some progress with msilo and serweb 
> messaging. Things appear to work, but when I look in the logs I see 
> some interesting things. The relevant bits of code are shown at the 
> bottom.
>
> Basically what I see from the logs is that when a UA is ONLINE, but 
> Doesn't support messaging, I correctly see:
>
> (i.e the failure_route[1] seems to pick it up).
>
> Jul 21 16:55:03 sip /usr/sbin/ser[20927]: MESSAGING: Destination UA 
> does not support MESSAGE requests. Stored.
>
> In the log file. However, it is immediately followed by: (161.30.94.68

> is sip.dev.inmarsat.com - its not in DNS yet)
>
> Jul 21 16:55:03 sip /usr/sbin/ser[20927]: ACC: transaction answered: 
> method=MESSAGE, i-uri=sip:admin at 161.30.94.68, 
> o-uri=sip:admin at 81.86.136.86:5060, call_id=397ffff9-20938 at 127.0.0.1, 
>
from=sip:test1 at sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54ed
-c64b, 
> code=202
>
> Jul 21 16:55:03 sip /usr/sbin/ser[20924]: MESSAGING: MESSAGE to 
> offline user received -> storing using MSILO
>
> Jul 21 16:55:03 sip /usr/sbin/ser[20924]: MESSAGING: offline message 
> NOT stored
>
> Jul 21 16:55:03 sip /usr/sbin/ser[20924]: ACC: transaction answered: 
> method=MESSAGE, i-uri=sip:daemon at sip.dev.inmarsat.com, 
> o-uri=sip:daemon at sip.dev.inmarsat.com, 
> call_id=397ffff7-20927 at 161.30.94.68, 
>
from=sip:sip_registrar at 161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54ed
-d172, 
> code=503
>
> Jul 21 16:55:03 sip /usr/sbin/ser[20924]: MESSAGING: MESSAGE to 
> offline user received -> storing using MSILO
>
> i.e. then something happens which makes Ser process it again as a 
> message to an offline user. I don't understand this. Is it something 
> to do with the way that serweb sends messages? Perhaps something 
> related to this sip:daemon at ... address? Does Ser try and send it 
> internally? And is my logic then confused by the internal ACK's?
>
> Any help would be very very much appreciated.
>
> Thanks again,
>
> Dave
>
> ----------------- BEGIN CODE SNIPPETS 
>
------------------------------------------------------------------------
--------
>
> if (!lookup("location")) { # BEGIN if not in location database
>
> # Handle messages
>
> if (method=="MESSAGE") {
>
> log(1, "MESSAGING: MESSAGE to offline user received -> storing using 
> MSILO\n");
>
> route(2);
>
> break;
>
> <snip>
>
> .....
>
> </snip>
>
> # END "if not in location database"
>
> }
>
> else
>
> { # BEGIN "user is in location database"
>
> # Set flag for accounting missed calls. If no-answer or other
>
> # network error will be logged from here
>
> setflag(3);
>
> # Check if UA supports messaging protocol before
>
> # forward to user's current destination
>
> t_on_failure("1");
>
> t_relay();
>
> break;
>
> # END "user is in location database"
>
> };
>
> ---------------------------------------------------
>
> failure_route[1] {
>
> # forwarding failed -- check if the request was a MESSAGE
>
> if (!method=="MESSAGE")
>
> {
>
> break;
>
> };
>
> # we have changed the R-URI with the contact address -- ignore it now
>
> if (m_store("1"))
>
> {
>
> log(1, "MESSAGING: Destination UA does not support MESSAGE requests. 
> Stored.\n");
>
> t_reply("202", "Accepted for delivery");
>
> break;
>
> }
>
> else
>
> {
>
> log(1, "MESSAGING: WARNING! MESSAGE request unsupported, but not 
> stored!\n");
>
> t_reply("503", "Service Unavailable");
>
> break;
>
> };
>
> }
>
> ---------------------------------------------------
>
> route[2] {
>
> # Route for handling message transmission using msilo. Store a message

> locally if a UA
>
> # is offline, but supports messaging protocol.
>
> if (!t_newtran()) {
>
> sl_reply_error();
>
> break;
>
> };
>
> if (m_store("0")) {
>
> log(1, "MESSAGING: offline message stored\n");
>
> t_reply("202", "Accepted for Later Delivery");
>
> break;
>
> };
>
> log(1, "MESSAGING: offline message NOT stored\n");
>
> t_reply("503", "Service Unavailable");
>
> break;
>
> }
>
> /-------------------------------------/
>
> /Dave Bath/
>
> /dave at fuuz.com <mailto:dave at fuuz.com>/
>
> /www.fuuz.com <http://www.fuuz.com>/
>
> /07736 232085/
>
> NOTE: The information contained in this email is intended for the 
> named recipients only, it may be privileged and confidential. If you 
> are not the intended recipient, you must not copy distribute or take 
> any action in reliance upon it. No warranties or assurances are made 
> in relation to the safety and content of this email and any 
> attachments. No liability is accepted for any consequences arising
from it
>
>-----------------------------------------------------------------------
-
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>  
>







More information about the sr-users mailing list