Hi List,
We seem to be hitting a strange behaviour when we get an OPTIONS ping with
a Cseq of 0. (latest 1.11 branch).
Our routing script contains this at the very beginning to decline OPTIONS
messages:
route {
if (is_method("OPTIONS")) {
sl_send_reply("501", "Method not allowed");
exit;
};
## blah...
}
If we send this OPTIONS request:
2016-07-06 17:12:05 +0100 : CLIENT_IP:5061 -> OPENSIPS_IP:5060
OPTIONS sip:200@HOSTNAME:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5061
;branch=z9hG4bK-895-1-0 From: sipp <sip:[email protected]>;tag=1 To: <sip:200@
HOSTNAME:5060> Call-ID: [email protected] CSeq: 0 OPTIONS Contact: sip:100@1
27.0.0.1:5061 Max-Forwards: 100 Content-Length: 0
There is no reply from OpenSIPS. Interestingly, siptrace module is also
running and saving captures in Homer. Homer, actually, is getting a copy of
the generated reply:
2016-07-06 17:12:05 +0100 : OPENSIPS_IP:5060 -> CLIENT_IP:5061
SIP/2.0 501 Method not allowed Via: SIP/2.0/UDP 127.0.0.1:5061;received=
*CLIENT_IP*;branch=z9hG4bK-895-1-0 From: sipp <sip:[email protected]>;tag=1 To:
<sip:200@HOSTNAME:5060>;tag=06a366df8881a48001f15f72f7138d9f.7522 Call-ID: 1
[email protected] CSeq: 0 OPTIONS Server: User Agent String Content-Length: 0
But running a tcpdump on the OpenSIPS host reveals that no actual packet is
ever sent to the client. Debug shows:
Jul 6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:core:udp_send:
sendto(sock,0x7f7867aee470,324,0,0x7fff77d00090,16): Operation not
permitted(1)
Jul 6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:sl:msg_send: udp_send
failed
OpenSIPS is running as root.
Switching Cseq to 1 in that original OPTIONS message works. But in this
particular case we have no control over the Cseq of the host we are being
pinged from, and need to reply. According to the RFC, Cseq should be a
32bit unsigned integer, so 0 should not be an issue.
Any ideas?
Thanks!
Karolis
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
