Topic: What are the contexts available in SARK-SAIL 3.1.0 ?

[apmuthu]

SAIL-3.1.0-100

Code: [Select]

context=internal
;context=from-pstnAny other contexts for use?
By default, atleast one day/night timer should be in SAIL fresh install.

What is the purpose of the Analog-In trunk?

Using a SoundWin as a GenericSIP Trunk for it's FXO port and setting the peer and user stanzas, we are unable to get inbound calls from it reaching the mainmenu (from-pstn context).

[SARK devs]

You can see the contexts it uses in extensions.conf.   It doesn't use many.  All of the extensions are in [extensions] while inbound and outbound are processed through [mainmenu] and [internal].  It also has aliases for the freepbx contexts (e.g. from-pstn, from-trunk and so on) and it has special contexts for PIKA (fxo, digital).  You can create your own contexts with custom-apps and sail will stitch them into the call path for you. It gets more complex if you elect to use tenants but the form is much the same.

By default, atleast one day/night timer should be in SAIL fresh install.

Can you tell us more?  Why do want a default timer?

Code: [Select]

What is the purpose of the Analog-In trunk?To route inbound calls that arrive in the from-pstn context (essentially, analogue inbound on a Digium type FXO channel).

SoundWin as a GenericSIP Trunk for it's FXO port...

 
I have not heard of SoundWin but I assume it is an ATA.  As a SIP device,  it should normally be set up to send in a DNID through the mainmenu context. If it is set to register with Asterisk (i.e. host=dynamic) then it should specify a context of mainmenu in the peer entry.  Also, although we haven't tried it, you may be able to just send it in through [from-pstn] context by explicitly specifying that context in the peer entry.
 
KInd Regards

S


 

[apmuthu]

Yes, thanks - I had used the extensions.conf to study the existing contexts and how they are stitched in - I just thought there was a good Wiki Entry on using them - now that the Carriers panel is missing in SAIL v3 - atleast a small subset of the monster of v2 should have been left back.

A default timer is good to have since we have Open and Closed routing available for the IVR / Trunklines pages.

Even if we delete the Analog-In trunkline, it's entry in the extensions.conf still remains. If it is important, then it should not be deletable.

The peer entry is for outgoing calls I thought. How would the from-trunk context be useful in the peer stanza? Should it not be in the user stanza?

Can the peer and user stanzas have the same name?

[SARK devs]

OK - lot of questions here...

now that the Carriers panel is missing in SAIL v3

Not missing - removed.  99% of all sip carrier trunks can be handled witha single definition.  Those few that can't can be manually updated in the peer and user entries so no need for it.

default timer is good to have since we have Open and Closed routing available for the IVR / Trunklines pages.

Not sure we understand - what would the default times be?

Even if we delete the Analog-In trunkline, it's entry in the extensions.conf still remains. If it is important, then it should not be deletable.

Agreed - we will fix.
If you do delete it accidentally then run /opt/sark/scripts/update_db.sh
It will fix it.

How would the from-trunk context be useful in the peer stanza?

We don't use context 'from_trunk', it exists purely for Fpbx compatibility and I think they use it to process inbound Voip traffic so you could use it where we use mainmenu. In SAIL, it anyway aliases our mainmenu inbound context.     
In general, for SIP trunks you should not need to put anything in the user entry.

Can the peer and user stanzas have the same name?

You would need to ask Digium.  I would avoid it if possible or use a friend stanza instead.

Kind Regards

S

[apmuthu]

Default Closed Time could be entire Sunday for a start. If the logic of having no timers chooses not to traverse the timer decision tree, then it may not be necessary.

If we only send out traffic thru a SIP trunk then a peer stanza would suffice, but the absence of a user stanza generates warnings in the asterisk logs with an autogenerated user-stanza-name. The mainmenu doesn't seem to cut it in v3.1.x as yet. There seems to be no feature code to simulate an incoming trunk to access from the extensions side - 7777 does it for Elastix. Had to create a dummy Call Group with a fall-through to an IVR (currently restricted to 1 digit only with no facility for dialling an extension number).

If we are only receiving calls from a SIP trunk (aka IPKall.com) then we would need only the user entry and not the peer entry - is that correct? Or are there any entries in the peer that need to be retained?

Earlier versions of SAIL had carrier provisioning for same peer and user name for a carrier instance.

Awaiting your new release with updated tool-tips, ability to manage the SQLite dbs, and clarity in tool-tips for carrier types.

[SARK devs]

hello

Default Closed Time could be entire Sunday for a start. If the logic of having no timers chooses not to traverse the timer decision tree, then it may not be necessary.

Sorry;  I don't know what you mean.  Are you talking about GoToIfTime type cascades a la FreePBX?  SARK doesn't work that way.

f we only send out traffic thru a SIP trunk then a peer stanza would suffice, but the absence of a user stanza generates warnings in the asterisk logs with an autogenerated user-stanza-name.

What error does it generate? 

Peer & User stanzas aren't strictly inbound and outbound paths (although they are often explained that way).     The user entry is only used to validate UA's which want to register with us (which is never a carrier).   Control of the call is always achieved through the peer entry.  For IPKall, which only ever sends in calls, the host entry is unnecessary but still nice to include for clear documentation.  So - yor IPKall stanza might end up something like...

Code: [Select]

type=peer
host=66.54.140.46
qualify=yes
deny=0.0.0.0/0.0.0.0
permit=66.54.140.46/255.255.255.255
permit=66.54.140.47/255.255.255.255
disallow=all
allow=alaw
allow=ulaw   
To test the permissions, if you comment out the two permits then you should no longer receive calls from IPKall. 

Kind Regards

S

[apmuthu]

Thanks a lot.

A GeneralSIP Trunk was created and given a name (IPKall) and the the peer entry was made (named the phone number itself) as you stated. No user entry was made. The call came thru' but the callerid stated Private Number since the US number was called from overseas to test it and possibly the telco may have been using a grey route.

Incidentally the other carrier Trunk types have errors for example:
PTT_CLID type has no form field for the label: Display Name

[SARK devs]

PTT_CLID type has no form field for the label: Display Name

Thankyou - I'll look at it

Kind Regards

S

[apmuthu]

A call that came in thru' Vonage into the IPKall number showed up as a SIP name: "Olympia        W" instead of their callerid. What settings are necessary to obtain the CallerID correctly - on the incoming call from IPKall?

A Custom Trunkline does not have any peer / user stanza textarea.