Because my extensions and phones are in sip custom.conf.
[root@freepbx asterisk]# cat sip_custom.conf
[4047935592] ;
defaultuser=4047935592
mailbox=4047935592@default
context=from-sip
host=dynamic
type=friend
qualify=yes
port=5060
nat=no
dtmfmode=rfc2833
insecure=no
call-limit=10
directmedia=no
callerid=" " <4047935592>
secret=fhyiC49Kx27H8cw31ml09
If you’re using FreePBX doesn’t make sense to create custom sip configuration, if they provide you a GUI to add all SIP settings through the GUI.
OK the phones are up now but no dial tone or sound.
app_macro.c:321 _macro_exec: No such context ‘macro-stdexten’
freepbxCLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
4046180843/4046180843 10.1.50.142 D Yes Yes 5060 OK (24 ms)
bandwidth-1 x.82.x.x. Yes Yes 5060 Unmonitored
bandwidth-2 x.82.x.x Yes Yes 5060 Unmonitored
3 sip peers [Monitored: 1 online, 0 offline Unmonitored: 2 online, 0 offline]
[2019-03-19 16:50:48] WARNING[12834][C-00000000]: app_macro.c:321 _macro_exec: No such context ‘macro-stdexten’ for macro ‘stdexten’. Was called by +14046180843@from-pstn
[2019-03-19 16:50:49] WARNING[12834][C-00000000]: Ext. s:3 @ from-pstn: Friendly Scanner from 216.82.224.202;branch=z9hG4bKacce.d56c8c13.0
[2019-03-19 16:51:20] WARNING[12778]: chan_sip.c:4068 retrans_pkt: Retransmission timeout reached on transmission 1294513376_63941109@192.168.16.7 for seqno 937732 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
freepbxCLI>
SIP dial tone is generated by the phones themselves before they start interacting with the server.
i cant see the incoming call number.
freepbx*CLI>
== Using SIP RTP CoS mark 5
– Executing [+14046180843@from-pstn:1] Macro(“SIP/bandwidth-1-00000009”, “stdexten,4046180843,sip/4046180843”) in new stack
[2019-03-19 17:15:23] WARNING[16681][C-00000007]: app_macro.c:321 _macro_exec: No such context ‘macro-stdexten’ for macro ‘stdexten’. Was called by +14046180843@from-pstn
– Executing [+14046180843@from-pstn:2] NoOp(“SIP/bandwidth-1-00000009”, “Received an unknown call with DID set to +14046180843”) in new stack
– Executing [+14046180843@from-pstn:3] Goto(“SIP/bandwidth-1-00000009”, “s,a2”) in new stack
– Goto (from-pstn,s,2)
– Executing [s@from-pstn:2] Answer(“SIP/bandwidth-1-00000009”, “”) in new stack
– Executing [s@from-pstn:3] Log(“SIP/bandwidth-1-00000009”, “WARNING,Friendly Scanner from 216.82.224.202;branch=z9hG4bK05ab.e53c8513.0”) in new stack
[2019-03-19 17:15:23] WARNING[16681][C-00000007]: Ext. s:3 @ from-pstn: Friendly Scanner from 216.82.224.202;branch=z9hG4bK05ab.e53c8513.0
– Executing [s@from-pstn:4] Wait(“SIP/bandwidth-1-00000009”, “2”) in new stack
– Executing [s@from-pstn:5] Playback(“SIP/bandwidth-1-00000009”, “ss-noservice”) in new stack
– <SIP/bandwidth-1-00000009> Playing ‘ss-noservice.ulaw’ (language ‘en’)
– Executing [s@from-pstn:6] SayAlpha(“SIP/bandwidth-1-00000009”, “”) in new stack
– Executing [s@from-pstn:7] Hangup(“SIP/bandwidth-1-00000009”, “”) in new stack
== Spawn extension (from-pstn, s, 7) exited non-zero on ‘SIP/bandwidth-1-00000009’
– Executing [h@from-pstn:1] Macro(“SIP/bandwidth-1-00000009”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“SIP/bandwidth-1-00000009”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“SIP/bandwidth-1-00000009”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] NoOp(“SIP/bandwidth-1-00000009”, " monior file= ") in new stack
– Executing [s@macro-hangupcall:5] AGI(“SIP/bandwidth-1-00000009”, “attendedtransfer-rec-restart.php,”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php
– <SIP/bandwidth-1-00000009>AGI Script attendedtransfer-rec-restart.php completed, returning 0
– Executing [s@macro-hangupcall:6] Hangup(“SIP/bandwidth-1-00000009”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 6) exited non-zero on ‘SIP/bandwidth-1-00000009’ in macro ‘hangupcall’
== Spawn extension (from-pstn, h, 1) exited non-zero on ‘SIP/bandwidth-1-00000009’
[2019-03-19 17:15:55] WARNING[14417]: chan_sip.c:4068 retrans_pkt: Retransmission timeout reached on transmission 1298151381_128725733@192.168.16.7 for seqno 958534 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
When this happen on FreePBX most of the time is caused due no inbound route setup for a particular DID
Also show an actual SIP debug of a call that doesn’t work after you’ve made the updates. This is a configuration issue on your side.
insecure=invite,port
insecure=invite
Because there is no reason to believe they will issue requests from random port numbers. Re-instate if they actually do this.
insecure=invite
Because there is no secret, so we wouldn’t challenge INVITEs, anyway.
Because a challenge will still issue a 401 and want a proper response. So if there is no password there still has to be a user, domain and a nonce all of which the upstream will not be able to formulate and reply back with so they will get a 403 in return.
There should be absolutely no need to challenge a peer like this because it’s a peer. It’s done via IP auth. So for Chan_SIP insecure=invite,port is how you do that
Asterisk will not issue a challenge if there is no secret (or only a remotesecret)
Insecure=invite, is an outdated way of dealing with cases where only one side is prepared to provide credentials, typically the customer side. The modern way of doing that is to use remotesecret. What it does is allow you to have a secret that you use when making outgoing calls, and, in unusual cases, for registration, but causes Asterisk to behave as though there were no secret configured for incoming calls
insecure=port is the result of ITSPs using insecure=very in their cookbook solutions because they didn’t want to understand what the sub-parameters really mean and didn’t care about the customer system’s security. ITSPs generally copy other obsolete examples, and don’t really are about customer security. Their configurations are chosen to minimise support calls to them, when dealing with naive customers.
insecure=very was deprecated, I think precisely for this reason, but instead of causing people to think about what they were setting, the cook books simply translated very to invite,port.
insecure=port tends to be needed for TCP, because the source port is random. It is not needed for most UDP cases, because the source port will always be 5060, or whatever is configured for outgoing calls.
As I said, for asymmetric authentication case, using remotesecret is better solution, because it is less obscure about what it really does.