[SR-Users] Testing server up with SIP OPTIONS/netcat

[Giacomo Vacca]

Hi Andrew,
is there a \r\n at the end of the CSeq header?
You may also want to add 'Content-Length: 0'.
Alternatively sipsak is a tool often used for such keepalive requests.

Best regards,
Giacomo

On Fri, 13 Sep 2019 at 08:15, Andrew White <andrew at uconnected.com.au> wrote:

> Hi all,
>
> As part of a custom monitoring solution, I’m writing a simple script that
> sends an OPTIONS via netcat to a Kamailio server. However the server
> doesn’t appear to like it.
>
> Here’s the text - options.sip:
>
> OPTIONS sip:10.0.0.10 SIP/2.0
> Via: SIP/2.0/UDP 10.0.0.20:5060
> From: <sip:monitoring at 10.0.0.20>
> To: sip:monitoring at 10.0.0.10
> Call-ID: monitoring at 10.0.0.20
> CSeq: 1 OPTIONS
>
> I’m running the following command from the 10.0.0.20 machine:
>
> nc -u 10.0.0.10 5060 < options.sip
>
> And I get the following error in the Kamailio logs:
>
> ERROR: <core> [core/parser/parse_cseq.c:56]: parse_cseq(): method
> terminated unexpectedly
> ERROR: <core> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
> ERROR: <core> [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq
> ERROR: <core> [core/parser/msg_parser.c:337]: parse_headers(): bad header
> field [CSeq: 1 OPTIONS]
> ERROR: <core> [core/parser/parse_cseq.c:56]: parse_cseq(): method
> terminated unexpectedly
> ERROR: <core> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
> ERROR: <core> [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq
> ERROR: <core> [core/parser/msg_parser.c:337]: parse_headers(): bad header
> field [CSeq: 1 OPTIONS]
> WARNING: <core> [core/receive.c:319]: receive_msg(): parsing relevant
> headers failed
> ERROR: <core> [core/parser/parse_cseq.c:56]: parse_cseq(): method
> terminated unexpectedly
> ERROR: <core> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
> ERROR: <core> [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq
> ERROR: <core> [core/parser/msg_parser.c:337]: parse_headers(): bad header
> field [CSeq: 1 OPTIONS]
> ERROR: pv [pv_core.c:1893]: pv_get_hdr(): error parsing headers
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/parse_cseq.c:56]: parse_cseq(): method terminated unexpectedly
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/msg_parser.c:337]: parse_headers(): bad header field [CSeq: 1
> OPTIONS]
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/parse_cseq.c:56]: parse_cseq(): method terminated unexpectedly
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/msg_parser.c:337]: parse_headers(): bad header field [CSeq: 1
> OPTIONS]
> ERROR: {1 <null> monitoring at 13.236.91.139} maxfwd [mf_funcs.c:51]:
> is_maxfwd_present(): parsing MAX_FORWARD header failed!
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/parse_cseq.c:56]: parse_cseq(): method terminated unexpectedly
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/msg_parser.c:144]: get_hdr_field(): bad cseq
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/parser/msg_parser.c:337]: parse_headers(): bad header field [CSeq: 1
> OPTIONS]
> ERROR: {1 <null> monitoring at 13.236.91.139} <core>
> [core/msg_translator.c:2361]: build_res_buf_from_sip_req(): alas,
> parse_headers failed
>
> As far as I can see, the message itself is valid. It appears parse_cseq()
> is expecting a higher cseq, or more headers? I’ve looked at another OPTIONS
> message we get regularly from one of our upstream, and it’s almost
> identical to this one. Can anyone point me the right way here?
>
> Thanks!
>
> Andrew
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190913/8e765018/attachment.html>