RE: [Serusers] Serweb and messaging - have i mixed up my logic! - sr-users

22 Jul 2004

Many thanks Daniel! 

This was very easy to implement, so just some encouragement for anyone
else who's struggling with msilo or message routing, once you get your
head around it, it's fine.

Another thing to check off !

D

-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] 
Sent: 21 July 2004 18:02
To: Dave Bath
Cc: serusers(a)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@161.30.94.68, 
 o-uri=sip:admin@81.86.136.86:5060, call_id=397ffff9-20938(a)127.0.0.1, 
 from=sip:test1@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@sip.dev.inmarsat.com, 
 o-uri=sip:daemon@sip.dev.inmarsat.com, 
 call_id=397ffff7-20927(a)161.30.94.68, 
 from=sip:sip_registrar@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@... 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(a)fuuz.com <mailto:dave@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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers