Asterisk responds with 404 to OPTIONS even when an endpoint is matched

Hi all,

Asterisk 15.6.

I’ve got an issue where Asterisk is not replying to an OPTIONS ping with “200 OK”. It’s matching the endpoint by IP OK but still replying with a 404, which upsets our ITSP.

Am I missing anything? Thanks!

debug log:

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

Wizard

[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

[globals]
; don't allow asterisk to overwrite this file
writeprotect=yes

[inbound]
exten => s,1,Hangup

It’s doing as the RFC states it should. 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. If you add a dummy extension there (such as one that just does a NoOp) it should change to returning 200 OK.

3 Likes

Great explanation, thank you.

hi, i am running into similar issue. even though i created dummy extension “username”, but i am still getting 404 not found on options. what you think i am doing wrong?

dialplan
[kam-1]
exten => 0160109990982738,1,NoOp(This is a test call from dwkamail)
same => n,MixMonitor(REC-{STRFTIME({EPOCH},GMT-3,%C%y%m%d%H%M)}
${CALLERID(num)}.wav)
same => n,Answer
same => n,Wait(3000)
same => n,Hangup

exten => username,1,NoOp(aa)
same => n,Hangup

peer config:

[kam-1]
host=kamailio
port=5060
type=peer
usereqphone=yes
canreinvite=no
context=kam-1
dtmfmode=rfc2833
progressinband=yes
disallow=all
allow=alaw
insecure=port
qualify=yes
transport=udp

trace:

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
07:39:05.228504 IP (tos 0x10, ttl 64, id 14962, offset 0, flags [none], proto UDP (17), length 360)
kamailio.5060 > asterisk.5060: [udp sum ok] SIP, length: 332
OPTIONS sip:asterisk:5060 SIP/2.0
Via: SIP/2.0/UDP kamailio;branch=z9hG4bK389b.068f54d0000000000000000000000000.0
To: sip :asterisk :5060
From: sip :dispatcher@ localhost;tag=eb3683583afb4572e3a6635480287a80-6b5c
CSeq: 10 OPTIONS
Call-ID: 0654052444aaf7bb-25166@kamailio
Max-Forwards: 70
Content-Length: 0

07:39:05.228705 IP (tos 0x0, ttl 64, id 24940, offset 0, flags [none], proto UDP (17), length 530)
asterisk.5060 > kamailio.5060: [bad udp cksum 0x69e1 -> 0xe749!] SIP, length: 502
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP kamailio;branch=z9hG4bK389b.068f54d0000000000000000000000000.0;received=kamailio
From: sip:dispatcher@localhost;tag=eb3683583afb4572e3a6635480287a80-6b5c
To: sip:asterisk:5060;tag=as6a32dac5
Call-ID: 0654052444aaf7bb-25166@kamailio
CSeq: 10 OPTIONS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

resolved by adding “public” context with s extension:
[kam-1]
exten => 0160109990982738,1,NoOp(This is a test call from dwkamail)
same => n,MixMonitor(REC-{STRFTIME({EPOCH},GMT-3,%C%y%m%d%H%M)}
${CALLERID(num)}.wav)
same => n,Answer
same => n,Wait(3000)
same => n,Hangup
[public]
exten => s,1,NoOp(aa)
same => n,Hangup

Glad I found this as I could not understand why everything looked to be working OK and yet I could see the errors if I turned the pjsip logger on. In my case the public option did not work but by adding the username extension in the context specified in the endpoint record I got rid of the errors. Also, I simply put
exten => username,1,Hangup