While configuring SIP/PJSIP in Asterisk you may notice that Asterisk responds with 404 Not Found to the OPTIONS request. To demonstrate the behavior let’s have a look at this PJSIP debug log example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
<--- Received SIP request (421 bytes) from UDP:YYY.YYY.YYY.YYY:5060 ---> OPTIONS sip:username@XXX.XXX.XXX:5060 SIP/2.0 Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKf3ib152010patog7dmj0.1 From: "username"<sip:username@YYY.YYY.YYY.YYY:5060>;tag=5b17a3af569c5d90b23a68c65e7018bb8764d339 To: "username"<sip:username@XXX.XXX.XXX:5060> Call-ID: 5b17a3af569c5d90b23a68c65e7018bb8764d339 CSeq: 1 OPTIONS Max-Forwards: 49 Content-Length: 0 [Sep 21 13:44:18] DEBUG[13733]: res_pjsip/pjsip_distributor.c:393 find_dialog: Could not find matching transaction for Request msg OPTIONS/cseq=1 (rdata0x7f2bdc001c18) [Sep 21 13:44:18] DEBUG[13733]: res_pjsip/pjsip_distributor.c:471 ast_sip_get_distributor_serializer: Calculated serializer pjsip/distributor-00000026 to use for Request msg OPTIONS/cseq=1 (rdata0x7f2bdc001c18) [Sep 21 13:44:18] DEBUG[13734]: netsock2.c:170 ast_sockaddr_split_hostport: Splitting 'YYY.YYY.YYY.YYY' into... [Sep 21 13:44:18] DEBUG[13734]: netsock2.c:224 ast_sockaddr_split_hostport: ...host 'YYY.YYY.YYY.YYY' and port ''. [Sep 21 13:44:18] DEBUG[13734]: res_pjsip_endpoint_identifier_ip.c:240 ip_identify_match_check: Source address YYY.YYY.YYY.YYY:5060 matches identify 'Trunk_Primary-identify' [Sep 21 13:44:18] DEBUG[13734]: res_pjsip_endpoint_identifier_ip.c:273 common_identify: Identify 'Trunk_Primary-identify' SIP message matched to endpoint Trunk_Primary <--- Transmitting SIP response (945 bytes) to UDP:YYY.YYY.YYY.YYY:5060 ---> SIP/2.0 404 Not Found Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;rport=5060;received=YYY.YYY.YYY.YYY;branch=z9hG4bKf3ib152010patog7dmj0.1 Call-ID: 5b17a3af569c5d90b23a68c65e7018bb8764d339 From: "username" <sip:username@YYY.YYY.YYY.YYY>;tag=5b17a3af569c5d90b23a68c65e7018bb8764d339 To: "username" <sip:username@XXX.XXX.XXX>;tag=z9hG4bKf3ib152010patog7dmj0.1 CSeq: 1 OPTIONS Accept: application/sdp, application/dialog-info+xml, application/simple-message-summary, application/pidf+xml, application/xpidf+xml, application/cpim-pidf+xml, application/pidf+xml, application/dialog-info+xml, application/simple-message-summary, message/sipfrag;version=2.0 Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Accept-Encoding: text/plain Accept-Language: en Server: Asterisk PBX 15.6.0 Content-Length: 0 test-asterisk*CLI> |
pjsip.conf looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
[trunk](!) type = wizard accepts_auth = no accepts_registrations = no sends_auth = no sends_registrations = no endpoint/disallow = all endpoint/allow = alaw,ulaw,g729 endpoint/direct_media = no endpoint/allow_subscribe = no endpoint/trust_id_inbound = yes endpoint/context = inbound endpoint/send_pai = yes endpoint/callerid_privacy=allowed endpoint/trust_id_outbound=yes endpoint/identify_by=ip aor/qualify_frequency = 60 [Trunk_Primary](trunk) remote_hosts = YYY.YYY.YYY.YYY transport = transport-udp-vlan301 |
extensions.conf looks like this:
|
1 2 3 4 5 6 |
[globals] ; don't allow asterisk to overwrite this file writeprotect=yes [inbound] exten => s,1,Hangup |
The explanation can be found in RFC: an OPTIONS is supposed to be treated as if it were an INVITE, just without actually creating a call. For normal endpoints they have no concept of an extension so the phone would just ring and thus they return 200 OK pretty much always. In the case of Asterisk we are aware of extensions and as a result it would be looking for an extension named “username” in the context of the matched endpoint. So if we add a dummy extension there (such as one that just does a NoOp) it should change to returning 200 OK.
I hope this post clarifies the situation with Asterisk 404 Not Found!
Good luck!
