Argh, it was a nasty kernel problem. Haven't figured out yet what exactly causes this behaviour, but booting with another kernel fixes that. Well... :o)
Best regards, Andreas
Andreas Granig wrote:
Hi,
Some more insights:
If I do conditional call forwards, the problem also occurs with rtpproxy. Here's the last log of an INVITE in the branch-route:
./sbin/openser[27736]: Branch-Route, ruri='sip:foo2000@192.168.123.103:5060;transport=udp', du='sip:83.65.24.161:16450' - M='INVITE' R='sip:foo2000@192.168.123.103:5060;transport=udp' F='sip:foo1000@linguin.org' ID='3c26923794ed-0qet85v1w0in@snom360-0004132306CE' ./sbin/openser[27736]: ERROR: udp_send: sendto(sock,0xb5cdb638,1403,0,0xb5cd8e0c,16): Operation not permitted(1) ./sbin/openser[27736]: msg_send: ERROR: udp_send failed
I've no more ideas why the operation should not be permitted when sending to the d-uri "83.65.24.161:16450".
Andreas
Andreas Granig wrote:
Hi,
The config is the mediaproxy-template from http://www.sipwise.com/wizard/ , so it's really just very basic.
The odd thing is, that when using rtpproxy instead of mediaproxy, it works as expected. Something must be wrong with my mediaproxy setup, but there isn't much to do wrong, and I also get a correct answer from mediaproxy for the lookup:
proxydispatcher[26619]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '84.19.176.11 30002'
I'm running out of ideas. To sum it up: rtpproxy works in this setup, mediaproxy doesn't. I haven't seen this before, and I've set up quite a lot of such setups :o)
Andreas
Lesley Liu wrote:
Hi,
Could you attach all packets or openser.cfg?
Regards, Lesley
2007/6/4, Andreas Granig <agranig@sipwise.com mailto:agranig@sipwise.com>:
Hi, > Maybe you can check the contact of INVITE from sip proxy tocallee. > Try fix_contact () for INVITE.
The contact is fixed for INVITE. Also, replies are routedaccording to the Via-Header, so this isn't the issue.
What I've found out in the meanwhile is, that it's theuse_media_proxy() in the reply-route which causes the problem. If I comment this line, the 200-OK is routed without problems (but there's one-way-audio, obviously). Any hints in that direction?
Regards, Andreas
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users