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.
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.
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.
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.