[OpenSIPS-Devel] [ opensips-Bugs-3071925 ] No reply for asyncron MI requests through mi_datagram

SourceForge.net noreply at sourceforge.net
Wed Sep 22 12:55:23 CEST 2010


Bugs item #3071925, was opened at 2010-09-20 15:50
Message generated for change (Comment added) made by vabdulla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3071925&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Vallimamod Abdullah (vabdulla)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: No reply for asyncron MI requests through mi_datagram

Initial Comment:
When using the mi_datagram module with udp, I get no reply when sending ':pua_publish:' or ':t_uac_dlg:' requests over MI.  The request however is correctly executed by opensips the MI reply is never sent. I have made a ngrep on the server and on the client, I see nothing except the request. For other requests, I get the correct reply.

Here is how to test with a MESSAGE request with t_uac_dlg (the build_msg.sh script which just generate the request with correct CRLF is attached) :

sh build_msg.sh <dest> <msg> | nc -nu <mi_datagram_server_ip> <mi_datagram_server_port>

What is very strange is that on the logs, I see the answer as sent:

[2010-09-20 15:44:30] debug - /usr/sbin/opensips[21390]: DBG:mi_datagram:datagram_close_async: the response: 200 OK 200 OK . [stripped msg body]     has been sent in 630 octets

But, as a ngrep capture shows, there is actually nothing on the wire...

----------------------------------------------------------------------

>Comment By: Vallimamod Abdullah (vabdulla)
Date: 2010-09-22 12:55

Message:
Right, you are correct.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-09-22 12:52

Message:
So, you tested with both patches applied (mi_datagram.patch and main.patch)
in the same time, right ?

----------------------------------------------------------------------

Comment By: Vallimamod Abdullah (vabdulla)
Date: 2010-09-22 12:48

Message:
Hi Bogdan,

This patch works fine.

Thank you !
Vallimamod
.


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-09-22 12:15

Message:
Hi Vallimamod,

apply also the second patch I uploaded - it seams that the opensips
processes were forked before MI was init, so the MI_UDP sockets were not
shared....

Let me know if this new patch completes the fix.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Vallimamod Abdullah (vabdulla)
Date: 2010-09-21 14:32

Message:
Hi Bogdan,

Thank you for your reply. I have applied the patch but it doesn't solve
the problem unfortunately.

I have added debug statements on datagram_close_async() func :  when
mi_send_dgram() is called, the dest address corresponds to the client
address and the socket fd corresponds to the initial rx_sock of the MI
server. Moreover, mi_send_dgram() reports the correct number of bytes sent
in datagram_fnc.c:362

I have noticed that datagram_close_async() is called by a process other
than the one who called build_async_handler() : 
- datagram_close_async() is called by Process Type=SIP receiver
- build_async_handler() is called by Process Type=MI Datagram

Is it possible that the socket fd is not valid for the the process calling
the handler ?

Thank you,
- Vallimamod
.


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-09-21 12:42

Message:
Hi Vallimamod,

could you please test the attached fix.

Thanks  and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3071925&group_id=232389



More information about the Devel mailing list