Skinny Protocol : Call Ender (who ended the call first)

[haouaswajih]

Dear Networkers,

First, happy new year 2013

We're using CUCM v8.5

I would like to know; if the SCCP (Skinny Call Control Protocol) gives me the information about the call ender (who ended the call first).

I tried to make several Packet captures using Wireshark for a simple Call, but I was not abale to see such information while analysing the traffic.

Can you please advise ?

Thanks in advance.

[Jaime Valencia]

Yes, just look at who sent the hang up event first.

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Ayodeji Okanlawon]

One way I can think of is to look at CUCM traces. You can look at the tcp handle assigned to each phone and with that you can see who ended the call first

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Martin Gottfried]

Hi haouaswajih,

you can analyze the CDRs as well. There you are able to see practically whole trace of each call (which device called, which port was used, how long the call took, time of ringing, etc.).

However, for better overview of the traffic it is good to use some tool/app like call accounting.

But this is not real-time lookup to the traffic.

I can recommend 2Ring's Call Accounting app, for more info follow the link: http://www.2ring.com/ca.

HTH

Martin

[Harmit Singh]

Hi haouaswajih,

Not sure where you took the packet capture from. If you do a packet capture on the UCM which controls both IP phones, you would be able to see which phone sent the onhook / endcall event first. Here is how you can take a packet capture on the UCM:

https://supportforums.cisco.com/docs/DOC-11599

The CLI command (explained in the above doc) I use is:

utils network capture file count 1000000 size all

Note: Do not add the extension to the filename.

I've attached some screenshots I took for a wireshark capture I took from a UCM node which had 2 IP Phones registered to it. It clearly shows you which IP Phone hit the EndCall softkey.

I've also attached CUCM trace analysis screenshot for the same call. Like my friend Deji rightfully said (+5), you can search for the call using the TCP handles. The 1st phone to send a stationinit with the EndCall softkey event, you know that IP phone is the one who disconnected the call.

HTH.

Regards,

Harmit.

[Aaron Harrison]

Erm... why look at the packets to see who hung up first? May as well put in cameras and watch the users :-)

The info is in the CDRs, so turn on CAR and look at origCause_value and destCause_value. Usually if the caller hung up

origCause_value will be 16, and destCause_value will be 0. If the called party hung up the values will be the other way around.

Regards

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

[haouaswajih]

Hi all,

thanks for your responses.

Please allow me to clarify why I am asking this.

We have CUCM v 8.5 installed in UCCE v8.5 context.

We have a Quality Management application used for recording and qualifying the agents calls. The applications uses the SPAN configuration on the switch to sniff the IP Phones traffic in order to record the calls.

The Application has also a reporting field which shows some amout of information regarding the calls. One of the fields is "Call Ender" or who ended the call, is it the customer or the agent.

We noticed that this field is not giving the correct information of the call ender. The application developper said that he is referring to skinny protocol sniff which is not showing the right info.

So we're obliged to use the Skinny protocol.

I used wireshark to sniff the skinny packets, but couldn't find the information saying who's the one that is ending the call first.

Can you please advice.

Thanks for your help.

[Aaron Harrison]

Hi

Well - you really need to find out what the developer has used to make that determination. There may not be a field in the packets that says 'This user hung up', but you could infer that if you receive a 'close logical channel' or some such before you send a softkey event of 'end call' that the far end hung up. There could be lots of ways to make the determination of who disconnected.

Programs like wireshark have decoder modules for each protocol, and they aren't always up to date - SCCP packets change between different versions of CUCM and the phone firmware, so you don't always get accurate decodes in WireShark, especially with new versions of CUCM.

Your developer may be decoding the packets himself from a raw sniff, or might be using some third party code... really it doesn't matter too much as only they will be able to fix it. If they claim to support your version of CUCM then they should be happy to investigate and fix it.

Aaron

[William Bell]

If we are talking 100% SCCP (station-to-station) and the party ending  the call uses a softkey (i.e. EndCall) then a protocol trace will  identify the station that ended the call with a SoftKeyEventMessage  command. In the SCCP decode, you will see event ID 9 (EndCall).

If the party ending the call hung up by putting the  handset on the cradle or selecting the speakerphone button then that  station will send a SCCP packet with a OnHookMessage command.

Following  these events, the CUCM call processing agent(s) will begin the process  to tear down the call. A series of SCCP messages are sent to both SCCP  stations. You will see ClearPromptStatus, SetLamp, SelectSoftkeys, and  other status messages/commands. The important ones are the  CloseReceiveChannel commands as that tears down the media stream.

But  getting back to your question, in a SCCP station-to-station call the  message which indicates that the call is being terminated is either the  SoftKeyEventMessage (ID 9, EndCall) or the OnHookMessage from the  station terminating the call.

When you get into  multi-protocol (i.e. SIP to/from SCCP) calls and calls that involve a  gateway, then your application would need to have the ability to decode  SIP, MGCP, H.323, etc. to catch the call tear down event. Further, your  application would need to see all call controll messages related to said  event. You won't get that kind of coverage by simply SPANning the agent  phones. You may need to see the messaging to/from the CUCM.

As Aaron noted (+5 A.H.), it really comes down to what your QM app is looking for. It could trigger on specific messages for specific protocols or it may infer what happened given the absence of a specific message in the context of other messages it sees. The app may use some other method like looking for a ConnectionStatisticsReq or Res and then running a CDR query to piece the metadata together.

HTH

-Bill (http://ucguerrilla.com)

[Aziz Ali]

So if you look at the SDL traces, you will see StationInit: which represent that OnHook message came from ipPhone with MAC CN90734UCM9CIPC and IP-Address 10.202.56.196. I hope this answer your question

SCCP OnHook

94877777.001 |15:34:22.602 |AppInfo |StationInit: (0006579) OnHook.

94877778.000 |15:34:22.602 |SdlSig   |StationOnHook                         |restart0                       |StationD(2,100,58,6579)        |StationInit(2,100,57,1)         |2,100,13,257093.353^10.202.56.196^CN90734UCM9CIPC |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Line=0 CI=0 trigger=1 SsName=Unknown

94877779.000 |15:34:22.602 |SdlSig   |StationOnHook                         |active10                      |StationCdpc(2,100,59,711325)     |StationD(2,100,58,6579)         |2,100,13,257093.353^10.202.56.196^CN90734UCM9CIPC |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Line=1 CI=47365753 trigger=1 SsName=Unknown