A Sipura 3000 is effectively two SIP devices, one FXS (plug in an analog phone) and one FXO (plug in a phone line), which can cross-connect (e.g. dialing 911 can be routed out your local landline, and incoming calls on the analog line can be routed to the analog phone). Mine came with the FXS at port 5060 and FXO at 5061. If yours was preconfigured by a provider, it may be configured differently, and there may be lots of settings you can't change or even see at the option of the provider who configured it.
You cannot have two devices on the same public IP and the same port, as a NAT gateway cannot decide where to send packets coming in from the outside. Since the Sipura 3000 is two sip devices, you'd need to set two alternate ports.
If your setup has the two VOIP devices on two different public IP addresses (no NAT), this should present no problem (except for bandwidth and latency issues, which mostly has to do with pipe size).
This may be administratively impractical. If you make an IP-to-IP SIP call (as your provider will be doing to send a call to you), is there even a syntax to specify an alternate port? Asterisk does have one, but it's far from obvious that everything else does. You might be able to get an alternate port to work for outgoing calls only on one of the devices.
To take another example, if I set up an *EMAIL* server on an alternate port, I may be able to specially set up one of my servers to forward mail there (MX records do not include a port number), but there is no way to write an email address to get most of the servers in the world to forward mail there (e.g. email@example.com:26 doesn't work as an email address on most servers). I'd have to arrange for the mail to be routed through a server that uses a conventional port number.
It is possible to set up SRV records to specify what port incoming calls come in on, if someone is calling using a domain name to dial. However this does not allow specifying two different ports where the caller is supposed to intelligently choose which one to used based on precognition. Providers usually figure out where to send the call based on registration, which may not track port numbers.
I presume here that you have *ONE* public IP. This is part of the problem.
An unlocked Sipura 3000 can be configured for an alternate port on your end. A locked one might also be configurable as to port number. The problem is more likely on their end, which does not consider the port to connect to on an outgoing call to be a variable.
Gordon L. Burditt