It's a Cisco best practice to use a voice vlan, but from a pure technical perspective it should work fine. I would encourage you to at least use a dedicated voice vlan subnet and not mix data and voice subnets, though.
With all but the oldest switches (3524XL, 5500s, ETC) you don't need to configure the switch ports as trunks with the "switchport mode trunk" command. As long as you have the following commands the phones will work fine.
switchport access vlan 160
switchport voice vlan 260
So, I think you should consider setting all of your ports up this way just for the fact that you can place either a phone or a data device on any port on the switch. The data device will automatically be placed in the access vlan and if a phone happens to be placed there, then with the help of CDP, it will dynamically create an 802.1Q trunk and use the voice vlan. This also gives you the future capability to use a single cable solution if you wish without any reconfig.
Also, layer 2 QoS will only work over a trunk. If you set up the ports as standard access ports, then you will need to configure them to trust DSCP values from the phones. This gives the possibility of a smart user connecting to one of these ports with a PC and setting all of his traffic to use say DSCP EF. In that scenario your switch would trust that traffic from the PC and possibly cause qos issues with the rest of your phones. Not very likely, but a possibility. If you set up your switch ports to trust COS, then you don't have that problem.
Just thought I would add this reference doc to the great info you have received from Robert and Chris;
When you deploy voice, Cisco recommends that you enable two VLANs at the access layer: a native VLAN for data traffic and a voice VLAN under Cisco IOS or Auxiliary VLAN under CatOS for voice traffic.
Separate voice and data VLANs are recommended for the following reasons:
Address space conservation and voice device protection from external networks
Private addressing of phones on the voice or auxiliary VLAN ensures address conservation and ensures that phones are not accessible directly via public networks. PCs and servers are typically addressed with publicly routed subnet addresses; however, voice endpoints should be addressed using RFC 1918 private subnet addresses.
QoS trust boundary extension to voice devices
QoS trust boundaries can be extended to voice devices without extending these trust boundaries and, in turn, QoS features to PCs and other data devices.
Protection from malicious network attacks
VLAN access control, 802.1Q, and 802.1p tagging can provide protection for voice devices from malicious internal and external network attacks such as worms, denial of service (DoS) attacks, and attempts by data devices to gain access to priority queues via packet tagging.
Ease of management and configuration
Separate VLANs for voice and data devices at the access layer provide ease of management and simplified QoS configuration.
To provide high-quality voice and to take advantage of the full voice feature set, access layer switches should provide support for:
802.1Q trunking and 802.1p for proper treatment of Layer 2 CoS packet marking on ports with phones connected
Multiple egress queues to provide priority queuing of RTP voice packet streams
The ability to classify or reclassify traffic and establish a network trust boundary
Inline power capability (Although inline power capability is not mandatory, it is highly recommended for the access layer switches.)
Layer 3 awareness and the ability to implement QoS access control lists (These features are required if you are using certain IP telephony endpoints, such as a PC running a softphone application, that cannot benefit from an extended trust boundary.)
Spanning Tree Protocol (STP)
To minimize convergence times and maximize fault tolerance at Layer 2, enable the following STP features:
Enable PortFast on all access ports. The phones, PCs, or servers connected to these ports do not forward bridge protocol data units (BPDUs) that could affect STP operation. PortFast ensures that the phone or PC, when connected to the port, is able to begin receiving and transmitting traffic immediately without having to wait for STP to converge.
From this CCM SRND doc;
Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x
I am going to disable all the IP phone PC port, so it is impossible to have data traffic in the "voiced" VLAN.
I planned to setup regular data vlan for voice traffic, and all ports connecting IP phones will be setup as "Access" instead of "trunk".
to do this, the challenge part is from Qos, and access port will have no sense about the Cos value, therefore, I need to do more configuration on the switch to "override" the Cos/DSCP value from the real data port, and map some DSCP value (EF) to the traffic for voice.
at switch uplink port (trunk), I need to classify those traffic and put the traffic to different queue.
Just want to add one small practical point to address your concern about QoS. In LAN designs, at 100 / 1000 speeds, QoS for voice is very rarely a real concern. That is, in order to have quality issues, things should go so wrong, that not only the voice would suffer.
You can configure all the queues you want, but they are destined to stay empty all the time :)
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...