Howto:Firmware Upgrade V11r2 V12r1

From innovaphone wiki
Revision as of 12:24, 26 February 2020 by She (talk | contribs)
Jump to navigation Jump to search

Applies To

This information applies to:

  • All PBX devices
  • All DECT devices
  • Linux Application Platform

Migration Policy

Configuration Changes

Automatic Media Relay

Up and including v12r2, the PBX and relay have done media-relay for all calls between public and private network addresses. From v12r1 on, this is done only if Media Relay explicitly set to Auto in the PBX or in a gateway interface. <internal>communote: https://communote.innovaphone.com/microblog/global/portal/topics/12r1/notes/45172</internal>

Linux Application Platform and its applications

xx11/11xx gateways can host a LinuxPlatform as well. First LinuxImage which as well fits for the new hardware types is V10sr32 (Build 100210). This build contains TWO linux images labeled

  • Image-6010-3.4.10 - for old hardware types
  • Image-IPx11-4.4.0 - for new hardware types (xx11/11xx)

Pay attention to the definition of used "Linux Kernel file" at Linux/General - especially when moving configuration files from "old" to "new" hardware types.

Please note that there is no v12 version of the linux application platform, so you still will be using Linux Application Platform V10.00!

Known Problems

Main Memory (RAM) Considerations

New firmware always has more features which in turn requires more resources. Growing firmware will thus consume both more flash and RAM for sure. A given system configuration will run flawlessly after a firmware largely only if there is still enough memory left after boot. As a rough rule of thumb, a v12r1 release will consume 1.5MB RAM and 0.8MB flash more compared to a v11r2 firmware.

Standard configurations which are according to spec will run on all supported hardware. However, unusual configurations may not. It is a good idea to examine both flash and RAM memory left on high load situations in your existing configuration to see if there is enough resources left for an upgrade. Please find details in Reference:Device Health Check.

Special care has to be taken for old devices with less memory than suggested by current specs. Most notably, these are the older IP30x models (hardware build 306 or less, which had 16MB RAM as opposed to 32MB in the current models). We do not recommend to upgrade such old hardware to a current firmware version unless it has been determined that the configuration in question will work.

Flash Memory Considerations

New firmware comes with new code for new features which consumes more flash memory for the firmware image. For this reason, the IP800/IP22/IP24/IP38/IP302/IP305 may run out of flash memory during upgrade to v12r1. Here is the recommended procedure for upgrade on such devices:

  • save entire configuration
  • reset to factory defaults
  • load saved configuration (this will reorganize flash memory usage)
  • upgrade to new firmware

When there is still not enough flash memory available to store the new firmware, the web GUI will issue a Firmwareupdate failed:no space during firmware upload. If the firmware upload is done using the update client, a Error 0x00130001 Major FLASHMAN0 no space event will occur.

With the new firmware, the amount of flash memory allocatable for the LDAP directory (that is, PBX config and call lists) is less than before to accommodate for the larger requirements. It is reduced from 3200kB to 2816kB on the IP800 and from 3200kB to 2560kB on the IP22/IP24/IP38/IP302/IP305.


On older IP110, IP200a, IP230 and IP240 phones, the PPP module has been removed from the firmware to keep the flash memory allocatable for the LDAP directory (that is, local phone book and call lists) unchanged. Following file naming applies:

  • ip110,ip200a,ip230,ip240.bin support H.323 w/o PPP
  • ip110,ip200a,ip230,ip240-sip.bin support SIP w/o PPP
  • xxx-no-ppp.bin files are obsolete

No /DRIVE/CX0 any more

The /DRIVE/CX0 announcement file encoder has been removed. Use the web based converter instead.

SIP Digest Authentication

We have implemented protection against Replay Attacks for the SIP Digest Authentication.

In v12 (or later) we exercise the "one-time digests" strategy. A formally correct Digest Response is not accepted a second time. A client is required to increment the "nc" parameter if it issues another request.

If the client does not support this requirement the PBX will reject the registration. There is a config option to disable the protection. But it is not recommended to disable this feature. It's a security feature.

# for SIP/UDP
http://ip-of-pbx/!config change SIP /disable-digest-replay-check
# for SIP/TCP
http://ip-of-pbx/!config change TSIP /disable-digest-replay-check
# for SIP/TLS
http://ip-of-pbx/!config change SIPS /disable-digest-replay-check
http://ip-of-pbx/!config write
http://ip-of-pbx/!config activate

You get a hint with the SIP/2.0 401 Unauthorized message (wireshark pcap)

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.88.142:5060;branch=z9hG4bK5d7b5284edaa9bed3e3a323dc78f4022;rport=5060;received=192.168.88.142
From: <sip:111@192.168.88.134>;tag=2469966351
To: <sip:111@192.168.88.134>;tag=1151509663
Call-ID: 3129114392@192_168_88_142
CSeq: 1903 REGISTER
Content-Length: 0
Date: Fri, 06 May 2016 13:54:31 GMT
Warning: Digest replay attack detected
WWW-Authenticate: Digest realm="192.168.88.134",nonce="859b13f3852c5701116600903340032b",qop="auth",algorithm=MD5


We have added a new option to the SIP module. If you have problems to register your SIP client with an authentication. Please use the latest available version V12r1.

http://ip-of-pbx/!config [^] change SIP /no-authentication-info 
http://ip-of-pbx/!config [^] write
http://ip-of-pbx/!config [^] activate

Some SIP clients did not support it or did not work well. So you have to disable the authentication-info.

The client has to support the

RFC-2617:
  nonce-count
    This MUST be specified if a qop directive is sent (see above), and
    MUST NOT be specified if the server did not send a qop directive in
    the WWW-Authenticate header field. The nc-value is the hexadecimal
    count of the number of requests (including the current request)
    that the client has sent with the nonce value in this request. For
    example, in the first request sent in response to a given nonce
    value, the client sends "nc=00000001". The purpose of this
    directive is to allow the server to detect request replays by
    maintaining its own copy of this count - if the same nc-value is
    seen twice, then the request is a replay.

Special Precaution required when upgrading IPxx11 Gateways from pre-V11r2 sr13 or any V12r1 preview

There is an issue with cache coherency when multiple device drivers access the internal flash memory. In particular, if the SSD is used (by Linux or WebDAV), wrong data may be read from the internal flash (resulting in lost PBX objects for example). This issue has been fixed in V11r2 SR14.

However, during a firmware upgrade, this may result in corruption of some inherent device information such as the device's MAC address.

See Support:Special Precaution required when upgrading IPxx11 Gateways from pre-SR14 Firmware Versions!

Replicating objects from a dynPBX as dynPBX (Standby PBX)

It’s necessary to a add a dynPBX Id in the configuration of a Standby PBX in V12 if you are trying to a replication objects from a dynPBX to a dynPBX. In V11 you had to leave it empty because it used its own Id to find it at the master.

Related Articles