You have configured the AudioCodes Gateway (M800, M1K, M2k) with the best of your knowledge. Numbers manipulations are all correct in your view. You are sending the call to PSTN however call is simply dropping and you encountered below errors on logs.
Other errors on the logs:
- pstn recv <– CALL_RELEASED Trunk:0 Conn:0 RetCause:104 NetCause:44
- Abnormal Disconnect cause:44#GWAPP_REQUESTED_CIRCUIT_NOT_AVAILABLE Trunk:0 Conn:0
- LOCAL_CALL_RELEASED_EV(Trunk:0 Conn:0 Bchannel:28 TpEv=68)
- LOCAL_CALL_RELEASED_EV State:WAIT_FOR_BOARD_ANSWER Substate:sub_None
- RELEASE_EV (send) GWAPP_REQUESTED_CIRCUIT_NOT_AVAILABLE
So what’s wrong??!!
First, ask your customer if how many E1 or T1 channels they purchased. Usually as Voice engineers, we are used to use 1-24 for T1 and 1-31 for E1 in Trunk Configuration however if for example your customer only bought 10 channels, you must specify it in Trunks configuration correctly like 1-10 range only. Otherwise, you will meet above errors.
Hope it helps you!!
Resetting PIN for IP Phones logins also applies to resetting the Dialin PIN. So this is how it is done in SfB Client side.
Go to Phone Icon -> Pin
Dialin Page will pop-out, and sign in using your AD Sign-in address.
Then, reset your PIN accordingly.
Exchange Web Services (EWS) is a service used by Lync/SfB to integrate with Exchange. Successful integration obtains:
- Free/Busy information
- Save Conversation History
- High Resolution Photos
- Voice Mail Access
Lync/SfB Client process to connect to Exchange Web Services (EWS)
1. Client will attempt to read any existing Autodiscover data with a valid Time-to-Live (TTL), which may have been previously retrieved by Outlook.
2. Client or device will extract the SMTP domain from the user’s presence document.
3. Client or device will then use the user’s SMTP domain to construct DNS queries for the following URLs:
a. https:///autodiscover/autodiscover.xml -if fails, goes to b.
b. https://autodiscover./autodiscover/autodiscover.xml -if fails, goes to c.
c. http://autodiscover./autodiscover/autodiscover.xml -if fails, goes to d.
d. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and then “sg-exchcas01.contoso.net” is returned.
4. Client asks permission from the user to continue with Autodiscover to post to https://sg-exchcas01.contoso.net/autodiscover/autodiscover.xml
5. Autodiscover’s POST request is successfully posted to https://sg-exchcas01.contoso.net/autodiscover/autodiscover.xml.
Here’s the thing, I want to post this since I always forgot this syntax every time I’m in the field integrating Lync/SfB and Exchange UM. I tested it over Exchange 2013 UM and setup is on-premise.
New-ExchangeCertificate -FriendlyName ‘LyncUM’ -PrivateKeyExportable $true -KeySize ‘2048’ -SubjectName ‘C=SG, O=LNC, CN=SGEX1.contoso.com’ -DomainName ‘SGEX1.contoso.com’ -Services ‘UM,UMCallRouter’ -Server ‘SGEX1.contoso.com’
Note: The credit for this explanation does not belongs to me. I got this few years ago and save on my notepad but I forget to give credit to the author. If you read this, please comment.
The conversation history you are seeing in outlook is nothing to do with your archiving. Implementing Lync/SfB along side Exchange is giving you that functionality. This is a users personal conversation history, that they can refer to and manage as they see fit – and yes it contributes to the size of their mailbox but it’s insignificant size.
An archiving server on the other hand, stores IM and conferencing data to SQL. Archiving is normally deployed if a company needs to meet regulatory requirements, or would like to archive IM data for a period of time for their own personal ‘safety net’ reasons. If a user deletes something from their personal conversation history (mailbox) it is not removed from the server side archiving.
Retention policies and configuration is used on the server side archiving to determine how long you would like to keep data in the store, and how often to purge said data etc.
Question: Are we duplicating data?
Answer: Yes, but for two very different reasons.
One is manageable by the end user, and exists for their use, reference and history purposes. The other managed by administrators and used as the ‘go to’ point regarding incidents etc. A user could send an abusive IM then delete it from his own history, the purpose of an archiving server nullifies his attempts at covering things up.
Mailbox impact is trivial regarding conversation history.
Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn atl-sql-001.litwareinc.com -SqlInstanceName rtc -DatabasePaths “G:\CSDB”
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn atl-sql-001.litwareinc.com -DatabasePaths “E:\CSLog”,”F:\CSLog”,”G:\CSDB”
Install-CsDatabase -DatabaseType Monitoring -SqlServerFqdn LYNCCLUS01.litwareinc.com -SqlInstanceName SGLYNCMON -DatabasePaths I:\MonitoringLogs,H:\MonitoringData
Install-CsDatabase -DatabaseType Archiving -SqlServerFqdn LYNCCLUS01.litwareinc.com -SqlInstanceName SGLYNCARC -DatabasePaths I:\ArchivingLogs,H:\ArchivingData
Uninstall-CsDatabase -DatabaseType Monitoring -SqlServerFqdn LYNCCLUS01.litwareinc.com -SqlInstanceName SGLYNCMON
Uninstall-CsDatabase -DatabaseType Archiving -SqlServerFqdn LYNCCLUS01.litwareinc.com -SqlInstanceName SGLYNCARC
Moving Standard Lync CMS to Enterprise Lync/SfB
- Backup the CMS from Standard FE server.
- Export-CsConfiguration -Filename Customerconfig.zip
- Export-CsLisConfiguration –Filename Customerlis.zip
- Run as Administrator: Open Lync Management Shell from Enterprise Edition Server and type below.
- Install-CsDatabase –CentralManagementDatabase –UseDefaultSQL Paths -SqlServerFQDN sg-lyncdb.contoso.com –clean
- Run as Administrator: Enable from the Lync topology
- Run as Administrator: Move the CMS
- Restart both Master Replica Service and File-Transfer Agent service on Front end Servers
- Verify if CMS is installed on the EE pool
- Verify if replication is UpToDate
- Re-run “Install or Update Lync Server System” from Front end Servers
Remove the CM store files after a move
- Warning! Do not proceed if Get-CsManagementStoreReplication status isn’t UpToDate yet.
- Login to Standard FE server and remove CMS database files
- Uninstall-CsDatabase –CentralManagementDatabase –SqlServerfqdn sg-LyncTMP.contoso.com –SqlInstanceName rtc
Looks easy, isn’t it?
Firmware version: 7.0
The procedure below describes how to configure the address of the debug recording (capturing) server to where the device sends the captured traffic. Once you configure an address, the device generates DR packets for all calls.
Configuration tab > System menu > Logging > Logging Settings
In the “Debug Recording Destination IP”, put the IP address of your PC where you install and run wireshark.
Configuration tab > System menu > Logging > Logging Filters Table
Set as below:
- Filter Type: Any
- Log Type: Signalling & Media
- Mode: Enable
Activate a wireshark which will gather all the SIP and RTP traffic coming to and from the GW or SBC.
Reproduce the issue, then stop the wireshark. Send the logs to AudioCodes Support.
Note: Disable the Debug Recording on the GW or SBC.
You can configure the amount of information (debug level) to include in Syslog messages.
To configure the Syslog debug level:
Configuration tab > System > Syslog Settings
- Enable Syslog: Enable
- Syslog Server IP Address: IP address where Syslog Viewer or Wireshark is installed
- Syslog Server Port: 514
- Syslog CPU Protection: Enabled
- Debug Level: Detailed
Syslog Viewer can be downloaded here http://www.audiocodes.com/downloads