Got SIP response 405 "Method Not Allowed"

I’m getting "Got SIP response 405 “Method Not Allowed”’ on asterisk CLI. I have read through the other posts regarding this subject but none seem to apply here.

Here is the SIP debug CLI:

<— SIP read from 190.165.XXX.XXX:64756 —>
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/UDP 208.43.1XX.XXX:5060;branch=z9hG4bK543c6222;rport=5060
To: sip:101@192.168.XX.XXX:64756;rinstance=126be8dc139a75ae;tag=b335ec06
From: "Unknown"sip:Unknown@208.43.XXX.XXX1;tag=as2544d6bc
Call-ID: 5bda150342c611bd1f9616202638f5cf@208.43.XXX.XXX
CSeq: 102 NOTIFY
Content-Length: 0

Can anyone tell from this info why I’m getting the “Method Not Allowed” response?

I’ll be happy to post further details if requested.

Thanks for any help you can give.

Because 190.165.XXX.XXX doesn’t support the NOTIFY method, which I think is used for things like message waiting and busy lamp fields (presence). It seems to be lacking and Allow header, which would say what it did support and an a User-Agent one, to say what it is.

190.165.XXX.XXX is broken, because it violates a MUST clause in RFC 3261:

[quote] The UAS MUST also add an Allow
header field to the 405 (Method Not Allowed) response. The Allow
header field MUST list the set of methods supported by the UAS
generating the message. The Allow header field is presented in
Section 20.5.[/quote]

Thanks david55 for pointing me in the right direction. I changed one of my trunks from type=friend to type=peer, after that the “Method Not Allowed” stopped.

That doesn’t make sense. I’d worry that you have allowguest = yes and the “trunk” is no longer being used at all.

The trunk is still functioning as it should. Can you tell me the name and location of the file to look in to determine if “allowguest = yes”?

sip.conf, or a file included from it.

I don’t see “allowguest = yes” in any of the sip.conf and included files.

If you have any other ideas I will be happy to follow the leads. Since it’s not happening at present it might be hard to find.

Thank you again for your help.

This means you are using allowguest=yes as this the default.
Not sure why digium thinks this is a good choice.
You should put allowguest=no in sip.conf

Check also … onf.sample

Just to clarify. Although allowguest is a security problem for the vast majority of people who don’t use SIP in a true peer to peer fashion, the relevance here was that, if you have an option in a specific sip.conf entry that is using the disallowed method, you might actually find out that, as a result of changing the sip.conf entry’s type, you are not using that sip.conf entry at all. and the calls are being treated as guest calls.

I added allowguest=no to sip_general_custom.conf (included sip.conf file). The trunk that was changed (friend to peer) is still functioning as usual.

If I’m reading you correctly that means the trunk in question is not being treated as a guest but is using the trunk sip.conf entry.

If I’ve got that wrong please let me know.

Thank you for the security heads-up on allowguest=no.