OPTIONS messages got 408 Request Timeout

Hello Community,

I have question about OPTIONS messages. Mine company work with Interactive Genesis platform for Contact Center solutions. We have one customer who have 3rd party support for Asterisk servers. After update of new release for EDGE component witch is (media,proxy,gateway) all in one, they open ticket with problem of not able to send OPTIONS messages to our EDGE from their Asterisk.
We open support ticket to our ININ team and they suggest the adding port number on Request URI part. Other side(3rd party) claim that that is impossible to manage.
Can someone who know this issue help on this problem. It’s Asterisk 11.6 in usage and yes I know its EOF support.

Thanks a lot to any who can help to solve this problem, I’m wish to fix this strange problem.

Best regards,
Igor

There is no mention of 408 in the body of your posting.

Asterisk sends 408, if the relevant options are set, to test the integrity of the signalling path. The peer should respond with, at the very least, 404. If it doesn’t respond at all, either it is violating the SIP protocol, or there is a network problem that needs fixing in the network.

I’m not sure if 11.8 includes pjsip, but for, the older, chan_sip, you use qualify=no, if the peer doesn’t respond to OPTIONS at all, or is upset by them.

1 Like

Hello david,

No 11.6 does not support pjsip and I can not use aor for that purpose. We test with pjsip on 13 version of asterisk and other peer response with 200ok on qualify.

If I use qualify=no then I can’t see if asterisk see that peer with options messages. How ever when I make that on yes and use debug, asterisk try to retransmitting message and after 4 times give 408 message.

Is it possible to make on older sip_chan OPTIONS to work? This is mine sip.conf for test purpose, and debug logs. This is just test configure and I just wanted other end to respond.

[edge]
type=peer
canreinvite=no
host=10.20.11.5
port=5058
context=from-internal
disallaw=all
allow=ulaw,alaw
qualify=yes
nat=force_rport,comedia.


Retransmitting #4 (NAT) to 10.20.11.5:5058:
OPTIONS sip:10.20.11.5 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.15:5060;branch=z9hG4bK13933e0c;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@10.0.2.15;tag=as16ad93a9
To: sip:10.20.11.5
Contact: sip:asterisk@10.0.2.15:5060
Call-ID: 3c86c3bf6f4fc0d444799ed16c805d76@10.0.2.15:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 11.25.0
Date: Fri, 29 Dec 2017 10:17:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


Really destroying SIP dialog ‘3c86c3bf6f4fc0d444799ed16c805d76@10.0.2.15:5060’ Method: OPTIONS

<— SIP read from UDP:10.20.11.5:5058 —>
SIP/2.0 408 Request Timeout
From: “asterisk” sip:asterisk@10.0.2.15;tag=as662d7e74
To: sip:10.20.11.5;tag=3031944530
Via: SIP/2.0/UDP 10.20.11.5:5058;branch=z9hG4bK68b900895e095d077a9a6ff16, SIP/2.0/UDP 10.0.2.15:5060;received=192.168.113.4;rport=62031;branch=z9hG4bK718c42b0
Call-ID: 105453c521ccf01f5ed0b2922ec500f7@10.0.2.15:5060
CSeq: 102 OPTIONS
Content-Length: 0

<------------->
— (7 headers 0 lines) —

Thank you on support.

Best regards,
Igor

Only by fixing the peer. If the peer doesn’t respond, then the link is broken.

I believe the 408 is faked internally and means the peer didn’t respond to the request. Peers should respond, even if they don’t understand OPTIONS, or the URI given is not valid. Asterisk treats an error response as being acceptable.

If link is broken then even pjsip aor won’t works fine but it does. It respond normally 200ok.
Are you sure that even if not understand options peers will respond?

Also, when I use CLI and reload sip.conf got this message:
*CLI> [Dec 29 11:42:50] NOTICE[17946]: chan_sip.c:29806 sip_poke_noanswer: Peer ‘edge’ is now UNREACHABLE! Last qualify: 0

That is main problem. It must see Reachable that peer for options to work if I’m right?

From EDGE side its configured to accept and respond on options messages and asterisk is added on access list of devices.

The peer should respond with an invalid request or method unknown type response, even if it doesn’t understand OPTIONS. It should respond with 404 or 403 it it doesn’t like the URI.

If normal SIP implementations simply ignored options, there would be a lot of people raising this issue, but there are not.

Although I doubt there is a work around, you will need to identify why the peer is silently ignoring the request, rather than rejecting it, before any suggestion can be made as to a work round.

1 Like

@jcolp Are there any work around on this problem?

I have nothing to add that @david551 hasn’t already said.