I am looking into a strange issue. We use a SIP-based recording integration to fork audio to a third-party archiving system for compliance. The SIP REC (SIP Recording) session initiates correctly when the agent connects, but if the call is placed on hold and then retrieved, the recording on the archiving system often has blank audio for the remainder of the call. I suspect the media path is changing after the hold state, but the SIP REC session is not updating. How does Genesys Cloud handle media renegotiation (re-INVITEs) during hold states for external SIP recording trunks?
this is a massive compliance risk for us! If those recordings are blank, we fail our PCI-DSS audits. The issue is usually that the SIP REC endpoint (your archiving system) does not support the specific SDP attributes that Genesys Cloud sends in the re-INVITE after the hold is removed. Genesys Cloud often changes the RTP port or the media IP when pulling a call off hold from the Edge. If your recorder ignores the re-INVITE, it keeps listening on the old port, resulting in dead air.
I am leading our migration from PureConnect and we had this exact problem with our legacy recorders. To expand on 's point, you should take a PCAP on your Edge and look at the SIP signaling during the hold and retrieve actions. You will likely see Genesys Cloud send a sendrecv SDP attribute when taking the call off hold. Some older recorders expect a different sequence. You might need to adjust the “Media Tie” or “Media Bypass” settings on your trunk to force the media to remain anchored on the Edge, which prevents the RTP ports from changing during the hold state!