[cisco-voip] FW: CCM Trace - MAC & IP: Source/Dest?
Daniel Rodriquez
drodriguez at fidelus.com
Wed Mar 12 11:25:29 EDT 2008
Wes:
Thank you so much for the detailed response. So it’s safe to say that using the TCP Handles within a CCM trace (0044522 in this case) would only be reliable if the SCCP message was received by CCM from the endpoint, correct? For example, the OffHook SCCP message shows the TCP Handle matched with the correct IP and MAC of the endpoint. However, the startMediaTransmission message FROM CallManager with the 0044522 TCP Handle shows the IP and MAC for the other endpoint. In this case, it would be best to look further into the trace file entries and use knowledge of SCCP signaling in order to determine exactly what’s going on..?
Thanks again Wes.
-Daniel-
From: Wes Sisk [mailto:wsisk at cisco.com]
Sent: Wednesday, March 12, 2008 11:06 AM
To: Daniel Rodriquez
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] FW: CCM Trace - MAC & IP: Source/Dest?
Hi Daniel,
Unfortunately not true. The 'event correlation tags' appear at the end of SDI trace lines and also embedded in SDL trace lines. The original idea of correlation tags was to trace events back to the device/event that originated. As you can see in your example they are moderately reliable. In my own personal parsing I only 'trust' the correlation tags for certain messages where I know they are correct, station OffHook for example.
I use offhook to then identify the TCP Handle of the SCCP device, 0044522 in your case. Then I follow that TCP handle to see all SCCP events to/from that endpoint.
Unfortunately this does not work for SIP, MGCP, or H.323.
For SIP I still do not have a clear answer. Every endpoint sets up multiple 'dialogues' so the dialogue for SIP keepalive uses different text than the dialgogue for a SIP call. No easy way to follow through all events for a specific SIP endpoint. I've had moderate results following the device IP because it is printed in every SIP message if you are running detailed traces.
For MGCP I usually follow the endpoint identifier. There is another trick as well. The q.931 call identifer for d-channel backhaul matches the connection identifier in the MGCP traffic. This allows matching q.931 events to MGCP messaging.
For H.323 follow the GUID in asn1 decode of detailed traces. This shows all h.225 events for the call. For h.245 follow the TtPid. You have to use asn.1 or SDL to match the h.225 to h.245 by the h.245 port number. once you have the h.245 TtPid grep the SDI traces:
TtPid=(4,100,14,61) -Outgoing -value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
TtPid=(4,100,14,61) -Outgoing -value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
TtPid=(4,100,14,61) -Outgoing -value MultimediaSystemControlMessage ::= request : closeLogicalChannel :
TtPid=(4,100,14,61) -Incoming -value MultimediaSystemControlMessage ::= request : closeLogicalChannel :
...
TtPid=(4,100,14,61) -Incoming -value MultimediaSystemControlMessage ::= response : terminalCapabilitySetAck :
/Wes
Daniel Rodriquez wrote:
Mornin’ folks:
Anyone happen to have any input on this?
Thanks ahead of time for your help.
-Daniel-
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Rodriquez
Sent: Tuesday, March 11, 2008 12:29 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] CCM Trace - MAC & IP: Source/Dest?
Hello and good afternoon:
I have a few questions regarding CCM traces. I’ve read through my fair share of trace files but I recently noticed something within CCM traces that doesn’t quite make sense to me. Below is an excerpt of a CCM trace for an on-net call. The calling device is SEP001C58A2B308 (DN 3500/Line1_RTP – IP 192.168.102.175) and the called device is SEP001C58F075EA (DN 3037/Line1_RTP – IP 192.168.102.203). I’ve omitted a large portion of the trace and only included relevant lines. Questions listed below trace lines.
::::: Note the message ID, MAC, and IP ::::
::::: Calling party pressing NewCall softkey ::::
03/07/2008 12:01:21.055 CCM|StationInit: (0044624) SoftKeyEvent softKeyEvent=2(NewCall) lineInstance=1 callReference=0.|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362322><IP::192.168.102.175><DEV::SEP001C58A2B308>
03
::::: Msg ID stays the same ::::
::::: CCM instructing phone to display “Enter Number” on LCD screen ::::
03/07/2008 12:01:21.055 CCM|StationD: (0044624) DisplayPromptStatus timeOut=0 Status='€ ' content='Enter Number' line=1 CI=16777355 ver=8570000c.|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362322><IP::192.168.102.175><DEV::SEP001C58A2B308>
::::: Skipping traces… CCM tells phone to play inside tone… user dials “3037”… DA matches correct DN/partition ::::::::::::::::
::::: CCM checks busy trigger of called device… CCM instructs called phone to display “From 3500” on LCD screen :::::
::::: CCM instructs called phone to play inside ring :::::
::::: NOTICE the message ID change for the new call leg. In addition, notice how the MAC and IP add are kept the same when this is clearly destined for the called device :::::
03/07/2008 12:01:23.805 CCM|StationD: (0044522) DEBUG whatToDo: busy trigger not hit... send to open appearance|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362326><IP::192.168.102.175><DEV::SEP001C58A2B308>
03/07/2008 12:01:23.805 CCM|StationD: (0044522) DisplayPromptStatus timeOut=0 Status='€_3500' content='From 3500' line=1 CI=16777356 ver=8570000c.|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362326><IP::192.168.102.175><DEV::SEP001C58A2B308>
03/07/2008 12:01:23.805 CCM|StationD: (0044522) SetRinger ringMode=2(InsideRing).|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362326><IP::192.168.102.175><DEV::SEP001C58A2B308>
::::: Called party answers call :::::
::::: Notice the MAC and IP changes for the called device :::::
03/07/2008 12:01:28.695 CCM|StationInit: (0044522) SoftKeyEvent softKeyEvent=11(Answer) lineInstance=1 callReference=16777356.|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362329><IP::192.168.102.203><DEV::SEP001C58F075EA>
::::: CCM instructs calling device to start sending RTP packets to called device :::::
::::: Notice myIP is .175 (calling device) and remoteIP is the called device, but the IP and MAC at the end of the trace shows the called device :::::
03/07/2008 12:01:28.805 CCM|StationD: (0044624) startMediaTransmission conferenceID=16777355 passThruPartyID=16777905 remoteIpAddress=cb66a8c0(192.168.102.203) remotePortNumber=26544 milliSecondPacketSize=20 compressType=4(Media_Payload_G711Ulaw64k) qualifierOut=?. myIP: af66a8c0 (192.168.102.175) mediaEncryption algorithmID=0 keylen=0 saltlen=0|<CLID::StandAloneCluster><NID::192.168.102.11><CT::1,100,126,1.362331><IP::192.168.102.203><DEV::SEP001C58F075EA>
QUESTIONS:
For sent StationD and received StationInit SCCP messages, aren’t the IP and MAC addresses located at the end of the trace line supposed to specify the source or destination of the message? As you can see above, CCM was instructing the called device to display “From 3500” on its LCD screen, yet the MAC and IP addresses at the end of the trace line was for the calling device. I thought the message identifier would be consistent with this information too.
The Cisco IPTT book mentions that TCP Handle are assigned to IPT devices upon boot up and can be tracked by searching through keepalives. Am I correct to assume this was removed from CCM traces at some point? I always review CCM traces when logging levels are set to Detailed, yet I fail to find the TCP Handles anywhere within the trace files.
Thanks ahead of time for your input on this!
Daniel Rodriguez, CCVP
Fidelus Technologies, LLC
240 West 35th Street | 6th Floor | New York, NY 10001
o: 212.616-7843 | c: 917-797-2543 | f: 212.616-7850
e: drodriguez at fidelus.com<mailto:drodriguez at fidelus.com> | www.fidelus.com<http://www.fidelus.com>
[cid:image001.jpg at 01C88433.C6D25210]
________________________________
NOTICE: This e-mail and any attachment contain confidential information that may be legally privileged. If you are not the intended recipient, you must not review, retransmit, print, copy, use or disseminate it. Please immediately notify us by return e-mail and delete it. If this e-mail contains a forwarded e-mail or is a reply to a prior e-mail, the contents may not have been produced by the sender and therefore we are not responsible for its contents.
This notice is automatically appended to each e-mail. It is the recipient's responsibility to take measures to ensure that this e-mail is virus free, and no responsibility is accepted by Fidelus Technologies LLC for any loss or damage arising in any way from its use.
________________________________
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20080312/5b634962/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2185 bytes
Desc: image001.jpg
Url : https://puck.nether.net/pipermail/cisco-voip/attachments/20080312/5b634962/attachment-0001.jpg
More information about the cisco-voip
mailing list