OPTIONS is affected by the qualify setting, which is present for both SIP channel drivers. I would expect Method not Allowed, to be considered a good response, as the intent of OPTIONS is to obtain a response without changing the state of the remote party. Any response should do.
type=user is unlikely to work, as it would require the ITSP to set the the user part of the From header to 390541000000, when it more likely to be the caller ID. It is also unlikely to work as I don’t know of any ITSP that authenticates itself with a password. Regarding the first point the type=friend should be type=peer (friend is user + peer, but only the peer part is effective, and the user part provides an attack surface). and, in any case, it can’t have the same name as the type=user.
Generally, you should have incoming sections which are type=peer, and have no password, for every possible IP address from which you can receive calls from the ITSP. If that is a whole /24, you will need ~256 sections for chan_sip, but chan_pjsip would allow you a single match/permit entry.
Also, generally, all incoming and outgoing sections, for a provider, should have the same context.
(username isn’t documented as doing anything useful for outgoing registration cases.)
I initially assumed that you did have have it working, with chan_sip, before, but it looks like you have never had it working. In that case there is absolutely no case for persisting in trying to make chan_sip work.
I imagine that is because the incoming calls neither originate from 54.229.10.161, nor have a from user field set to 390541000000 or the name of your outbound section, so they don’t match friend in either host or user mode. Also, you haven’t specified any codecs on the incoming section, even allow=all can cause problems.
The ITSP (or your router) seems to have lost the call after it acknowledged it.
The Via header in the responses is wrong. Whilst I can’t rule out that it is jiggery pokery by chan_sip, which possibility you could exclude by using sngrep to confirm that the problem is still there at the boundary of the machine running Asterisk, my best guess is that you have a rogue application level gateway on your router, in which case you should disable it. The second guess is that the ITSP is having serious difficulty complying with RFC 3261. The first parameter should be unchanged from the request.
On the inbound attempt, if anything appears in the Asterisk log, paste that, including pjsip logger information. If not, if anything appears in sngrep, post that. If nothing in sngrep, report what caller hears and what, if anything, appears in provider’s log.
I try to make an outbond call to my IVR and i’m not able to digit option 1,2,3 when i press for example the button numer 1 on my cordless voip the ivr not recognize.
I have test the PBX and everything works audio is ok i can make inbound and outbound call, but after 1 hour or less the trunk change status from “registered” to “rejected”, any ideas ?
