[VoiceOps] Broadworks / Merging calls with Voipmon

Zilk, David David.Zilk at cdk.com
Mon Jan 22 16:21:33 EST 2018

In my experience the leg gets identified by the correlation ID that broadworks adds to the responses associated with the original INVITE. VoIPmonitor will use that to complete the correlation.

From: Matthew Crocker [mailto:matthew at corp.crocker.com]
Sent: Monday, January 22, 2018 1:19 PM
To: Zilk, David <David.Zilk at cdk.com>; Matthew Beckwell <matthewb at aitech.net>; voiceops at voiceops.org
Subject: Re: [VoiceOps] Broadworks / Merging calls with Voipmon

Thanks David,

The Broadworks Correlation Id is enabled but the original INVITE from the end-user (Polycom) doesn’t have it so voipmon isn’t picking it up (which make sense).  I was hoping there was a way for Broadworks to pull something out of the original invite for tracking.

Selecting both calls in voipmon and merging works, just doesn’t merge auto-magically


Matthew Crocker
Crocker Communications, Inc.
From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of "Zilk, David" <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>>
Date: Monday, January 22, 2018 at 4:11 PM
To: Matthew Beckwell <matthewb at aitech.net<mailto:matthewb at aitech.net>>, "voiceops at voiceops.org<mailto:voiceops at voiceops.org>" <voiceops at voiceops.org<mailto:voiceops at voiceops.org>>
Subject: Re: [VoiceOps] Broadworks / Merging calls with Voipmon

If you click on the ‘Merge’ dropdown while displaying the Legs by Header, you can select ‘SIP History’ to display the SIP Ladder diagram of all the legs together.


From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Matthew Beckwell
Sent: Monday, January 22, 2018 1:02 PM
To: voiceops at voiceops.org<mailto:voiceops at voiceops.org>
Subject: Re: [VoiceOps] Broadworks / Merging calls with Voipmon

Hi Matt,
Here's what I've done to get close to what you're looking for...

In the BroadWorks Application Server, set these parameters:

sendCallCorrelationIDAccess = true
sendCallCorrelationIDNetwork = true

Once you do that, you'll see BroadWorks start to add a header for "related" calls. They will have have a common correlation header (but different call-id) like this:


Then, in voipmonitor.conf you can set this parameter in the sniffer configuration to keep track of that header's value in the database:

matchheader = X-BroadWorks-Correlation-Info

VoIPmonitor won't merge them into a single SIP Diagram (at least not that I've found)-- but you should start to see the "related" call legs (with different Call-ID's but the same X-BroadWorks-Correlation-Info header) show up in the "Legs by header" tab when you're looking at a call's details in the VoIPmonitor GUI.


On Mon, Jan 22, 2018 at 2:36 PM, Matthew Crocker <matthew at corp.crocker.com<mailto:matthew at corp.crocker.com>> wrote:


We currently have Broadworks/AcmePacket handling calls to/from customers.  We have a couple VoipMon sensors running watching all traffic inside/outside our SBC.   Currently calls are presented in VoipMon as two different calls (PSTN -> Broadworks & Broadworks -> Polycom) or (Polycom -> Broadworks & Broadworks -> PSTN).     The Call-id on each call is different,  Broadworks generates a new SIP Dialog for the call.   If the customer has a hunt group there could be several INVITEs going out to multiple phones, all with different Call-Id.     Does anyone know of a way to get VoipMon to merge the calls into a single CDR/SIP Diagram?  Is there a way to configure Broadworks to embed the original Call-Id in the new INVITE (Parent-Call-Id Header)?

I’m running R20sp1



Matthew Crocker
Crocker Communications, Inc.

VoiceOps mailing list
VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20180122/a2108492/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 202 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20180122/a2108492/attachment-0001.png>

More information about the VoiceOps mailing list