Still looking for information on key system functionality for Grandstream 2000 sets.
Here is where I am.
System is up with working extensions SIP/Extensions
No analog at all.
Asterisk GUI-version Revision: 11425 $
I have thew following built Sla.conf
I have the following built in extensions.conf
(4 occurances, changed the station numbers from 1 to 4 as I added.
exten = station1,1,SlAStation(station1)
exten = station1_line1,1,SLAStation(station1_line1)
exten = station1_line2,1,SLAStation(station1_line2)
exten = station1_line3,1,SLAStation(station1_line3)
exten = station1_line4,1,SLAStation(station1_line4)
exten = station1_line1,hint,SLA:station1_line1
exten = station1_line2,hint,SLA:station1_line2
exten = station1_line3,hint,SLA:station1_line3
exten = station1_line4,hint,SLA:station1_line4
I will populate each extension’s context to sla-stations when ready.
(not having any trouble with sip/extensions)
It looks like the days of having extensions are over as soon as
sip context is changed ?? Can anyone verify this??
I think I need to to populate ZAPATA.conf with the following.
exten = s,1,SLATrunk(line1)
exten = s,1,SLATrunk(line2)
exten = s,1,SLATrunk(line3)
exten = s,1,SLATrunk(line4)
These a 4 different contexts.
Has anyone done this?
If so, precisely where do these live in ZAPATA?
or do they live in zapata.conf.zapscan??
I added these in zapata.conf and zapata.cong.zapscan as 4 individual contexts. Then did reload Chan_zap.so
Lost the box. The indication being that there was an unassigned channel
resource. I placed a call into the box to test when all of this went the way of the world.
Asterisk began doing cyclic restarts even after a power off and reboot.
Looked like something trashed modules / files ??
System reload finally put an end to it.
I am not in the mood to do this again without some assistance from someone that has this working.
Any thoughts and precise examples of how zapata.conf or (zapata.conf.zapscan (or both) (or none) is built would be appreciated.