Some notes i took 2/16/2015
NS_CLI/SubscriberMgmt> ?
The Subscriber Management (SubscriberMgmt) level allows display, addition,
modification, and/or deletion of attributes related to administrators,
enterprises, and users.
Commands:
0) Administrator : go to level Administrator
1) DefaultSourceID : go to level DefaultSourceID
2) Devices : go to level Devices
3) Enterprise : go to level Enterprise
NS_CLI/SubscriberMgmt/Enterprise> ?
The Network Server uses the concept of an enterprise as a way to collect and
organize users who share the same provisioning and routing
characteristics.Private routing policies are assigned to enterprises using this
level. Enterprises can be assigned routing profiles to process public calls as
well as policies to process private calls. User groups allow for a further
defining of an enterprise by breaking it down into smaller groups to which
specific phone numbers and URLs can be assigned. It is also possible to
provision a routing profile for a specific user group. The public policies used
during call processing are derived from the user group's profile first and then
from the enterprise's profile. A combination of both profiles is used and
priority is given to the user group's profile.
NS_CLI/SubscriberMgmt/Enterprise/Site> ?
This level is used to view, add, modify, and delete sites specific to an
enterprise.
4) IMRN : go to level IMRN
5) MaxFailedLoginAttempts : go to level MaxFailedLoginAttempts
6) MinLoginIdLength : go to level MinLoginIdLength
7) NetworkTranslationIndex : go to level NetworkTranslationIndex
8) Numbers : go to level Numbers
9) PasswordRules : go to level PasswordRules
NS_CLI/System/CallP> ?
Configuration on the Network Server for call processing involves translations,
SIP error code treatments, call type definitions, country and national
destination codes, and dial plans. From this level, all call processing
information can be viewed and specified.
Commands:
0) CallTypes : go to level CallTypes
1) CountryCodes : go to level CountryCodes
2) DMI : go to level DMI (Digit Manipulation like REPL)
3) Options : go to level Options
4) PolicyPrecedence : go to level PolicyPrecedence
5) Translation : go to level Translation (LCA and NNACL)
6) Treatment : go to level Treatment
NS_CLI/Policy> ?
The Policy level allows you to configure routing policies and profiles.
Routing policies can be defined as having instances that are a variation of the
policy. Instances are assigned to routing profiles, and profiles are then
associated with enterprises and user groups to instruct the Network Server on
the routing rules for that enterprise or user group.
Commands:
0) CallScreening : go to level CallScreening
1) CallTyping : go to level CallTyping
2) DstSvcRtg : go to level DstSvcRtg
3) EASvcCallRtg : go to level EASvcCallRtg
4) EqualAccess : go to level EqualAccess
5) FarEndRtg : go to level FarEndRtg
6) MediaSrvSel : go to level MediaSrvSel
7) MobileNumberRtg : go to level MobileNumberRtg
8) NearEndRtg : go to level NearEndRtg
9) NumberPortability : go to level NumberPortability
10) OrigRedirect : go to level OrigRedirect
11) PhysLocation : go to level PhysLocation
12) PreCallTyping : go to level PreCallTyping
13) Profile : go to level Profile
The Network Server processes routing rules according to the call type and the
policy instance assigned to the profile for that enterprise or user group. The
following describes policies, policy instances, and profiles.Policies.
- Routing services are implemented through policies (for example, SubLocation, or
Equal Access.). Routing policies specify the routing logic. To implement
different routing applications with similar routing logic, a routing policy
will have different instances.Policy Instances.
- For some policies (for example, Call Screening), a variation can be defined
which has the major properties of the policy but some different attributes.
Not all policies, however, can have multiple instances.Profiles.
- A profile is the assignment of policy instances to enterprises and user groups.
A profile consists of one or more instances of different policies. Once a
profile is defined, it may be assigned too many enterprises and user groups.
Each enterprise and user group can only have one profile. An enterprise must
have a profile, but profiles can also be assigned at the user group level. If
a profile exists for both a user group and its enterprise, the user group
profile has precedence. A system-wide default profile also can be defined. If
a caller is unknown, the default profile is used.
14) RCBasedRtg : go to level RCBasedRtg
15) ReverseTranslation : go to level ReverseTranslation
16) SIMPLE : go to level SIMPLE
17) SMSDefaultRtg : go to level SMSDefaultRtg
18) SMSNearEndRtg : go to level SMSNearEndRtg
19) SubLocation : go to level SubLocation
20) SvcCtrRtg : go to level SvcCtrRtg
The Service Center Routing policy (SvcCtrRtg) is an origination-based routing
policy. It allows a Network Server administrator to route incoming calls to
specific destinations based on the call originator and on the Network
Server-identified call type. This policy uses service routing entries to map
incoming call types and originator defined by a range of valid digits to a
destination. It provides support for three types of routing results:Fully
specified directory number destination (meaning, 11 digits for North America
E.164 compliant number)Network gatewaysNetwork gateway controllers along with a
destination trunk groupIf a phone or directory number is first obtained from
the search in the service routing list, it replaces the service number as the
call destination. The call will thereafter be routed using Network Server
public routing policies.If gateways and/or gateway controllers are obtained
from the search in the service routing list, they are be added as contacts in
the SIP 302 response. The call is then routed as is and does not go through
other policies.If a trunk group is obtained from the search in the service
routing list, a valid BroadWorks contact is added in the SIP 302 response. The
user part of the contact contains the address trunkgroup@mgcpGateway (in
escaped form) and the host part contains an Application Server acting as a
gateway controller. The call is then routed as is and does not go through
other policies.For the Service Center Routing policy, a service center routing
list is entered to determine how calls are handled.
NS_CLI/Policy/SvcCtrRtg/SCRL> ?
This level allows for display, addition, modification, and deletion of service
center routing list (SCRL) attributes associated with the Service Center
Routing policy.
21) TandemOverflow : go to level TandemOverflow
22) TgrpTerm : go to level TgrpTerm
23) TrunkGroupTransl : go to level TrunkGroupTransl
24) UrlDialing : go to level UrlDialing
25) XSLocation : go to level XSLocation
Monday, February 16, 2015
Asterisk 11.15.0 Voicemail Setup
Setting up Voicemail in Asterisk
11.15.0
Edit your /etc/asterisk/voicemail.conf file. After the [general] and [zonemessages] sections, any
other bracketed section is a voice mail context. Within each context, you can
define one or more mailbox. To define a mailbox, we set a mailbox number, a
PIN, the mailbox owner's name, the primary email address, a secondary email
address, and a list of mailbox options (separated by the pipe character), as
shown below:
[context]mailbox=>pin,full name,email
address,short email address,mailbox options
By way of explanation, the short email address is an email
address that will receive shorter email notifications suitable for mobile
devices such as cell phones and pagers. It will never receive attachments, even
if attach=yes. If you don’t want to use the email, or short, email address just
put nothing in it. Be sure to use the comma though for a place holder.
An example of this I use in my lab is:
[internal]
6026356915 => 9999, Glen
whittenberg,glen.whittenberg@cableone.biz,,attach=yes|maxmsg=100
My context is internal and extension is 6026356915 as
defined in my sip.conf and extensions.conf files. 9999 will be my password.
Glen Whittenberg is my full name. glen.whittenberg@cableone.biz
is my email address. I am not using a short email addr so I just put in the
comma. My options, separated by pipe symbol, are voicemail attachments will be
sent to email, attach=yes, and maximum messages will be 100, maxmsg=100.
Now let’s edit the /etc/asterisk/extensions.conf file. We
will add 9999 to get to voicemal system and also add to our extensions, and
DID’s, to enable voicemail for them.
To make 9999 your access number to the voicemail system add
the flowing under the [internal] context:
;used 9999 to access voicemail
exten => 9999,1,Answer(500)
exten => 9999,n,VoiceMailMain(@internal)
Now for my extension of 6026356915 I added the following,
still in my [internal] context:
exten => 100,n,VoiceMail(6026356915@internal,u)
My entire entry so far for this extensions is:
;used to pass extension dialed, 100, to registered phone of 6026356915
exten => 100,1,Dial(SIP/6026356915,20)
exten => 100,n,VoiceMail(6026356915@internal,u)
exten => 100,n,Playback(vm-goodbye)
exten => 100,n,Hangup
You can see I am using 100 to associate to 6026356915. This
allows me to dial 100 from inside the system instead the entire 6026356915
number to call this phone/extension.
Now we need to edit our context concerning outside calls
into the system. So when an outside caller calls my DID of 6026356915 they can
also leave a voice message.
Again edit the /etc/asterisk/extensions.conf file under the
correct context for inbound calls. In my case this context is called [from-test].
This was defined in my /etc/asterisk/dahdi-channels.conf file. Add the
following for the DID 6026356915.
exten => 6026356915,n,VoiceMail(6026356915@internal,u)
My entire entry under the [from-test] context for DID 6026356915
is:
exten => 6026356915,1,Dial(SIP/6026356915,20)
exten => 6026356915,n,VoiceMail(6026356915@internal,u)
exten => 6026356915,n,Playback(vm-goodbye)
exten => 6026356915,n,Hangup
Now reload voicemail and extensions in asterisk with:
# asterisk –x ‘core reload’
Enjoy!
Adtran 908e 2nd Gen Dual PRI Failover Issue
908e 2nd Gen Dual PRI Failover Issue
In testing the 908e 2nd Gen I discovered a problem with the ability to route inbound calls to the second PRI when the first one was unplugged. If you did a shutdown ("admin down") on the T1 for that PRI it would send the calls to the second one. If you just unplugged the cable and it became "DOWN", inbound calls would not complete.
Support articles showed possible problems
with the A2.X release of the AOS. I opened a ticket with Adtran support
to discuss further. It was confirmed that the A2.x release had a problem
with how it handled this. there is a work around for this, but the A2.x
version is no longer supported by Adtran. The suggested fix was to
leave the config the same as I had it and upgrade AOS to R10.9.5. After
the upgrade, and reboot, the testing completed successfully. Now when I
unplugged the cable from PRI 1 inbound calls got sent to PRI 2.
The AOS file I used is labeled for the 900e 2nd Gen series, not the 900 series.
AOS version used in upgrade is R10.9.5:
https://www.adtran.com/web/page/portal/Adtran/wp_support_productdownloads_landin
Document for this upgrade:
https://supportforums.adtran.com/docs/DOC-1672
This AOS release allows for a single SIP trunk, Two T1's/PRI's, and single ISDN-group with both PRI's in the group. Example:
interface t1 0/3
description T1 to PBX
lbo long -7.5
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 0/4
description T1 to Vanna PBX
lbo long -7.5
tdm-group 1 timeslots 1-24 speed 64
no shutdown
description T1 to PBX
lbo long -7.5
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 0/4
description T1 to Vanna PBX
lbo long -7.5
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface pri 1
description PRI to PBX
role network b-channel-restarts enable
isdn name-delivery setup
connect t1 0/3 tdm-group 1
no shutdown
!
description PRI to PBX
role network b-channel-restarts enable
isdn name-delivery setup
connect t1 0/3 tdm-group 1
no shutdown
!
!
interface pri 3
description PRI to Vanna PBX
role network b-channel-restarts enable
isdn name-delivery setup
connect t1 0/4 tdm-group 1
no shutdown
!
isdn-group 1interface pri 3
description PRI to Vanna PBX
role network b-channel-restarts enable
isdn name-delivery setup
connect t1 0/4 tdm-group 1
no shutdown
!
connect pri 1
connect pri 3
!
!
voice trunk T01 type sip
description "SIP-Trunk"
sip-server primary xxx.cableone.net
registrar primary xxx.cableone.net
outbound-proxy primary x.x.x.x
domain "xxx.cableone.net"
sip-keep-alive options 3600
register 6026000000
register 6026000001
authentication username "xxx" password "xxx"
!
voice trunk T02 type isdn
description "PRI-Trunk"
resource-selection circular descending
connect isdn-group 1
rtp delay-mode adaptive
!
!
voice grouped-trunk SIP
trunk T01
accept $ cost 0
!
!
voice grouped-trunk ISDN
trunk T02
accept $ cost 0
Adtran 908e GEN3 in getting Spoofing messages when trying to access from outside the Adtran local network
Issue with Adtran 908e GEN3 in getting Spoofing messages when trying to access from outside the Adtran local network.
This also prevented any access to the Adtran from outside the Adtran local network.
It appears that in the GEN3 we have to use “ip
routing”. Adtran support said it will not work without it, even though
we have been using the 908 GEN2 and 908e GEN2 Adtran without “ip routing”. So use it we will .
It is a very simple procedure. After you get the config loaded on the Adtran, which was generated with Sigma, make the following changes.
To turn on ip routing:
(config)#ip routing
Now set a default route:
ip route <ip address> <subnet mask> <interface>
Example: (config)#ip route 0.0.0.0 0.0.0.0 10.10.10.1
The example above is just that. You need to substitute 10.10.10.1 with your correct gateway route out.
That’s it. Now if your “ip access-list” and “ip policy-class” are correct, and correctly assigned to your Ethernet interface, you should have access to the Adtran from outside the Adtran local network.
This has been tested on 908 GEN2 A4.11.00. Also on 908e GEN2 using AOS A4.11, and GEN3 using R10.9.4.
Adtran zero-touch and auto-config
zero-touch and auto-config
The zero-touch feature is
not supported on all AOS platforms. On
the units that support auto-config zero-touch, TFTP is the method to obtain the
configuration. Typically, if HTTP is
needed for the configuration, instead of the user erasing the configuration,
they will enter the HTTP commands instead.
On page 13, #5, in the
“Using Auto-Config in AOS guide”, it explains:
5. If the configuration
file is successfully received, Auto-Config proceeds to apply the configuration
file to the unit¿s running configuration. Applying the configuration file
affects the running configuration only, not the startup configuration file. To
store the running configuration as the startup configuration after Auto-Config
is complete, make certain the last command of the downloaded file is do write.
The configuration server
is a network server or another AOS device that provides the configuration files
necessary to complete Auto-Config. Locating the server is accomplished by
entering the static IPv4
Adtran 908e GEN3 R10.9.5 timing-source
Adtran 908e GEN3 R10.9.5 timing-source
The
timing-source on this IAD is default set to internal. We discovered
that “show run verbose” does not show this default setting. If you
change this default it will appear in “show run” and “show run verbose”.
The default setting of internal is what we need to have set, as the clients BCM will clock to us.
To set timing-source to internal:
(config)#timing-source internal
Subscribe to:
Posts (Atom)