How to conservatively translate "open these ports in the firewall" requests?

Kimputer: Thank you!
Well, just to be clear, the information that I provided comes from a VOIP provider - it's their information and I have no control over it.
The VOIP server (if I understand at all what this means) is outside.  Well, all we have are telephones and that's it.  Perhaps you mean the VOIP PBX?  I've seen those both ways but most cases I'd be dealing with, it is outside.

What I have to do is to set up the local firewall so that:
1) VOIP works
2) the firewall settings aren't sloppier than needed for (1).

So, now I'll translate what you said:

VOIP Provider sez: The full network information for the VoIP system is: Port Range (Audio): 35000-65000 UDP

That's a sloppy range. The VOIP system should do much better.
Limit it to a narrower range - I can't change what they said here.
Make it clear if it's source/dest (and thereby incoming or outgoing).  I sure agree that it would be helpful for them to say.

VOIP Provider sez: Port Range (SIP): 5060 UDP, 5061 TLS

It depends if the VOIP server is inside your LAN or not. If yes, it's incoming. If not, it's outgoing.

Since it's outside the LAN then it's outgoing and not needed (to be dealt with in firewall settings) at all.

VOIP Provider sez: Port Range (Configuration Servers): 1024-65536 TCP source port, TCP Destination ports: 80, 443, 1443, 2443, 6716,
Again, ridiculous port range. Assume it's outgoing though.
Again, if outgoing then no special firewall settings needed.  But, if THEY said "outgoing" then we'd know for sure.  In truth, I have asked about 80 and 443 in the past as was told it was needed incoming with the server outside.  Not that the answer I got was correct but it sure was conservative for THEM.

VOIP Provider sez: Port Range (Presence Servers): TCP Destination ports: 5222 and 5280.
It depends if the VOIP server is inside your LAN or not. If yes, it's incoming. If not, it's outgoing.
Again, if outgoing then no special firewall settings needed.  But, if THEY said "outgoing" then we'd know for sure.  

Generally speaking, you have to do research for each request. Usually, if it's to reach a server inside your network, it's incoming. If it's because the users have a client app, it's usually outgoing.
Right.  But what's harder to ascertain is whether they might be trying to use incoming ports and whether their point of contact knows the difference.....  In most of the cases I run into, the whole thing is a bit of a nuisance for me and the people I have to deal with are often fairly clueless in that they simply pass on the information that they've been given.  Not to be disparaging as they are nice people and we both have our jobs to do.  My point is that the "research" is often difficult.  The same set of issues come up when visitors are going to be using their own VPN to "phone home".

Also, in most situations, I don't filter outgoing, except port 25 to prevent spam. If you have the same logic, you don't really have to pay attention to any request that's for outgoing ports.
Yes, that's what I've been doing.

My belief is this:
They tell us that certain ports have to be open.  
This could include all the outgoing ports that are already open.
But, without information, we'd have to open the same incoming port numbers with no legitimate purpose.
The specifier is being conservative in making it easy for his/her people and app's -  to the detriment of the firewall.

The main thing I ask when I get the "I need the fw rule to be Bi-directional" request is "Which side is initiating the connection?"  This seems to always clear things up with app or system folks.

Yes, the direction is the main issue. What the provider tells is too unspecific. BTW, I think TLS is a typo and means TCP, as TLS is  SSL and can use both UDP and TCP.

If you cannot get the "issuer" to provide more detailed information, you need to do your own research on each individual protocol used.
E.g. SIP is used for signaling phone calls, with a fixed target port (which means outgoing phone port X to PBX port 5060/5061 and incoming PBX X to phone 5060/5061).
And a port range of 1024-65535 of course means "all ports", usually for the source port.

Note that your firewall needs to be SIP aware (because the phone IPs get NATted), or the phones have public IPs not getting translated-

Setting up VOIP traffic can get very complex and flaky. Usual issues are calling/signaling works, but no voice is heard, as there are two audio streams often using UDP with unspecific ports.

VOIP 5060 UDP (unencrypted SIP), 5061 UDP(Encrypted SIP) and 5060 TCP (Both unencrypted/encrypted(TLS) SIP over TCP).

This is from a phone in the direction of a PBX.
A PBX will return the the traffic to the IP address/Port that was given during registration.
Be aware that in the case of NAT the SIP registration timeout should be well below the NAT timeout. (Otherwise you cannot be called again if the NAT entry expires.)

The Audio ports are a given and should be setup as UDP bidirectional (The are negotiated during SIP CALL setup).

A SIP ALG can be used to proxy for the portnumbers BUT very many ALG's are flawed of don't cooperate well with a given PBX. A serious PBX will be able to handle FENT (Far End NAT) without ALG.
if the PBX is off-premises (Outside) then all port 80, 443, etc. are in the direction of the PBX, your VOIP provider SHOULD know the difference.

Onsite or cloud PBX? That is going to help majorly in figuring out this mess. I have seen vendors give big lists of firewall ports without citing which systems those ports should be open on until they get pressured.

A lot of good points have been brought up already (namely the vagueness on the part of the vendor from what you have presented), and it is concerning that the telephone people don't seem to be able to answer whether the ports they are asking about are in or outbound.

But having that answer of onsite of cloud, as well as they type of PBX (if known) would be a possible way of getting around their lack of clarity.

masnrock:  Good point!  Of course, *we* generally know if the PBX is internal or external but what they tell us may not differentiate and we may assume that it must be tailored to our situation.

Thanks all!  Great answers!  Very helpful - and supportive!