PPM / Feature Buttons not working on Avaya SIP phones

This one was very frustrating. My SIP phones could log into the SBC-E and got dialtone fine, but wouldn’t pull PPM. The Avaya One-X Communicator for iPhone could do it though. Whaaaaa??

I have my phones configured to pull a config file from a web server – it’s the only manual setting required in the phone. All other settings are in the config file on the web. Well, it turns out that the phone didn’t like the SET CONFIG_SERVER w.x.y.z parameter. Once I removed that, then PPM flowed just fine.

By the way, if you have trouble with feature buttons, the other issue I had was the entity link between Session Manager and the SBC. If your’re using TLS connections between the phone and the SBC, then you also need to use TLS on the entity link between the SBC and the Session Manager, and the Session Manager to the Communication Manager. In other words, all connections from the endpoint to the CM need to be TLS. If any of them go back to unencrypted TCP or UDP, then the PPM breaks. At least it did for me!

10 thoughts on “PPM / Feature Buttons not working on Avaya SIP phones

  1. Mervyn

    I look forward to more interesting Factoids surrounding the world we live in, This is a wonderful find, I will try to send you some European articles that I have in my archive somewhere.

    Keep up the good work.

    I would love to see the routing diagrams/schematics

  2. Waheed Karwani

    Hi Roger

    I hope you’re well?

    Please help, i’m trying to setup remote workers on my SBCE but so far have had no luck after following the Avaya doc for remote workers.

    I’m not using TLS but trying to set it up using TCP for now. I have passed this onto our support team who have not set this up yet and said they will charge for 2 days work but can’t confirm if they can even fix this.

    Any help would be much appreciated.


    1. roger Post author

      My business partner set it up for me, so I’m not sure. The TLS is important for PPM. If you just want ‘dialtone’ with no features or common lamping, then you can mix tls with non-tls. If you want PPM, then it needs to be 100{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0} tcp/udp or 100{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0} tls back to the CM. At least, it was that way for me.

      But if you don’t have the programming in the SBCE, then I will probably not be able to help. It looked extremely complicated and not at all intuitive. Do you have some of the programming done?

      1. Waheed Karwani

        Hi Roger

        I have programmed the SBCE following the docs supplied by Avaya but its still keeps seeing a “forbidden message” on the SBCE trace.

        So i would be happy to share this with you but so far i have had no luck with this.


  3. Jameel

    Hi Roger,

    Very interesting posts, always a good read. I have a question about Avaya phones but in a non-Avaya environment. I actually have quite of few of them working with just Freepbx using the SIP firmware. However on the later model phones 9641g I can’t seem to get the MWI working. On the 9630’s they work very well. Upon some digging around, it looks like the newer firmware for these phones do not like the transport=TCP at the end of the SIP notify MWI message.

    I have seen some posts about modifying the SIP messages. I was wondering if you would be able to give me some pointers on how to get that going? Any help would be greatly appreciated. Here is my post about how I got these phones working in a non-Avaya Environment:


    Many thanks,

  4. John Waber

    In spite of what the error message says, the issue is not the domain in the FROM header but the one in the P-Asserted-Identity (or possibly the Contact) header. The fix is to get the Authoritative Domain in the PROCR Network Region to match what is provided. That might also require a rule in the SBC to modify the domain on those headers (FROM, P-Asserted-Identity, and Contact) to the domain specified on CM.

    I found the following on the Avaya Support site.
    Doc ID: SOLN223576
    Version: 1.0
    Status: Published
    Published date: 15 Mar 2013
    Author: Charles Kuhn

    Receiving 403 Forbidden Error when calling a new toll-free number.

    Problem Clarification
    When calling the new toll free number the call traverses carrier network to customer inbound SIP trunk (SONUS) to AVAYA session Manager to PROCR on AVAYA CM. AVAYA CM rejects the call with a 403 Forbidden Invalid Domain in From header.

    Because CM is configured with an authoritative sip domain and because the far-end is sending a p-asserted identity (PAI) the session manager will pass the PAI to CM and if the domains don’t match then the CM will reject with a 403 Forbidden, Invalid domain in From header.

    Customer should create a rule or direct responsible party in the SBC to not send PAI would be the best solution.

  5. Ted Hargiss

    I have the same problem on all of my SIP phones. Where is the SET CONFIG_SERVER w.x.y.z parameter set? And, how is it removed?


    1. roger Post author

      Sorry Ted – I just saw this. It’s in the 46xxsettings.txt file that the phone loads upon bootup. If you don’t have it in your config file, then you can get a newer version from Avaya’s site. Or let me know and I can dig one up.

      1. Ted Hargiss

        My 46xxsettings.txt file does not have the SET CONFIG_SERVER w.x.y.z parameter, and it still would not get its features.

        However, I did find out that the following parameters must be set in order for PPM to pass features:
        SET SIP_PORT_SECURE 5060
        (it is trying to get the PPM via https rather than http)

        Now this worked for TCP. The SIP phone registered and got its PPM. However, some of the features didn’t work such as alerting an active call on bridged-appearances.
        I changed the file parameters back to TLS and I am experiencing the same shortfalls: phone registers, PPM passes, but the some features do not work.

        NOTE: I am running TCP between CM>ASM>SBC.



Leave a Reply

Your email address will not be published. Required fields are marked *