[Serusers] mdump() errors

[Dave Bath]

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 at 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 at sip.dev.inmarsat.com		today 13:42
test

sip:test1 at 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 at sip.dev.inmarsat.com,
o-uri=sip:admin at 81.86.136.86:5060, call_id=769feac0-30426 at 161.30.94.68,
from=sip:test1 at sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54ed
-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 at sip.dev.inmarsat.com,
o-uri=sip:test1 at sip.dev.inmarsat.com,
call_id=769feac1-30431 at 161.30.94.68,
from=sip:sip_registrar at 161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54ed
-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 at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of Dave Bath
Sent: 22 July 2004 12:58
To: serusers at 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 at sip.dev.inmarsat.com,
o-uri=sip:admin at 81.86.136.86:5060, call_id=1bcf7e01-23423 at 161.30.94.68,
from=sip:test1 at sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54ed
-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 at sip.dev.inmarsat.com,
o-uri=sip:test1 at sip.dev.inmarsat.com,
call_id=1bcf7e01-23424 at 161.30.94.68,
from=sip:sip_registrar at 161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54ed
-4a28, code=503

-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel at iptel.org] 
Sent: 22 July 2004 12:38
To: Dave Bath
Cc: serusers at lists.iptel.org
Subject: Re: [Serusers] mdump() errors

How is registered sip.dev.inmarsat.com in your DNS? mdupm() tries to 
send messages to <sip:admin at sip.dev.inmarsat.com>. Is there an IP 
associated with this domain or a SRV entry for it?

Daniel

On 7/22/2004 1:22 PM, Dave Bath wrote:

