4 Jun
2007
4 Jun
'07
5:07 p.m.
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:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users Hi,
Could you attach all packets or openser.cfg?
Regards,
Lesley
2007/6/4, Andreas Granig <agranig(a)sipwise.com
<mailto:agranig@sipwise.com>>:
Hi,
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users Maybe you can check the contact of INVITE from
sip proxy to
callee.
Try fix_contact () for INVITE.
The contact is fixed for INVITE. Also, replies are routed
according to
the Via-Header, so this isn't the issue.
What I've found out in the meanwhile is, that it's the
use_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