Other Border Devices

The following border devices are known to work with QMS with minimal custom configuration required:

Ribbon

OpenScape Branch

  • The Session Recording Client Protocol must be set to TCP, rather than UDP.

  • The OPUS codec is not supported and must be removed as an option from the phone settings.

  • Internal calls between two QMS agents may not always be recorded.

Dialogic

  • Support is limited to two-party call scenarios

Khomph

  • Support is limited to two-party call scenarios

TE-Systems Anynode

  • The Anynode SBC doesn’t send calling and called party audio in separate RTP streams, instead it sends stereo audio with left and right channels in a single RTP stream labeled with a dynamic payload type. QMS can record this audio and separate it into two RTP streams for advanced call processing where QMS requires distinct agent and remote streams. Enabling this feature requires setting the SeparateStereoPCMAOnPayloadType in the Advanced Settings section of the Recording Service tab to the value of the dynamic payload the SBC will code the audio as. The SBC must code the stream as stereo PCMA and consistently name the payload type of this audio with the payload type configured in SeparateStereoPCMAOnPayloadType.

  • Support is limited to two-party call scenarios on Anynode.

Other RFC 7866 Compliant Devices

It is possible to use an SBC that isn’t explicitly listed as being supported to record two party call scenarios as long as the device complies with some basic rules detailed in RFC 7866.

  • The XML that makes up the SipRec portion of the conversation metadata must be well-formed. If a wireshark trace at the QMS host shows Sip traffic from the SBC, but no Sip responses from QMS that indicates a problem parsing the SipRec conversation.

  • The device must stream a supported audio type using a standard payload type. Supported type are PCMU as type 0, PCMA as type 8, G.722 as type 9 and G.729 as type 18.

  • The device must represent the parties in a call using a single SipRec session where there are two audio streams, one for the calling party and the other for the called party.

  • The device must consistently order the participants so either the calling party is listed as the first participant or the called party is listed as the first participant. RFC 7866 states the calling party will be the first participant. The expectation that the calling party is the first participant can be reversed so QMS assumes the called party is first by setting the SBCAssumeInboundOnQMSAnchor value to true in the Advanced Settings section of the Recording Service tab.

  • If the device doesn’t order participants according to the RFC the device would need to be capable of attaching custom headers on the Invites sent to the SRS and programmed to do so. The names of these custom headers are OriginatingTo, and OriginatingFrom and each must contain an AOR similar to the AOR named in the participants. If the custom headers are present QMS will use them to determine call direction where the participant matching the OriginatingTo is assumed to be the called party and the participant matching the OriginatingFrom is the calling party.

  • QMS attempts to identify the type of the SBC communicating with it and applies logic and varying call treatment based on the SBC type. It’s unlikely a border device not supported would be identified as one of these supported devices, but in the case it is a QMS can be forced to treat calls from the device using the default treatment by setting SiprecForcedFlavor to value RfcDefault in the Advanced Settings section of the Recording Service tab. The SBC type identification is visible in the Call Recording log on lines that state "Processing new invite" and is listed as the "flavor".