- Log in to your Mitel MiAccess account and go to the Licensing application (https://sls.mitel.com/sls/index.xhtml)
- Search and navigate to the company you need to generate a new key for.
- Click on the Select view license button
- Click on Validate SLR
- Upload you SLR license file
- Click on the Check mark button to apply the SLR file and generate a system key
- The new system key should be emailed to you.
Welcome to my knowledge base blog, an IT technical blog about configurations and topics other topics related to Networking, VOIP and other aspects of IT. I hope this blog serves you well.
Monday, May 18, 2020
ShoreTel:System Key Generation
Here are the steps on how to generate a new system key from the Mitel SLS portal. (The screen shots below are taken from a Mitel license PDF)
Labels:
ShoreTel
Tuesday, October 22, 2019
ShoreTel/MiTel: How to Migrate MiVoice Connect to a new Server
I have tried to move a few Connect systems from one piece of hardware/OS to another by doing a backup/restore and it has always ended in disaster. There were always issues with CAS, or certs, or the client not connecting, that I ended up just telling customers it was better to build the system all over again on the new hardware and then cut over to it. Yes users would loose call history, voice mail, client settings extra but as I was not able to do it any other way and TAC was no help this was the best way to go.
With that being said, I did have a customer that had a UC 20 server running Server 2012 that had a bad HDD and needed to be replace. So we replaced with a UC 30 running Server 2016. I decided that this was a good time to try and see if I could make the migration work doing a export of the old server and the import of the new server. I was pleasantly surprised when i was able to get the import and everything working. So here are the steps that I took to make this happen.
The steps below assume that you have already installed all the server roles needed, and made the OS changes that Connect requires.
Also:
With that being said, I did have a customer that had a UC 20 server running Server 2012 that had a bad HDD and needed to be replace. So we replaced with a UC 30 running Server 2016. I decided that this was a good time to try and see if I could make the migration work doing a export of the old server and the import of the new server. I was pleasantly surprised when i was able to get the import and everything working. So here are the steps that I took to make this happen.
The steps below assume that you have already installed all the server roles needed, and made the OS changes that Connect requires.
Also:
- This will change the server certificate for web services (Director,CAS)
- If you are using "Require secure client access" make sure to turn it off from Administration=>System=>Additional Parameters
- If you are using a 3rd party certificate, make sure you have the certificate and private key
- Make sure to install all pre-requisites and prep the server according to the Build notes and the Planning and Install guide
- Use the TACTOOLS power shell script to verify all roles and features are installed
On the Old Server
- Back up System
- Navigate to C:\Program Files (x86)\Shoreline Communications\Shoreware Server\MySQL\MySQL Server 5.0\Examples and run the following file
- BackupCDR.bat -> Will output an .sql file to the root of C:
- BackupConfig.bat -> Will output an .sql file to the root of C:
- BackupWebridge.bat -> Will output an .sql file to the root of C:
- Only required if there is an SA-100/SA-400 in use.
- BackupMonitoring.bat-> Will output an .sql file to the root of C:
- Only required for ShoreTel 14.x
- Copy the resulting .sql files folder to a safe location (Network Share, Thumb drive, etc...)
- Stop all ST services from script at C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-stop-svcs (make sure to run as administrator)
- Reboot the server
- Copy the Shoreline Data folder to a safe location (Network Share, Thumb drive, etc...)
- If the server is added to the active directory domain, delete the computer account from active director (Roll back from this is hard)
- Shutdown the server or Disconnect it from the network
On the New Server
- Make sure the new server has the same Name as the old server
- Make sure the new server has the same IP address as the old server
- Make sure the new server does not have any Anti-Virus
- Add it to the domain if it is needed
- Make sure there are not Group policies assigned to the server
- Create a BLANK Shoreline Data folder and copy the keystore directory from the back up of the old server into the folder
- Re-install the same EXACT version and build that was installed on the old server
- Copy the database back up files to the root of the C drive
- Restore all the databases with the restore.bat files located in the \Program Files\Shoreline Communications\Shoreware Server\My SQL\MySQL Server 5.0\Examples or \Program Files (x86)\Shoreline Communications\Shoreware Server\My SQL\MySQL Server 5.0\Examples
- Reboot the server
- After the reboot, log into the server to verify that switches and phones are connected to the new server
- Stop all ShoreTel services
- C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-stop-svcs (make sure to run as administrator)
- Copy the UserData, Prompts, IMArchives and VMS folders from the back up of the old server to the new server
- Re import your 3rd party certificate through Director (if you have one)
- Test the system thoroughly to ensure all system functionality is working properly
- Workgroups
- Route Points
- Connect Client
- Voicemail
- Auto Attendants
- Call Handling Mode Changes
- Extension to extension dialing
- External dialing
- Dialing in to Workgroups, hunt groups, auto attendants
- Phone time
- Conferencing
- Instant messaging
- Call history
- Mobility
- ECT
- Request new system key
Labels:
ShoreTel
Monday, October 21, 2019
ShoreTel/MiTel: Auto Attendant at remote site with ShoreTel SG90V Switch not playing greeting
I ran into a issue just recently where I migrated a customer from a 2008 R2 server to a 2016 server and instead of doing a back up restore I configured the system from scratch. So it essentially is a new system running but with the same hardware and all the hardware had download the new configurations. The issue we ran into is that a remote site with a singe SG90V switch with external analog trunks would not play the auto attendant recording when some one would call in. It would just play the default ShoreTel back up auto attendant recording, no matter how we tried to route the call to the correct auto attendant.
We tried routing the call to a user and forwarding to the AA, we tried sending it to a route point and then the AA, we tried all sorts of things to try and make this work. The auto attendant was reachable if you called it internally, it was reachable if you called it externally at the HQ site, but the site it was supposed to work at could not get the AA to play. There were no communications issues, TMS was connected, LSP worked between the equipment everything seemed to be configured correctly.
It turns out that the customer uses Office 365 for voice mail to email, and the ShoreTel SMTP relay was configured to use port 587, it was using TLS, and had a smart-host configured as well as a user account to authenticate to Office 365 with. ShoreTel uses SMTP port 25 to transfer AA greetings to V switches, and because the customer was using SMTP on 587 for Office 365 the recording could not be transferred to the V switch.
So to test we set the SMTP port to 25, removed TLS, and the user account, re-imported the greeting to the AA and tested. We were able to get the AA to play once this took place, but it broke their voice mail to email. This aspect is very important to them so we reverted the changes, but because the V switch already had the AA greeting saved the AA continued to work. The issue is going to be when they want to change the greeting we will have to either find a different work around or we will have to record the greeting, break voice mail to email re-import the greeting and then reconfigure voice mail to email.
As soon as i have more information about a possible work around or resolution to this i will update this post.
We tried routing the call to a user and forwarding to the AA, we tried sending it to a route point and then the AA, we tried all sorts of things to try and make this work. The auto attendant was reachable if you called it internally, it was reachable if you called it externally at the HQ site, but the site it was supposed to work at could not get the AA to play. There were no communications issues, TMS was connected, LSP worked between the equipment everything seemed to be configured correctly.
It turns out that the customer uses Office 365 for voice mail to email, and the ShoreTel SMTP relay was configured to use port 587, it was using TLS, and had a smart-host configured as well as a user account to authenticate to Office 365 with. ShoreTel uses SMTP port 25 to transfer AA greetings to V switches, and because the customer was using SMTP on 587 for Office 365 the recording could not be transferred to the V switch.
So to test we set the SMTP port to 25, removed TLS, and the user account, re-imported the greeting to the AA and tested. We were able to get the AA to play once this took place, but it broke their voice mail to email. This aspect is very important to them so we reverted the changes, but because the V switch already had the AA greeting saved the AA continued to work. The issue is going to be when they want to change the greeting we will have to either find a different work around or we will have to record the greeting, break voice mail to email re-import the greeting and then reconfigure voice mail to email.
As soon as i have more information about a possible work around or resolution to this i will update this post.
Labels:
ShoreTel
Friday, August 2, 2019
ShoreTel: How to configure a ShoreTel IP400 series VPN phone and EGW user
Here are some step by step instructions on how to configure a ShoreTel IP 400 Series phone to use with an Edge Gateway. When setting up a VPN phone for a user I always connect the phone to the network at HQ or a remote site first so that the phone can register with the server, download any firmware and config files, ect, before configuring as a VPN phone. I know you are supposed to be able to just configure it and it should just work but I have not had much success with that working.
- Connect the ShoreTel phone (IP400) that the user will be using to the local phone network to make sure it gets the latest config and firmware update
- On the back of the ShoreTel phone write down the MAC address
- Log in to ShoreWare Director
- Go to Administration => Users => Users
- Find the user you would like to configure to use a Remote phone
- Click on the telephony tab
- Place a check mark next to Enable remote phone authentication
- Click Save
- Navigate to Administration => Appliance/Servers => Platform Equipment
- Find the Edge Gateway under the name column and click on it (The name should have a line under it making it a hyperlink)
- The Edge Gateway web page should open
- The default login is admin and ShoreTel
- Click Configuration from the top of the page
- Click on Phones from the left navigation panel
- Click the Allowed List link
- At the bottom of the page click the Add button
- In the MAC address box put the MAC address of the phone you are going to use
- i.e. 00:10:49:00:00:00
- In the Phone Name box enter a name ( A description, I usually enter the phone model)
- In the User ID box enter the Extension number of the user that will be using that phone
- Click apply
- With the phone on hook, press the MUTE button followed by 4636# (INFO#)
- Enter the Admin password 1234# (If asked)
- Press the down arrow key until you reach Diagnostic and then press Open button (Button under screen on left side)
- Press the down arrow key until you reach clear configuration and then press Open
- Press the Clear button
- The phone will reboot
- Watch the phone screen and when you see the phone ask you to press any key for set up press the # key
- You will be asked for a password enter 1234#
- Press the down arrow key until you reach the VPN and then press Open
- Set Use VPN to “ON” by pressing the Toggle soft key
- Press the down arrow to select VPN Gateway
- Set the VPN Gateway value to the public IP or FQDN of your Edge Gateway (By using the keypad numbers and the * key )
- Press the Back button (Button under the screen on the right side)
- Press the Apply button (Button under the screen on the right side)
- The phone will reboot
- User experience may very a little bit after this point as not all systems act the same
- The phone will say Connecting to VPN (sits here for a bit)
- The phone will say Unable to connect to VPN (sits here for a bit)
- The phone will say Server certificate could not be verified press the OK button (Button under the screen on the right side)
- The phone will say Connecting (sits for bit)
- The phone will say Requesting Service (for a bit)
- The phone will say Available or your user info
This is a licensed based usage so make sure you have Remote Phone licenses available to use or get some if you do not. If you don't have the license you can still configure this but if you don't remove it within the 45 day trial period your ShoreTel system will be locked and you wont be able to make any changes to it. You will need to buy the licenses you are over and apply them to the system to unlock it or have ShoreTel unlock you system and this comes with a fee.
Labels:
ShoreTel
Wednesday, July 17, 2019
SIP: P-Asserted-Identity SIP Header mondification
ShoreTel/Mitel allows users to move their extension from one location to another as long as they are configured on the ShoreTel/Mitel system. This not only gives the users the ability to travel between sites with the same extension but also the same DID and Caller ID. This is a really cool feature but it also can create a issue with making cretin calls.
For example you have two sites, we will call them Site A and Site B, and each site has their own external SIP trunks for outbound dialing. We have a user name Jeremy, Jeremy usually works from Site B, and that is also where his DID resides on Sites B SIP trunks. Today Jeremy needs to go to Site A for the day to work. Once there he logs in to a phone and is able to make local and long distance calls like normal going out the Site A SIP trunks with his caller ID even though it does not belong to the Site A SIP trunks. He needs to dial a 800 number to join conference bridge but the call is unable to connect.
This issue is something I have run into a lot. This call is being blocked by the carrier because the caller ID does not match any of the caller ID's that resides on those external trunks. There are a lot of hacks out there that allow people to spoof calls to dial 800 numbers and this is know as toll fraud. One way the carriers combat this is only allowing caller IDs that reside on that circuit to make 800 number calls. There are a number of ways to resolve this by modifying the SIP header to include the Billing Telephone Number (BTN) of that circuit. The way I have resolved it is by configuring P-Asserted-Identity (PAI) on the Ingate SIParator.
The way to do this is, on the SIP Trunk group page in the SIParator, you need to modify the User Name in the Outgoing Calls under the PBX Lines. It normally just has a $1 in the User Name field to pass through the caller ID that it is being presented with from the PBX.
We need to modify it so that it adds the sites BTN to it also. So to do that you would enter in something like this in to the User Name field.
$1?P-Asserted-Identity=%3csip%3a2625555555%401.1.2.1%3e
The green highlight of the line above enables PAI in the SIP header, the blue highlight is the BTN to use and the purple highlight is the IP address of the carrier device. Below is what it looks like when it is in the SIParator.
Now, when Jeremy makes a 800 number call from Site A the carrier accepts the call as he is presenting them with the BTN for authentication that he is allowed to use the circuit, as well as his caller ID even though it does not belong to that circuit.
There are a lot of ways to do this, but this is the way that I have found that works best for most of the deployments I am involved in
For example you have two sites, we will call them Site A and Site B, and each site has their own external SIP trunks for outbound dialing. We have a user name Jeremy, Jeremy usually works from Site B, and that is also where his DID resides on Sites B SIP trunks. Today Jeremy needs to go to Site A for the day to work. Once there he logs in to a phone and is able to make local and long distance calls like normal going out the Site A SIP trunks with his caller ID even though it does not belong to the Site A SIP trunks. He needs to dial a 800 number to join conference bridge but the call is unable to connect.
This issue is something I have run into a lot. This call is being blocked by the carrier because the caller ID does not match any of the caller ID's that resides on those external trunks. There are a lot of hacks out there that allow people to spoof calls to dial 800 numbers and this is know as toll fraud. One way the carriers combat this is only allowing caller IDs that reside on that circuit to make 800 number calls. There are a number of ways to resolve this by modifying the SIP header to include the Billing Telephone Number (BTN) of that circuit. The way I have resolved it is by configuring P-Asserted-Identity (PAI) on the Ingate SIParator.
The way to do this is, on the SIP Trunk group page in the SIParator, you need to modify the User Name in the Outgoing Calls under the PBX Lines. It normally just has a $1 in the User Name field to pass through the caller ID that it is being presented with from the PBX.
We need to modify it so that it adds the sites BTN to it also. So to do that you would enter in something like this in to the User Name field.
$1?P-Asserted-Identity=%3csip%3a2625555555%401.1.2.1%3e
The green highlight of the line above enables PAI in the SIP header, the blue highlight is the BTN to use and the purple highlight is the IP address of the carrier device. Below is what it looks like when it is in the SIParator.
Now, when Jeremy makes a 800 number call from Site A the carrier accepts the call as he is presenting them with the BTN for authentication that he is allowed to use the circuit, as well as his caller ID even though it does not belong to that circuit.
There are a lot of ways to do this, but this is the way that I have found that works best for most of the deployments I am involved in
Labels:
SIP
Cisco: Track default route when Outside IP address is assigned VIA DHCP
Sometimes you need to to apply a tracking statement to a route so that if a cretin condition is met that route gets removed. In this case I needed to have the default route fail over to a second internet connection if the primary internet went down. Except, we receive a DHCP IP address on the primary connection so I can not just track reach ability to the next hop as that IP address changes. So here is a way to do tracking statements with a DHCP default route. We just set the default route to the interface instead of a IP address.
track 1 ip sla 10 reachability
delay down 30 up 30 (This makes it so that when there is a failure on the IP SLA it waits 30 seconds to make the change, this is so that it doesn't flap up/down)
ip sla auto discovery
ip sla 10
icmp-echo 8.8.4.4 source-interface GigabitEthernet0/1
tag Ping Google
threshold 1000
timeout 2000
frequency 3
ip sla schedule 10 life forever start-time now
(The above section is where you configure an IP address that you want to monitor, the router will send out a ping packet to that IP address to determine readability up/down)
interface GigabitEthernet0/1
ip dhcp client default-router distance 1
ip dhcp client route track 1
ip route 8.8.8.8 255.255.255.255 GigabitEthernet0/1 (Always forces this traffic out this interface so we dont end up sending over the backup)
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1 track 1 (Primary internet connection default route with a tracking statement)
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2 200 (Back up internet connection default route)
Labels:
Cisco
Cisco: DMVPN commands and configuration
DMVPN debugs
Debugs on both sides at the same time:
Debug crypto condition peer ipv4 (public ip of peer)
Debug crypto isakmp
Debug crypto ipsec
Clear DMVPN session and Crypto
Interface tunnel0
Shut
Clear dmvpn sesssion interface tunnel0
Clear crypto isa
DMVPN Sample Scripts
These scripts assume that you have the router base configuration already done. They just give you some of the base info to create a DMVPN configuration and are not anything more than base. For the ACL on the inbound interface the script has "any any" on it but should be locked down to the remote IP address of the other spokes and hub.DMVPN HUB Sample Script
crypto keyring dmvpnspokesdescription For DMVPN Tunnel
pre-shared-key address 0.0.0.0 0.0.0.0 key "PRE_SHARED_KEY" (This should be a strong key)
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
hash md5
crypto isakmp profile DMVPNIsakmpProfile
keyring dmvpnspokes
match identity address 0.0.0.0
crypto ipsec transform-set ESP-AES-MD5 esp-aes 256 esp-md5-hmac
mode transport
crypto ipsec profile DMVPNIpsecProfile
set transform-set dmvpn-aes-sha
set isakmp-profile DMVPNIsakmpProfile
interface Tunnel0
description DMVPN_HUB
ip address "IP_ADDRESS" 255.255.255.255
ip mtu 1400
ip nhrp authentication "NHRP_PASSWORD"(This password is configured all Tunnel interfaces i.e.)
ip nhrp map multicast dynamic
ip nhrp network-id "NETWORK_ID"(i.e. 10010100)
ip nhrp holdtime 600
ip nhrp shortcut
ip nhrp redirect
ip tcp adjust-mss 1360
load-interval 30
no shutdown
qos pre-classify
tunnel source "INTERFACE"(Interface that will be making the DMVPN Connection)
tunnel mode gre multipoint
tunnel key "KEY"(i.e 10010100)
tunnel protection ipsec profile DMVPNIpsecProfile
ip access-list extended inbound
permit gre any any
permit icmp any any
permit udp any any eq isakmp
permit udp any eq isakmp any
permit udp any any eq non500-isakmp
permit esp any any
permit tcp any any established
DMVPN Spoke Script
crypto keyring dmvpnspokesdescription For DMVPN Tunnel
pre-shared-key address 0.0.0.0 0.0.0.0 key "PRE_SHARED_KEY" (This should be a strong key)
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
hash md5
crypto isakmp profile DMVPNIsakmpProfile
keyring dmvpnspokes
match identity address 0.0.0.0
crypto ipsec transform-set ESP-AES-MD5 esp-aes 256 esp-md5-hmac
mode transport
crypto ipsec profile DMVPNIpsecProfile
set transform-set dmvpn-aes-sha
set isakmp-profile DMVPNIsakmpProfile
interface Tunnel0
description DMVPN_SPOKE
ip address "IP_ADDRESS" 255.255.255.255
ip mtu 1400
ip nhrp authentication "NHRP_PASSWORD"(This password is configured all Tunnel interfaces i.e.)
ip nhrp map multicast "HUB_EXTERNAL_IP"
ip nhrp map "HUB_TUNNEL_IP" "HUB_EXTERNAL_IP"(i.e. 10.10.10.10 8.8.8.8)
ip nhrp network-id "NETWORK_ID"(i.e. 10010100)
ip nhrp holdtime 600
ip nhrp shortcut
ip nhrp redirect
ip tcp adjust-mss 1360
load-interval 30
no shutdown
qos pre-classify
tunnel source "INTERFACE"(Interface that will be making the DMVPN Connection)
tunnel mode gre multipoint
tunnel key "KEY"(i.e 10010100)
tunnel protection ipsec profile DMVPNIpsecProfile
ip access-list extended inbound
permit gre any any
permit icmp any any
permit udp any any eq isakmp
permit udp any eq isakmp any
permit udp any any eq non500-isakmp
permit esp any any
permit tcp any any established
Labels:
Cisco
SIP: SIP Response Codes
Here is a list of Sip Response Codes very useful with trouble shooting sip in Wire Shark.
1xx - Informational Responses
- 100 Trying Extended search being performed may take a significant time so a forking proxy must send a 100 Trying response
- 180 Ringing
- 181 Call Is Being Forwarded
- 182 Queued
- 183 Session Progress
2xx - Successful Responses
- 200 OK
- 202 accepted: It Indicates that the request has been understood but actually can't be processed
3xx - Redirection Responses
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Moved Temporarily
- 305 Use Proxy
- 380 Alternative Service
4xx - Client Failure Responses
- 400 Bad Request
- 401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
- 402 Payment Required (Reserved for future use)
- 403 Forbidden
- 404 Not Found (User not found)
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication Required
- 408 Request Timeout (Couldn't find the user in time)
- 410 Gone (The user existed once, but is not available here any more.)
- 412 Conditional Request Failed
- 413 Request Entity Too Large
- 414 Request-URI Too Long
- 415 Unsupported Media Type
- 416 Unsupported URI Scheme
- 417 Unknown Resource-Priority
- 420 Bad Extension (Bad SIP Protocol Extension used, not understood by the server)
- 421 Extension Required
- 422 Session Interval Too Small
- 423 Interval Too Brief
- 428 Use Identity Header
- 429 Provide Referrer Identity
- 433 Anonymity Disallowed
- 436 Bad Identity-Info
- 437 Unsupported Certificate
- 438 Invalid Identity Header
- 480 Temporarily Unavailable
- 481 Call/Transaction Does Not Exist
- 482 Loop Detected
- 483 Too Many Hops
- 484 Address Incomplete
- 485 Ambiguous
- 486 Busy Here
- 487 Request Terminated
- 488 Not Acceptable Here
- 489 Bad Event
- 491 Request Pending
- 493 Undecipherable (Could not decrypt S/MIME body part)
- 494 Security Agreement Required
5xx - Server Failure Responses
- 500 Server Internal Error
- 501 Not Implemented: The SIP request method is not implemented here
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Server Time-out
- 505 Version Not Supported: The server does not support this version of the SIP protocol
- 513 Message Too Large
- 580 Precondition Failure
6xx - Global Failure Responses
- 600 Busy Everywhere
- 603 Decline
- 604 Does Not Exist Anywhere
- 606 Not Acceptable
Labels:
SIP
SIP: SIP Profile Parameters and their usage
DontFwdRefer Usage: DontFwdRefer=[0|1]
When this parameter is set to 1, it inhibits the use of REFER for transfer on the trunk. It also inhibits sending INVITE with Replaces header. Peer must support INVITE without SDP for certain transfer call- flows
SendMacIn911CallSetup Usage: SendMacIn911CallSetup=[0|1]
This parameter is used in conjunction with SIP based emergency gateways, such as those provided by 911 Enable. It appends the MAC address of the IP phone in the From tag of an outgoing emergency call. From: "Dizzy Gillespie
This only applies to ShoreTel IP Phones, excluding the IP-8000 conference room phone
StripVideoCodec Usage: StripVideoCodec=[0|1]
This parameter should be set to 1 if the trunk does not support video properly. When set to 1, it strips video codecs from SDP in INVITE’s being sent to the trunk and properly restores and rejects the video media lines in the 200 response from the trunk. It also strips video codecs from INVITE’s coming from the trunk and properly restores and rejects the video media lines in the 200 response to the trunk
AddG729AnnexB_NO Usage: AddG729AnnexB_NO=[0|1]
This parameter should be set to 1 if the trunk does not support G729 Annex B properly. When this is set, any outgoing INVITE with G729 in the SDP will have the attribute "a=fmtp:18 annexb=no" added to the SDP.
HistoryInfo Usage: HistoryInfo=[none|diversion|history]
This parameter controls how information is presented when an external incoming call is forwarded out this trunk. In this case, the "From" header will indicate the actual caller, which may not be a valid number to present to the trunk. The Diversion or History-Info header will be used to indicate the DID number of the user on who’s behalf the call was forwarded.
If set to 'none' or omitted, then no indication of the forwarding number is presented. If set to 'diversion', the SIP Diversion header is supplied, as dictated by RFC 5806. If set to 'history', the SIP History-Info header is supplied, as dictated by RFC 4244.
EnableP-AssertedIdentity Usage: EnableP-AssertedIdentity=[0|1]
This profile parameter controls how Caller-ID is presented on outbound calls. If it is set to 0 or not pre- sent, then the old style or presenting caller-ID in From header is used when sending outgoing calls. Note that the style of presenting blocked caller-ID has changed in ShoreTel 12.
When set to 1, the Caller-ID is placed in the P-Asserted-Identity header. If privacy is indicated for the call (User dials *67, or trunk group is configured to not send Caller-ID), then a Privacy header is inserted with value “id”, and the From header is anonymous
Port Usage: Port=[5060|1-65535]
This profile parameter changes the remote port used for the SIP trunk. Currently, there is no way to con- figure the port number for SIP trunks in ShoreWare Director. Only port 5060 is supported. This profile parameter allows the port number for a trunk group to be configured
HairPin Usage: HairPin=[0|1]
This profile parameter controls if hairpin is allowed on SIP trunk calls, when enabled and available, features like Barge-in, silent monitoring, whisper-page, whisper-coach, call-record will be supported on the SIP trunks.
OptionsPing Usage: OptionsPing=[0|1]
This profile parameter controls if OPTIONS message should be sent to remote party for detecting connectivity
OptionsPeriod Usage: OptionsPeriod=[180|60-3600]
This profile parameter is used to control the time interval between SIP OPTIONS messages
OverWriteFromUser Usage: OverWriteFromUser=[none|UserID|BTN]
This profile parameter is used to choose either user’s id or billing phone number in the FROM header when making calls
DontAdvertiseUpdate Usage: DontAdvertiseUpdate=[0|1]
This profile parameter is used to decide if UPDATE should be sent in the SUPPORTED header
RFC2543Hold Usage: RFC2543Hold=[0|1]
This profile parameter is used to decide if connection field should be set to 0.0.0.0 in case of sending out- going INVITE for hold
AlwaysSend180 Usage: alwaysSend180=[0|1]
This profile parameter is used to decide if a 180 will be sent out right away after receiving an incoming INVITE
IgnoreEarlyMedia Usage: IgnoreEarlyMedia=[0|1]
This profile parameter is used to decide if early media should be forwarded to the caller, when a SIP de- vice doesn’t wish to accept early media, this parameter should be set to be 1
Register Usage: Register=[0|1]
This profile parameter is used to decide if outgoing REGISTER messages should be sent
RegisterUser Usage: RegisterUser=[BTN|UserID|DID]
This profile parameter is used to decide in what to use in FROM header in the outgoing REGISTER messages
RegisterExpiration Usage: RegisterExpiration=[3600|60-86400]
This profile parameter is used to decide the time interval between outgoing REGISTER messages
1CodecAnswer Usage: 1CodecAnswer=[0|1]
This profile parameter is used to decide if the SDP should contain only 1 codec for an outgoing answer.
SIP Extension Profile Parameters:
1CodecAnswer Usage: 1CodecAnswer=[0|1]
Some devices do not honor the codec order specified in a 200 OK response to an INVITE. This causes several problems. First, some endpoints in the system do not support asymmetric codecs during a session. Second, any bandwidth calculations based on observing the offer/answer exchange will likely be wrong. When set to 1, only 1 audio codec is sent in a 200 OK response.
AddGracePeriod Usage: AddGracePeriod=[0-1800]
Some SIP devices re-register too close to the expiration time, introducing a race condition where the sys- tem is in the process of deleting the record from the system when the re-register is received. This parameter adds a grace period to the expiration received in the REGISTER request.
AllowedCodecs Usage: AllowedCodecs=[any|[codec[,codec]*]
Valid values are ‘any’ (default) or a comma separated list of codec names. The codec name must be for- matted as shown on the Supported Codecs page (Administration, Call Control, Supported Codecs). For example: 'PCMU/8000'. This should be used if the SIP device cannot follow the normal rules of codec negotiation for all codecs supported in the installation. For example, one particular implementation would rejected requests containing some codecs it didn’t understand.
This only applies to audio codecs. Video codecs and RFC 2833 'telephony-event' is not affected by this parameter.
DelayUnregister Usage: DelayUnregister=[0-20]
Some devices, under certain circumstances, un-register, then immediately register again. This introduces a race condition similar to the one discussed in section 0. Usage of this parameter mitigates this problem.
FakeDeclineAsRedirect Usage: FakeDeclineAsRedirect=[0|1|400-606]
Some SIP devices present an option to decline a call. When invoked, various different response codes have been used by various implementations. If set to 0, only a 3xx class response will cause the call to be diverted to the busy destination. If set to 1, 603 will be sent to busy destination as well. If set to a value from 400 to 606, the selected response code will be used to send the call to the busy destination.
MWI Usage: MWI=[none|subscribe|notify]
This parameter defines how RFC 3842 Message Waiting Indication is handled. When set to "subscribe", an explicit subscription is required. If set to "notify", the NOTIFY messages are sent without requiring a SUBSCRIBE. If set to "none", then MWI is not supported.
OptionsPing Usage: OptionsPing=[0|1]
ShoreGear switches can send a periodic OPTIONS message to SIP devices, and mark them Out-Of- Service if they don’t respond. There are 2 benefits to this: Calls are diverted immediately to the busy destination, and there is logging of the event on the server.
The OPTIONS ping occurs periodically between 3 and 4.5 minutes.
OptionsResponse Usage: OptionsResponse=[200-699]
Some devices reject OPTIONS requests, such as with a 405 "Not Supported" response. This can still be used to determine if the device is alive and on the network by using this parameter. Otherwise, a 405 response would put the device Out-Of-Service.
SendEarlyMedia Usage: SendEarlyMedia=[0|1]
When set to 1, the device will be sent 183 response with SDP for certain call-flows. Currently, this is only used in error conditions when an announcement is played.
StripVideoCodec Usage: StripVideoCodec=[0|1]
This parameter should be set to 1 if the device does not support video properly. When set to 1, it strips video codecs from SDP in INVITE’s being sent to the device and properly restores and rejects the video media lines in the 200 response from the device. It also strips video codecs from INVITE’s coming from the device and properly restores and rejects the video media lines in the 200 response to the device.
XferFailureNotSupported Usage: XferFailureNotSupported=[0|1]
For scalability reasons, there are a few call-flows that use REFER as a means for the caller to hear ringback tone. These call-flows rely on the device’s capability to recover from a transfer failure and keep the original call alive. If the device cannot do this, then this parameter should be set to 1, and an alternative means of providing ringback is used.
Labels:
SIP
Tuesday, July 16, 2019
Routing: Administrative Distance Values
I don't always remember even though I should, what the AD values are of the different routing protocols.
- Connected Interface = 0
- Static route = 1
- Summary route (EIGRP) = 5
- External Border Gateway Protocol (BGP) = 20
- Internal EIGRP = 90
- IGRP = 100
- OSPF = 110
- Intermediate System to Intermediate System (IS-IS) = 11
- Routing Information Protocol (RIP = 120
- Exterior Gateway Protocol (EGP) = 140
- On Demand Routing (ODR) = 160
- External EIGRP = 170
- Internal BGP = 200
- Unknown = 255
Labels:
Routing Protocols
General IT: Crossover, Straight through and Loopback cables
When ever I am installing a new PRI or connecting two PBX's together I always need to make a cross over cable and I always end up having to look up the pin out. So I thought I would just add it here and make it easy on myself for future reference.
Straight Through patch cable
T1 Crossover Cable
T1 Loop-back
Labels:
General IT
ShoreTel: Konftel 300IP and ShoreTel/Mitel Configuration
This will provide you with some detail on how to intergrate a Konftel 300IP conference phone in to a ShoreTel/Mitel phone system.
If you do not have a switch at a site that has any SIP Proxy resources enabled you will need to find a switch at that site that has an available resource and set it to SIP Proxy.
Navigate to Administration=>Sites=> then the site you are looking to add the phone to. Scroll down to the SIP proxy switch for that site and under Proxy Switch 1 click the drop down and select the phone switch that you would like to use that already has the SIP Proxy resource enabled on it. If you are using more than one switch for SIP Proxy resources then you can add the 2nd switch in the Proxy Switch 2 field and then enter in a IP address into the Virtual IP address box.
Navigate to Settings=>SIP to configure the user account that was created on the ShoreTel/Mitel system.
In SWD navigate to Maintenance=>Status and Maintenance=>IP Phones, then click the Name column to sort by phone names. You should see the Konftel phone in the list, which means the phone has resisted with the ShoreTel/Mitel system and is ready to be used.
Call Control Settings
In SWD navigate to Administration=> Features=>Call Control=>Options and make sure that the parameters (default values) are configured in the SIP section.Switch Settings
In SWD navigate to Administration=>Appliances/Servers=>Platform Equipment. ShoreTel Voice switches can support IP phones and SIP phones in a various methods, either as a physical port, DSP resource or built in capacity. From this page you can look to see if you have any switches that are already configured with SIP Proxy resources, by looking under the SIP proxy column.If you do not have a switch at a site that has any SIP Proxy resources enabled you will need to find a switch at that site that has an available resource and set it to SIP Proxy.
Navigate to Administration=>Sites=> then the site you are looking to add the phone to. Scroll down to the SIP proxy switch for that site and under Proxy Switch 1 click the drop down and select the phone switch that you would like to use that already has the SIP Proxy resource enabled on it. If you are using more than one switch for SIP Proxy resources then you can add the 2nd switch in the Proxy Switch 2 field and then enter in a IP address into the Virtual IP address box.
SIP Profile
To be able to optimize the Konftel phone interoperability a new SIP profile must be created. Navigate to Administration=>Telephones=>SIP Profiles and click new. Name the new SIP profile Konftel 300IP and set the User Agent to "Konftel300IP.*" Then in the Custom Parameter add "XferFailureNotSupported=1" Make sure the Enable check box is checked and click Save.User Setup
Navigate to Administration=>Users=>Users and then find the user you wish to set up for the Konftel phone. Scroll down to the SIP password and enter a SIP password for this users. Also make not of the users Client Username, and Extension number.Konftel 300IP Configuration
The best way to configure the Konftel phone is from the web interface. Find the IP address of the phone Menu=>Status=>Network in Konftel User interface on the phone. Navigate to that address using a web browser and log in as ADMIN and the default password of 1234Navigate to Settings=>SIP to configure the user account that was created on the ShoreTel/Mitel system.
- Account name is displayed on the idle screen of the phone
- Users is the Users extension number
- Registrar is the IP address of the SIP Proxy
- Authentication name is the ShoreTel Client Username
- Password is the ShoreTel SIP password
In SWD navigate to Maintenance=>Status and Maintenance=>IP Phones, then click the Name column to sort by phone names. You should see the Konftel phone in the list, which means the phone has resisted with the ShoreTel/Mitel system and is ready to be used.
Labels:
ShoreTel
Thursday, June 20, 2019
ShoreTel: Migrate a ShoreTel 14.2 system to a new Server
Here are the steps that I follow when I need to migrate a ShoreTel 14.2 and below system to a new server. This could be to upgrade the server OS or moving from a physical server to a virtual server.
There are a few things to note:
- You will need to install the SAME version of ShoreTel on the new server that you are using on the current server
- The new server will have to have the same IP address as the current server at the time you install ShoreTel on it
- The new server will have to have the same computer name as the current server at the time you install ShoreTel on it
- After the server is migrated you will need to request a new system key from ShoreTel
Prep new Server:
- Prep the new server as per the Build Notes and Install Guide
- Change IP address to the same IP as the old server
- Change the name to the same name as the old server
- Install the ShoreTel Software (EXACT same build as old server)
- Right click on Setup and click "Run as Administrator
- Reboot when Prompted
- Log in to Director using the default credentials
- Username: admin
- Password: changeme
- Verify all services are running by click on the Headquaters link to the right of the Quick Look page
- Log out of Director
Back up the old server:
- Databases .sql files
- Navigate to C:\Program Files (x86)\Shoreline Communications\Shoreware Server\MySQL\MySQL Server 5.0\Examples and run the following files
- BackupCDR.bat -> Will output an .sql file to the root of C:
- BackupConfig.bat -> Will output an .sql file to the root of C:
- BackupWebridge.bat -> Will output an .sql file to the root of C:
- Only required if there is an SA-100/SA-400 in use.
- BackupMonitoring.bat-> Will output an .sql file to the root of C:
- Only required for ShoreTel 14.x
- Copy the resulting .sql files folder to a safe location (Network Share, Thumb drive, etc...)
- Shoreline Data folder
- Stop all ST services from script at C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-stop-svcs (make sure to run as administrator)
- Copy the VMS, User Data, & Prompts folder from Shoreline Data, to a safe location (Network Share, Thumb drive, etc...)
- Start all ST services from script at C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-start-svcs (make sure to run as administrator)
- Reboot the ShoreTel server
- Copy the back up files to the new server
- Shut down the Old server
Restore data to new server
- Place the backed up configuration and CDR SQL files at the root of the C: drive and run the "Restore" batch files at C:\Program Files (x86)\Shoreline Communications\ShoreWare
- Server\MySQL\MySQL Server 5.0\Example
- RestoreConfig.bat
- RestoreCDR.bat
- Only required if the site has an SA-100/SA-400
- RestoreMonitoring.bat
- Stop all ST services from script at C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-stop-svcs (make sure to run as administrator)
- Copy the back up version of VMS, Promps, and User Data folders to the Shoreline Data folder (write over the new folders)
- Delete all .dat files in the VMS folder
- Start all ST services from script at C:\Program Files (x86)\Shoreline Communications\ShoreWare Server\Script\ hq_shoretel-start-svcs (make sure to run as administrator)
- Reboot the server
Verify the old data is restored
- Log into Director with your existing credentials
- Check for your users, AA menus, switches, etc
- Request a new license key for the new server
Labels:
ShoreTel
ShoreTel: How to check your Voice mail from outside the ShoreTel/Mitel system
There are sometimes where you need to call into the ShoreTel\Mitel phone system to check your voice mails. This usually happens when you are not doing voice mail to email, don't have access to the system remotely or many other reasons. To access your voice mails just follow the instructions below.
- Dial your direct number or another phone number that belongs to the system
- When you hear the voice mail greeting press the * and then #
- The System will ask you to enter you extension number
- Then the system will ask you to enter your voice mail password followed by a #
- After you have completed the above, all operations are the same as the regular office voice mail
Labels:
ShoreTel
ShoreTel: How to log into a ShoreTel/Mitel phone
Here are the steps that you can use to log into a ShoreTel/Mitel phone that is in a Available state or if someone else is logged into it.
Sometimes (depends on the system configuration) on the ShoreTel/Mitel IP 400 series phones there will be a soft key that you can use to assign your extention to that phone. To do this you would:
If your phone does not have the Assign soft key you can still assign your extension to that phone. To do this you would:
Sometimes (depends on the system configuration) on the ShoreTel/Mitel IP 400 series phones there will be a soft key that you can use to assign your extention to that phone. To do this you would:
- Press the Assign soft key
- Enter your extension number
- Press the Next soft key
- Enter you voice mail password
- Press OK
- If you need to unassign your extension from a phone there is a unassign soft key you can press or you can follow the steps below to unassign you extension from the phone
If your phone does not have the Assign soft key you can still assign your extension to that phone. To do this you would:
- Pick up the handset to go Off-hook
- Press the # to access the Voice Mail system
- Enter your extension number
- Enter you voice mail password
- Enter 7, 3, 1, to assign your extension to that phone
- If you need to unassign your extension from a phone, you would follow the steps above except you would enter 7, 3, 2
Labels:
ShoreTel
ShoreTel: How to find a call GUID from the Connect Client
How to pull a GUID for a ShoreTel/Mitel Call or Voice Mail from the Connect Client.
- In the connect client Click on the Recent Navigation link
- In the right pain select the drop down and select Calls or Voice Mail
- Find the Call or Voice Mail that you need the GUID for
- Right click that Call or Voice Mail and select Copy Call ID to Clipboard
- Now you can past the GUID into a email or text document
Labels:
ShoreTel
ShoreTel: Installing Connect Windows components fail
A few times when I started installing Mitel Connect on a Windows Server 2016 I have gotten issues where some of the Microsoft windows components fail to install. Things like Web Framework, external cache, ect.
This is because there is a bug where the Connect install has a issue reading the framework version. So in order to fix this you have to edit the registry. In order to do this open regedit and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp
Once there edit the "MajorVersion" entry, and set the "DECIMAL" value to 9 and then reboot the server. Now you can go back and install the Connect software and you should be good to go.
This is because there is a bug where the Connect install has a issue reading the framework version. So in order to fix this you have to edit the registry. In order to do this open regedit and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp
Once there edit the "MajorVersion" entry, and set the "DECIMAL" value to 9 and then reboot the server. Now you can go back and install the Connect software and you should be good to go.
Labels:
ShoreTel
Thursday, May 16, 2019
Cisco: Useful Cisco commands
There are a ton of useful Cisco commands that I do not use everyday but I still use often. This post is probably going to be one that gets updated frequently with new commands that I come across that I want to hold on to. So I am apologizing in advance in case this one gets a little messy. The actual Cisco command will be in bold lettering and in quotations.
Display Cisco stateful packet inspection session created becasue a policy map is applied on a specified zone pair - "show policy-map type inspect zone-pair sessions"
To show AnyConnect connected VPN users and their session info - "show vpn-sessiondb anyconnect"
To show that detailed status for active crypto sessions (i.e. VPN) - "show crypto session detail"
To delete a router config enter in the following command and reboot the router with out saving - "delete nvram:startup-config"
Here is how to create a LACP trunk on a Cisco switch:
"interface GigabitEthernet1/0/48
switchport mode trunk
channel-protocol lacp
channel-group 2 mode active"
Cisco 4K routers NAT ACL's can not use a Permit IP any any for the NAT overload statement. It has some issues with it, so you need to be more specific with the networks that it will be NAT'ing. For security reasons you should be specific anyways. By using a Permit IP any any NAT statement it will cause irregular behavior on the router, it very well may work but it also may just stop working.
"ip nat inside source list NAT interface GigabitEthernet0/0/0 overload
IP access-list extended NAT
10 permit ip 10.1.1.0 0.0.0.255 any
20 permit ip 10.1.2.0 0.0.0.255 any"
Display Cisco stateful packet inspection session created becasue a policy map is applied on a specified zone pair - "show policy-map type inspect zone-pair sessions"
To show AnyConnect connected VPN users and their session info - "show vpn-sessiondb anyconnect"
To show that detailed status for active crypto sessions (i.e. VPN) - "show crypto session detail"
To delete a router config enter in the following command and reboot the router with out saving - "delete nvram:startup-config"
Here is how to create a LACP trunk on a Cisco switch:
"interface GigabitEthernet1/0/48
switchport mode trunk
channel-protocol lacp
channel-group 2 mode active"
Cisco 4K routers NAT ACL's can not use a Permit IP any any for the NAT overload statement. It has some issues with it, so you need to be more specific with the networks that it will be NAT'ing. For security reasons you should be specific anyways. By using a Permit IP any any NAT statement it will cause irregular behavior on the router, it very well may work but it also may just stop working.
"ip nat inside source list NAT interface GigabitEthernet0/0/0 overload
IP access-list extended NAT
10 permit ip 10.1.1.0 0.0.0.255 any
20 permit ip 10.1.2.0 0.0.0.255 any"
Labels:
Cisco
Subscribe to:
Comments (Atom)







