Your configuration is not from a WAN port but from a LAN port. Please note that just because the service provider hands you an Ethernet port, that does not mean you can use any old LAN switch to connect to it. The service provider is using Ethernet to keep their costs down but it is still a WAN port and requires a WAN interface on your terminating equipment to properly schedule and queue the traffic.
Examples of a WAN Ethernet (FastEthernet, GigabitEthernet) port are most any ISR router, a Catalyst Metro switch (i.e. 3750-METRO), the WAN blades on a 6500 switch (not LAN blades!), or the Ethernet WAN/Metro SPA adapters for a 6500/7600 SIP module.
Note that a LAN switch assumes high speed interfaces and not much of a speed mismatch between ports. A LAN port connected to a slow WAN will not be able to buffer anywhere close to amount of traffic that comes through the switch to this port and will cause a HOL (head of line) blocking scenario; and this assumes you setup the port speed and shaping/sharing parameters correctly.
A LAN switch port output buffers are measured in K and will handle 4 to 10 packets of bursting; on the other hand, a WAN port's output buffers are measured in M and will handle thousands of packets of burst.
The effects can be staggering. It is not uncommon for a service provider WAN/MAN to be terminated with a bunch of cheap LAN switches that drop upwards of 90% of the traffic destined for the WAN! Just because of lack of buffers on the output queue side and massive oversubscription between the LAN side and the WAN side, using a LAN port.
And we haven't even started talking about traffic shaping yet to match the speed of transmission from a WAN port to that of the contracted rate such that it doesn't exceed the speed on the receiving side.
Remember, regardless of the size of the WAN port (T1, E1, DS-3, OC-3, 10Mb, 100Mb, 1000Mb), the 'width' of the connection is serial and still only 1 bit wide. Just the rate of bits being sent per second is different.
The key concept that often gets lost is if you have a GigabitEthernet port on a LAN switch connected to a WAN or MAN in which you are purchasing 200Mb of service, you are, by definition, dropping 80% of the traffic in the service provider network (or at the ingress port to the service provider!). This is regardless of how 'busy' or utilized the GigabitEthernet link is. A single packet of data, say 500 bytes, will be sent out the GigabitEthernet port at 1 *billion* bits per second. Unfortunately, you may only have paid for 200 *million* bits per second as your contracted access to the service provider's network. Trust me, the service provider will deal with this discrepancy by policing 80% of your data to the bit bucket and they don't care what type of data it is.
So it doesn't matter how much data you are sending, a 1% utilized WAN connection using a LAN switch in this way could still be dropping 80% (or more) of the traffic!
A final note: Please don't be confused by most switch vendor's terminology regarding shaping or sharing of multiple limited output queue resources on their LAN switches, this is *NOT* the same thing as traffic shaping or long queues on a WAN router port or WAN/METRO switch port. This includes Cisco. This is why Cisco (and Juniper and Foundry, etc.) sell switches with METRO or WAN interfaces on them and why they are more expensive than LAN only switches.
We figured out why only one side was receiving the video. The Polycom V500 has feature to NAT so that external users will access via its public IP address. Since we are not using this via the WAN, we disabled this feature et voila!!!
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...