srp521w issues with functionality and firmware

[paulbertrand1399]

A client picked up a Cisco SRP521w router for use with a asterisk based pbx using sip.  We installed it but immediately had issues with being unable to register our sip trunks and being unable to resolve this issue switched it back out.  Looking at things more closely we now realize that the status shows the firmware as being v1.2.4 which is beyond Cisco's latest v1.01.29.  Can anyone shed some light on this?  Did my client pick up a bad router?  The router looks like a legitimate Cisco (as far as we can tell).  Any help or suggestions would be appreciated.  Thanks.

[Tom Rottler]

Hello Paul,

The firmware v1.2.4 belongs to the Cisco SRP 540 series and not the 520 series as you described.  I am sure that you have done this but have you checked that you actually have the correct router?

In Cisco's Services Ready Platform Configuration Utility, on the top right of the page once logged in is a tab called "about".  Click on the tab and a new window will appear.  Copy what's in the window and paste on your reply so we all can see this issue.

Kindest Regards

[Andrew Hickman]

Hi Paul,

Tom is correct that the 1.2.4 release (we just posted 1.2.6 by the way) is for the SRP540 series.  It can also be used with the newer SRP520-U products.  (i.e. if your part number is something like SRP52xW-U-x-K9)

The 1.1.x releases may only be used with the original SRP520 series devices (SRP52xW-K9-Gx).

Regarding the SIP trunk.  The SRP voice features were intentionally designed to work with a hosted IPT service and as such, the SIP User Agents for the voice ports are bound to WAN interface using different port numbers to avoid NAT complications. 

If you want to use a local call control agent, you'll need to keep this in mind, as you'll need to use the WAN address when configuring Asterisk.  This may be an issue if your SP assigns addressing dynamically, but you may be able to deal with this using DDNS and a FQDN instead of an IP address.  Alternatively, you could also consider adding a WAN sub-interface with a private address and binding the voice application to this.

Regards,

Andy