I did that without our API. Its just to demo what you can do with Asterisk’s ARI and some utilities the FreePBX team wrote to interface with FreePBX
↧
Voice IVR - Any new updates or software to use?
↧
Transfer to Voicemail not a valid extension
Does your device have a transfer button or softkey? If so, does pressing it, dialing *110 and completing the transfer (device dependent) work correctly?
↧
↧
Call Parking and BLFs - Unexpected Behavior - S500
Correct the default behavior of pressing a BLF while on a call is to transfer the call to the BLF. You can instead make that behavior be to create a new call and not transfer. This is documented in the wiki for Sangoma phones.
↧
Execute AGI on AMI Originated Call
The outbound leg should be to channel local@0777$did@from-internal, then it will use your outbound routes
Looks okay, assuming the AGI file works
Never (ever!) use from-pstn-custom. Use your own context that ends with a goto to from-pstn, and direct trunk calls to this new context. Every line you put in from-pstn-custom overwrites a line of generated FreePBX dialplan, and there is an early line that is critical for system security. Do not be lulled into this habit because it’s working in your tests.
↧
PJSIP Endpoint Matching
I’ve got a somewhat unusual trunk situation. It’s an OBi202 channel that registers with Asterisk:
Trunk -> pjsip Settings tab -> General tab -> Registration = Receive.
It works as expected in all regards except incoming calls come in as a SIP Guest:
<--- Received SIP request (848 bytes) from UDP:192.168.0.234:5062 --->
INVITE sip:87055512340@192.168.0.123:5060 SIP/2.0
Call-ID: 2b088ef49fec381d@192.168.0.234
Content-Length: 314
CSeq: 8001 INVITE
From: sip:+13235554321@192.168.0.123;tag=SP37f7fd0d4ffff09e1
Max-Forwards: 70
To: sip:87055512340@192.168.0.123
Via: SIP/2.0/UDP 192.168.0.234:5062;branch=z9hG4bK-775a7339;rport
User-Agent: OBIHAI/OBi202-3.2.2.5859
Contact: sip:obi202bt@192.168.0.234:5062
Expires: 60
Supported: replaces
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Content-Type: application/sdp
v=0
o=- 76106878 1 IN IP4 192.168.0.234
s=-
c=IN IP4 192.168.0.234
t=0 0
m=audio 17110 RTP/AVP 0 8 18 104 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:104 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian
== Setting global variable ‘SIPDOMAIN’ to ‘192.168.0.123’
<— Transmitting SIP response (330 bytes) to UDP:192.168.0.234:5062 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.234:5062;rport=5062;received=192.168.0.234;branch=z9hG4bK-775a7339
Call-ID: 2b088ef49fec381d@192.168.0.234
From: sip:+13235554321@192.168.0.123;tag=SP37f7fd0d4ffff09e1
To: sip:87055512340@192.168.0.123
CSeq: 8001 INVITE
Server: FPBX-14.0.4.5(16.99.99)
Content-Length: 0
-- Executing [87055512340@from-sip-external:1] NoOp("PJSIP/anonymous-00000008", "Received incoming SIP connection from unknown peer to 87055512340") in new stack
What is needed for Asterisk to identify the incoming SIP connection and not route the incoming call to the the anonymous context?
↧
↧
PJSIP Endpoint Matching
You need a peer (DID) that matches:-
↧
PJSIP Endpoint Matching
It doesn’t matter what I put in:
Trunk -> pjsip Settings tab -> General tab -> Context
The incoming call is always sent to the anonymous (from-sip-external) context.
↧
PJSIP Endpoint Matching
When you put a context there that effectively resolves the calling party to one of your local endpoints, it will work?
Currently, do have an endpoint +13235554321
?
↧
PJSIP Endpoint Matching
I have an Inbound route for 87055512340 which points to an extension. Incoming calls make it to that extension. It’s just that they get there via from-sip-external (anonymous) and require that ‘Allow SIP Guests’ to be set to YES.
↧
↧
PJSIP Endpoint Matching
My PJSIP endpoint is:
[obi202bt]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=g722,ulaw
aors=obi202bt
language=en
outbound_auth=obi202bt
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rewrite_contact=yes
rtp_symmetric=yes
dtmf_mode=auto
↧
PJSIP Endpoint Matching
[obi202bt] does not not match +13235554321
↧
PJSIP Endpoint Matching
I have a number of trunks for DID’s. None of them use the DID number as the trunk name and incoming calls on those trunks get routed to:
Trunk -> pjsip Settings tab -> General tab -> Context
not
from-sip-external.
The problem appears to be related to this particular trunk receiving registration rather than sending registration.
↧
Multiple incoming call not work on GXW4104 and freepbx
Current Asterisk Version: 13.19.1
I check Chan_PJSip Registrations and it show Status " reject". I don’t know that problem come from FreePBX or GXW4104
https://wiki.freepbx.org/display/FOP/Configuring+a+Grandstream+GXW-410X+Device+to+act+as+an+FXO+Gateway
I follow the Gui setting from Grandstream site, What can i do now ?
↧
↧
PJSIP Endpoint Matching
I am guessing that in addition to the trunk under discussion, you also have an SPx on the same OBi configured as an extension. So pjsip can’t match by IP (both the same) or by username (you’re using that for caller ID). And FreePBX can’t (yet) tell pjsip to match on auth_username.
Try the pjsip_custom_post.conf workaround near the end of https://issues.freepbx.org/browse/FREEPBX-17803 (requires Asterisk restart).
If you still have trouble, post a detailed log.
The brute-force fix is to use chan_sip for the trunk; you can still use pjsip for the OBi extension(s).
↧
PJSIP Endpoint Matching
True, and it’s PJSIP also.
That looked so promising.
pjsip_custom_post.comf:
[global](+)
endpoint_identifier_order=auth_username,username,ip
FreePBX*CLI> pjsip show identifiers
Identifier Names:
name not specified
auth_username
username
ip
header
anonymous
Unfortunately, incoming calls on this trunk are still from an unknown peer.
↧
PJSIP Endpoint Matching
I don’t understand what’s going on, because the INVITE wasn’t challenged so it has no auth_username. I suppose you could try setting Authentication Inbound for the trunk, but if it knows to authenticate when you set it, then it already knows which trunk it is! Conceivably, it will authenticate to resolve the ambiguity.
Otherwise, post the relevant lines from a verbose log at the start of a call and maybe there will be a clue.
↧
PJSIP Endpoint Matching
I changed Authentication from Outbound to Both, but there’s still no challenge:
<--- Received SIP request (848 bytes) from UDP:192.168.1.140:5062 --->
INVITE sip:8705551234@192.168.1.115:5060 SIP/2.0
Call-ID: 0efa59b4c3400c3a@192.168.1.140
Content-Length: 314
CSeq: 8001 INVITE
From: sip:+13235554321@192.168.1.115;tag=SP31b5e06c77bef5679
Max-Forwards: 70
To: sip:8705551234@192.168.1.115
Via: SIP/2.0/UDP 192.168.1.140:5062;branch=z9hG4bK-d5cf8c98;rport
User-Agent: OBIHAI/OBi202-3.2.2.5859
Contact: sip:obi202bt@192.168.1.140:5062
Expires: 60
Supported: replaces
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Content-Type: application/sdp
v=0
o=- 78707646 1 IN IP4 192.168.1.140
s=-
c=IN IP4 192.168.1.140
t=0 0
m=audio 17164 RTP/AVP 0 8 18 104 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:104 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian
== Setting global variable ‘SIPDOMAIN’ to ‘192.168.1.115’
<— Transmitting SIP response (330 bytes) to UDP:192.168.1.140:5062 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.140:5062;rport=5062;received=192.168.1.140;branch=z9hG4bK-d5cf8c98
Call-ID: 0efa59b4c3400c3a@192.168.1.140
From: sip:+13235554321@192.168.1.115;tag=SP31b5e06c77bef5679
To: sip:8705551234@192.168.1.115
CSeq: 8001 INVITE
Server: FPBX-14.0.4.5(16.99.99)
Content-Length: 0
-- Executing [8705551234@from-sip-external:1] NoOp("PJSIP/anonymous-00000000", "Received incoming SIP connection from unknown peer to 8705551234") in new stack
The only change in pjsip*.conf files was in pjsip.endpoint.conf:
auth=obi202bt
was added to the obi202bt block.
↧
↧
PJSIP Endpoint Matching
The Authentication setting affects SIP REGISTER’s, not SIP INVITE’s.
That doesn’t look right to me and doesn’t match the hint provided with the setting.
↧
PJSIP Endpoint Matching
That makes no sense to me. If you have a typical SIP trunk (to a provider), then I believe that setting Authentication Incoming is equivalent to insecure=invite being off in a chan_sip trunk, i.e. it will challenge incoming INVITE. Authentication control on REGISTER seems strange (I’ve never seen a server that would accept a REGISTER request without challenging it).
↧
PJSIP Endpoint Matching
I agree, Stewart.
If you use Inbound (or Both) which challenges REGISTER’s, the username setting is forced to the trunk name.
↧