In System Manager (SMGR) there is a really nice reporting capability. To find it, navigate to: Elements >> Reports.
Look for the option for Detailed Reports. And look for the options to have the report emailed, and on a reoccurring basis.
Chapter 17 of the SMGR Admin guide provides...
Over the years I have loaded CM probably a couple hundred times. So, I have frequently bumped into that issue, where the "ADD" command is not available. What works for me (which is what it appears you also did) was:
1. From CM's web-based System Management Interface, create a new customer...
My first suggestion is that you force a reload of the PPM information. (i.e. Reload Complete, or Reload Config). That would help ensure the phone has the correct/current configuration.
My second thought is that perhaps you have made a very common administration mistake. Many administrators...
Neither Communication Manager (for H.323 phones) nor Session Manager (for SIP phones) impose a penalty if a user inputs the wrong credentials too many times when logging into their phone. In other words, a hacker can try new passwords endlessly. Further, there are no alarms or reports about...
You will find your answer on page 12 of this document:
Avaya J100 Series SIP IP Phones Overview and Specifications Release 4.1.6
https://support.avaya.com/css/public/documents/101084503
The command to invoke fall-back to the CM-main is:
enable mg-return
The following URLs point to documents that might be helpful.
Avaya Aura® Communication Manager Survivability Options Release 10.2.x
https://support.avaya.com/css/public/documents/101087592
Administering Avaya Aura®...
I'm guessing that on your SIP Trunk-Group the Service Type is set to Public-Network. Try changing it to Tie.
CM assumes that a Public SIP Trunk-group is connecting to the PSTN through a SIP Service Provider. In such cases, the SIP Serviced Provider requires that the Called-number be formatted...
To the best of my knowledge, you CANNOT encrypt your calls to the PSTN.
First, the two parties to the phone call must be able to use the same encryption standard. Typically, that is AES (Advanced Encryption Standard) with 256 bits, but there are several choices of encryption standards. So...
I understand how easily that sort of mistake can happen--I've made my fair share of 2:00 AM oops.
I believe the fundamental problem is that your SBCE is still not applying Topology Hiding to the traffic going to ASM. I'm looking at the Server Flow for KCELL you presented above. It looks...
It appears you did the opposite of what I was suggesting.
In the Server Flow going to KCELL, the Topology Hiding should be: Default
In the Server Flow going to ASM, the Topology Hiding should be: ASM
Sorry, I should have been more specific about my suggestion for fixing Topology Hiding. First, put back the line that Overwrites the domain in the Request-Line.
You should have two Topology Hiding (TH) statements. The first one, "Default" contains no changes. In other words, the Action for...
So, trying to summarize the discussion.
Problem: Outgoing calls work, but incoming calls from SP, through SBCE, are being rejected by ASM with the error "407 Proxy Authentication Required".
Reason: ASM does not recognize the request as coming from a SIP Entity, namely the SBCE.
Background...
First, thank you for providing this level of detail. It helps enormously.
When Aura Session Manager (ASM) responds with a 407 Proxy Authentication Required response that means that ASM believes it is talking to a SIP endpoint. Essentially ASM is saying "I don't trust you. Prove to me that...
I notice that the phone numbers contain different quantity of digits.
TO: 83459
FROM: 13048483447
In the Communication profiles for your SIP users, did you administer two addresses? In this case you probably need both [ Avaya SIP 13048483459@evoipsip.fbi ], and [Avaya SIP 83459@evoipsip.fbi]...
It surprised me when I was setting up my first SBCE to learn that the default behavior of all SBCs is to forward ALL requests. So when ASM sends an OPTIONS request towards the SBCE, the SBCE simply forwards it out the other side to the SIP Trunking Provider's SIP Proxy. In my experience...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.