Any way to send SIP signaling to monitor device?

[aklassen]

My company develops a VoIP monitoring product which currently uses a TAP or monitor port on a router/switch to get a copy of signaling messages between communication devices and the CUCM, e.g. phones, SBCs, etc... This works fine unless the signaling is encrypted and then problems with decryption occur. I am looking for an alternative mechanism which would use something internal to the CUCM

to send the SIP messages, thereby side-stepping the issue with encryption.

I was reading through this forum and thought perhaps you might have some ideas about how to

have the SIP signaling duplicated and sent to an external device. I looked a little bit at LUA which seemed

to be a good candidate, but did not see anything.

Thanks for any thoughts on the matter,

Andrew

[Mark Stover]

Hi Andrew,

Lua (SIP Normalization) can be used to manipulate the SIP headers of the signalling, but it cannot be used by itself to fork the call. Have you looked at the recording interface of Unified CM for that? If you want to monitor the activity to a phone, that would be more of the CTI interface.

Mark

[aklassen]

Hi Mark,

Thanks for the suggestion. I looked at the description of the call recording interface and I am not sure if that is what I am looking for. It doesn't look like I would actually get the original signaling of the call being monitored, which is what I really want.

Can I get a copy of the original call signaling using CTI?

I noticed that the CUCM as call trace logs which can be enabled to include signaling. Is there anyway to

have the call trace logs sent to an external server like a syslog server for consumption? If so maybe I

could use that.

Thanks again for your help,

Andrew

[Mark Stover]

CTI would not have the original SIP signalling messages if that is what you are ultimately looking for. You can use the Serviceability XML interface to programmatically get CUCM traces, which is probably the least invasive way to do this. There is also a gateway API that can be used for things like monitoring traffic for voice spam that is available.

CUCM wasn't designed to send 'original' signalling to multiple locations unless you are forking calls...even then, you aren't getting the original signalling, you are getting the B2BUA signalling destined for your forked device.

I'm not sure which SIP headers or SDP you are looking for as part of the monitoring, so it is hard to say. For example, CURRI gives you calling/called and original calling/called numbers per call, but no SIP messages. There are a number of options, but I don't know that we have a single interface that does exactly what you want.

Mark

[aklassen]

Hi Mark,

Thanks for the reply and for trying to help me figure this out. I understand the SIP option is dead...

We would like to get the following information as close to real time as possible:

for calls which did not connect:

called/calling party number

failure reason

for successfully connected calls

called/calling party number

source/destination IP and port for media stream(s)

*codec type, RTP payload type (including comfort noise, dtmf etc... payload types)

call hold

call resume

call terminated

*if the mapping of RTP payload type to codec type is well known and reasonably static,

then we could handle this with configuration instead of discovery.

Realistically how "real" time will the use of the CUCM traces be? I took a quick look and it looks like within

minutes is probably possible. Can you configure file sizes to be reasonable size so that the transfer time is

manageable?

I started looking at TAPI regarding CTI. Is that what I should look at?

Thanks again,

Andrew

[Mark Stover]

Sorry for letting so much time go by. It's been a busy month for me.

From your list of things you are interested in, have you considered looking at Call Detail Records? The system can be configured to SFTP them to a server periodically.

For CTI, I would look into JTAPI, it's much easier to deal with from the server side.

Mark