Hi,
I'm going crazy with this problem, so maybe anyone here can see any error or can give a hint how to debug this.
I've two clients behind (the same) NAT. INVITE goes thru, so does 100 and 180. But the 200 isn't relayed because of the following syslog error:
./sbin/openser[23933]: ERROR: udp_send: sendto(sock,0x81816a8,814,0,0xb5b7f168,16): Operation not permitted(1) ./sbin/openser[23933]: msg_send: ERROR: udp_send failed
I can't find any error (the two Via headers are exactly the same), so here is the 180 which is relayed without problems, and below the 200, which causes the error:
SIP/2.0 180 Ringing Via: SIP/2.0/UDP 84.19.176.11;branch=z9hG4bK6351.1b30ad43.0 Via: SIP/2.0/UDP 192.168.123.100:2083;received=83.65.24.161;branch=z9hG4bK-kq6qyyeowiei;rport=12499 From: "Foo Bar" sip:foo1000@linguin.org;tag=xuu6a2tp6b To: sip:2000@linguin.org;user=phone;tag=2091138726 Call-ID: 3c27e5729c40-csdi3p954zyn@snom360-0004132306CE CSeq: 2 INVITE Server: Cisco ATA 186 v3.1.1 atasip (040629A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 84.19.176.11;branch=z9hG4bK6351.1b30ad43.0 Via: SIP/2.0/UDP 192.168.123.100:2083;received=83.65.24.161;branch=z9hG4bK-kq6qyyeowiei;rport=12499 Record-Route: sip:84.19.176.11;lr=on;ftag=xuu6a2tp6b;nat=yes From: "Foo Bar" sip:foo1000@linguin.org;tag=xuu6a2tp6b To: sip:2000@linguin.org;user=phone;tag=2091138726 Call-ID: 3c27e5729c40-csdi3p954zyn@snom360-0004132306CE CSeq: 2 INVITE Contact: sip:foo2000@192.168.123.103:5060;transport=udp Server: Cisco ATA 186 v3.1.1 atasip (040629A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Supported: replaces Content-Length: 204 Content-Type: application/sdp
v=0 o=foo2000 11828 11828 IN IP4 192.168.123.103 s=ATA186 Call c=IN IP4 192.168.123.103 t=0 0 m=audio 16384 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
Any ideas?
Regards, Andreas
PS: this happens with both OpenSER 1.1 and 1.2
Hi,
Maybe you can check the contact of INVITE from sip proxy to callee. Try fix_contact () for INVITE.
Regards, Lesley
2007/6/4, Andreas Granig agranig@sipwise.com:
Hi,
I'm going crazy with this problem, so maybe anyone here can see any error or can give a hint how to debug this.
I've two clients behind (the same) NAT. INVITE goes thru, so does 100 and 180. But the 200 isn't relayed because of the following syslog error:
./sbin/openser[23933]: ERROR: udp_send: sendto(sock,0x81816a8,814,0,0xb5b7f168,16): Operation not permitted(1) ./sbin/openser[23933]: msg_send: ERROR: udp_send failed
I can't find any error (the two Via headers are exactly the same), so here is the 180 which is relayed without problems, and below the 200, which causes the error:
SIP/2.0 180 Ringing Via: SIP/2.0/UDP 84.19.176.11;branch=z9hG4bK6351.1b30ad43.0 Via: SIP/2.0/UDP 192.168.123.100:2083;received=83.65.24.161 ;branch=z9hG4bK-kq6qyyeowiei;rport=12499 From: "Foo Bar" sip:foo1000@linguin.org;tag=xuu6a2tp6b To: sip:2000@linguin.org;user=phone;tag=2091138726 Call-ID: 3c27e5729c40-csdi3p954zyn@snom360-0004132306CE CSeq: 2 INVITE Server: Cisco ATA 186 v3.1.1 atasip (040629A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/UDP 84.19.176.11;branch=z9hG4bK6351.1b30ad43.0 Via: SIP/2.0/UDP 192.168.123.100:2083;received=83.65.24.161 ;branch=z9hG4bK-kq6qyyeowiei;rport=12499 Record-Route: sip:84.19.176.11;lr=on;ftag=xuu6a2tp6b;nat=yes From: "Foo Bar" sip:foo1000@linguin.org;tag=xuu6a2tp6b To: sip:2000@linguin.org;user=phone;tag=2091138726 Call-ID: 3c27e5729c40-csdi3p954zyn@snom360-0004132306CE CSeq: 2 INVITE Contact: sip:foo2000@192.168.123.103:5060;transport=udp Server: Cisco ATA 186 v3.1.1 atasip (040629A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Supported: replaces Content-Length: 204 Content-Type: application/sdp
v=0 o=foo2000 11828 11828 IN IP4 192.168.123.103 s=ATA186 Call c=IN IP4 192.168.123.103 t=0 0 m=audio 16384 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
Any ideas?
Regards, Andreas
PS: this happens with both OpenSER 1.1 and 1.2
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
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
Hi,
Could you attach all packets or openser.cfg?
Regards, Lesley
2007/6/4, Andreas Granig agranig@sipwise.com:
Hi,
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
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 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
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
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
So, which kernel causes this bad behaviour?
Andreas Granig wrote:
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Klaus,
It's 2.6.20, but it's a self-compiled one, so maybe it just isn't properly configured.
Andreas
Klaus Darilion wrote:
So, which kernel causes this bad behaviour?
Andreas Granig wrote:
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
maybe you used sip conntrack?
Andreas Granig wrote:
Klaus,
It's 2.6.20, but it's a self-compiled one, so maybe it just isn't properly configured.
Andreas
Klaus Darilion wrote:
So, which kernel causes this bad behaviour?
Andreas Granig wrote:
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Andreas Granig -
Klaus Darilion -
Lesley Liu