Hi, we've call-manager setup (1 publisher, 1 subscriber and 1 music-on-hold servers). Customer added a voice-recording server and thus I did some port spanning and destined all the traffics to the port where the recording server connected to our core switch.
Here's the config:
monitor session 1 source vlan xxx , xxx
monitor session 1 destin int <int_to_voice_recording_server>
the recording server vendor is complaining they can't see the traffics goes to the server, i tried to put on a sniifer (ethereal) and make some calls, i did saw the packets flow through but when I select the SKINNY protocol, highlighted on the "SelectSoftKeyMessage" and the vendor is complaining under the Skinny Client Control Protocol, they can't see the calling and called party, that's the main reason their software can't catch the call...
I just want to clarify whether its my ccm or my port spanning feature that cause the SCCP protocol doesn't equipped with calling and called party, anyone experience this problem before? kindly advise, thanks
SCCP will provide the information that the call recording needs to see such as calling name and number.
what is the call recording vendor? telRex?
their solution is easy and very effective.
(turn on SPAN for the VLAN and Oi'la!)
try to setup SPAN to span only one VLAN or port and test again. if successful, then you can continue to add more VLANs/ports to the SPAN.
if not successful, verify the Recording Server has the proper NIC plugged into the SPAN port. the call recording server may have two NICs. one for connection to the IP network for administration and one for connection to the SPAN port.
the SPAN port NIC does not require an IP Address, it only needs to be enabled.
(should not be able to ping the server NIC used for SPAN; if it is pingable, then the NIC is not plugged into the SPAN port or your SPAN is not operational)
use the 'show monitor' command to view the monitor/SPAN operation.
if all else fails, double check that your SPAN port is receiving the data by placing your sniffer into that port; place a call and then verify if the span port is receiving your phone traffic.
if the SPAN port does receive the phone traffic as seen by your sniffer, then there is an issue with the call recording server or its configuration.
the span port is receiving the phone traffic, but in the SKINNY protocol, i can't see any calling and called party...that's what the recording server vendor complaining about, i can't do anything as I saw the packets went through, but it does not tell the calling party number
the attached file is what i sniffed from the SPAN port...under the SCCP section, the vendor stressing it should have some calling party number so that their software can read it and display accordingly..is that true?
the single frame you have provided in your attachment is but one of many SCCP messages your connection will have. the shown frame does not have the 'callingPartyNumber' but there is a SCCP frame that does. it is the 'SKINNY CallInfoMessage' frame.
(you should see this frame afer the 'keypad button' frames, when the entire digit string has been entered and ccm performs its digit analysis)
the top seven lines of this frame contain the calling/called party name & number.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...