>Hey Daniel, 
>
>Many thanks for reply.  I don't think it is as stated in error messages
>- as I have a single machine with a single NIC and single IP.  Here are
>the network dumps foe the register statement, and corresponding syslog
>entry.
>
>Jul 22 12:17:58 sip /usr/sbin/ser[23427]: MESSAGING: Offline messages
>dumped
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: ERROR: udp_send:
>sendto(sock,0xbd72b0f8,633,0,0xbd72a464,16): Invalid argument(22)
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: CRITICAL: invalid
>sendtoparameters one possible reason is the server is bound to
localhost
>and attempts to send to the net
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: msg_send: ERROR: udp_send
>failed
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: ERROR: t_forward_nonack:
>sending request failed
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: ACC: transaction answered:
>method=MESSAGE, i-uri=sip:admin at sip.dev.inmarsat.com,
>o-uri=sip:admin at 81.86.136.86:5060, call_id=1bcf7e00-23427 at 161.30.94.68,
>from=sip:test1 at sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54e
d
>-cced, code=477
>
>interface: eth0 (161.30.94.64/255.255.255.224)
>filter: ip and ( port 5060 )
>match: UDP
>#
>U 81.86.136.86:5060 -> 161.30.94.68:5060
>REGISTER sip:sip.dev.inmarsat.com SIP/2.0..Via: SIP/2.0/UDP
>81.86.136.86:50
>60;rport;branch=z9hG4bKDA365D6C01604EF4ABC2FED4B3AAF541..From: Dave
Bath
><s
>ip:admin at sip.dev.inmarsat.com>;tag=1598567160..To: Dave Bath
><sip:admin at sip
>.dev.inmarsat.com>..Contact: "Dave Bath"
><sip:admin at 81.86.136.86:5060>..Cal
>l-ID: F64F298D25B34CB69E54236E6B62A53B at sip.dev.inmarsat.com..CSeq:
43904
>RE
>GISTER..Expires: 1800..Max-Forwards: 70..User-Agent: X-Lite release
>1103m..
>Content-Length: 0....
>#
>U 161.30.94.68:5060 -> 81.86.136.86:5060
>SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP
>81.86.136.86:5060;rport=5060;bra
>nch=z9hG4bKDA365D6C01604EF4ABC2FED4B3AAF541..From: Dave Bath
><sip:admin at sip
>.dev.inmarsat.com>;tag=1598567160..To: Dave Bath
><sip:admin at sip.dev.inmarsa
>t.com>;tag=b27e1a1d33761e85846fc98f5f3a7e58.3ce6..Call-ID:
>F64F298D25B34CB6
>9E54236E6B62A53B at sip.dev.inmarsat.com..CSeq: 43904
>REGISTER..WWW-Authentica
>te: Digest realm="sip.dev.inmarsat.com",
>nonce="40ffa3926d16f7926917b380f86
>83ceb509974df"..Server: Sip EXpress router (0.8.12
>(i386/linux))..Content-L
>ength: 0..Warning: 392 161.30.94.68:5060 "Noisy feedback tells:
>pid=23430
>req_src_ip=81.86.136.86 req_src_port=5060
>in_uri=sip:sip.dev.inmarsat.com o
>ut_uri=sip:sip.dev.inmarsat.com via_cnt==1"....
>#
>U 81.86.136.86:5060 -> 161.30.94.68:5060
>REGISTER sip:sip.dev.inmarsat.com SIP/2.0..Via: SIP/2.0/UDP
>81.86.136.86:50
>60;rport;branch=z9hG4bKA3FF9ABFFB7945CBB01DA4A460F991E9..From: Dave
Bath
><s
>ip:admin at sip.dev.inmarsat.com>;tag=1598567160..To: Dave Bath
><sip:admin at sip
>.dev.inmarsat.com>..Contact: "Dave Bath"
><sip:admin at 81.86.136.86:5060>..Cal
>l-ID: F64F298D25B34CB69E54236E6B62A53B at sip.dev.inmarsat.com..CSeq:
43905
>RE
>GISTER..Expires: 1800..Authorization: Digest
>username="admin",realm="sip.de
>v.inmarsat.com",nonce="40ffa3926d16f7926917b380f8683ceb509974df",respon
s
>e="
>96729bb402fed85833dd6e1fb0cb08c9",uri="sip:sip.dev.inmarsat.com"..Max-F
o
>rwa
>rds: 70..User-Agent: X-Lite release 1103m..Content-Length: 0....
>#
>U 161.30.94.68:5060 -> 81.86.136.86:5060
>SIP/2.0 200 OK..Via: SIP/2.0/UDP
>81.86.136.86:5060;rport=5060;branch=z9hG4b
>KA3FF9ABFFB7945CBB01DA4A460F991E9..From: Dave Bath
><sip:admin at sip.dev.inmar
>sat.com>;tag=1598567160..To: Dave Bath
><sip:admin at sip.dev.inmarsat.com>;tag
>=b27e1a1d33761e85846fc98f5f3a7e58.29ec..Call-ID:
>F64F298D25B34CB69E54236E6B
>62A53B at sip.dev.inmarsat.com..CSeq: 43905 REGISTER..Contact:
><sip:admin at 81.8
>6.136.86:5060>;q=0.00;expires=1800..Server: Sip EXpress router (0.8.12
>(i38
>6/linux))..Content-Length: 0..Warning: 392 161.30.94.68:5060 "Noisy
>feedbac
>k tells:  pid=23427 req_src_ip=81.86.136.86 req_src_port=5060
>in_uri=sip:si
>p.dev.inmarsat.com out_uri=sip:sip.dev.inmarsat.com via_cnt==1"....
>###
>
>-----Original Message-----
>From: Daniel-Constantin Mierla [mailto:daniel at iptel.org] 
>Sent: 22 July 2004 12:01
>To: Dave Bath
>Cc: serusers at lists.iptel.org
>Subject: Re: [Serusers] mdump() errors
>
>The error is related to sendto() function. If it is not the situation 
>shown in the error messages, please send the network dumps including
the
>
>REGISTER request that triggers the mdump(). The error messages are 
>underlined below.
>
>Daniel
>
>On 7/22/2004 12:50 PM, Dave Bath wrote:
>
>  
>
>>Hey guys,
>>
>>Finally have the proper logic in place to cope with offline messages 
>>and messages to UAs that don't support the MESSAGE method... however,
>>    
>>
>at 
>  
>
>>the end of the REGISTER block in my ser.cfg I try and call mdump() to 
>>make sure any offline messages are delivered to the UA.... However
>>    
>>
>when 
>  
>
>>registering with a UA which doesn't support MESSAGE method (I haven't 
>>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 
>>dumped
>>
>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: ERROR: udp_send: 
>>sendto(sock,0xbd72b0f8,633,0,0xbd72a
>>
>>464,16): Invalid argument(22)
>>
>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: CRITICAL: invalid 
>>sendtoparameters one possible reaso
>>
>>n is the server is bound to localhost and attempts to send to the net
>>
>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: msg_send: ERROR: udp_send
>>    
>>
>failed
>  
>
>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: ERROR: t_forward_nonack: 
>>sending request failed
>>
>>    
>>
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>  
>
>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: ACC: transaction answered: 
>>method=MESSAGE, i-uri=sip:
>>
>>admin at sip.dev.inmarsat.com, o-uri=sip:admin at 81.86.136.86:5060, 
>>call_id=1bcf7e00-23423 at 161.30.94
>>
>>.68, 
>>
>>    
>>
>from=sip:test1 at sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54e
d
>-57d2, 
>  
>
>>code=477
>>
>>Is this perhaps because m_dump() is trying to send it to the UA even 
>>though the UA does not support MESSAGE? If so, is there a way I can 
>>catch it? Does the registration process interrogate the UA as to which
>>    
>>
>
>  
>
>>methods it supports? Perhaps if this is the case, I could only do an 
>>m_dump() if the UA supported messages? Or does m_dump() have its own 
>>error handling somewhere?
>>
>>Sorry for all the questions!
>>
>>NB. I don't get this message when sending an IM to an offline or an 
>>online-but-message-unsupported-UA... only as part of the m_dump in my 
>>register block...
>>
>>Many thanks in advance,
>>
>>Dave
>>
>>/-------------------------------------/
>>
>>/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
>> 
>>
>>    
>>
>
>
>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>  
>




_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers