[Serusers] mdump() errors

Daniel-Constantin Mierla daniel at iptel.org
Thu Jul 22 15:09:47 CEST 2004 

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 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
>
>
>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>  
>

More information about the sr-users mailing list