Reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_recording_proxy.html

Using media proxy with the CUCM Call Recording leg - simplifies implementation.

• only designated agents with an updated Recording Profile on their CUCM Extension will get the call recording legs sent to the CUBE Media Proxy
• All calls for these agents will be sent to the recorder and the transcription server, i.e. inbound, outbound and internal (inter-agent) calls will work by default without any changes to routing.
• This retains existing call flows and should reduce SIP CUBE licencing requirements - since only the concurrent usage of the selected agents will require a license.

The Alternative is to use a CUBE between CVP and CUCM with SIPREC / Media Forking to send a copy of the call to the transcription server - which would work for inbound calls to the agents. But if we do not want all agent calls to get transcribed this makes configuration more difficult.

A key advantage is not having to have a dedicated CUBE. However currently if early offer is used then SRTP (Secure RTP) is not sent and this would likely be a reqiurement.

If outbound calls and inter-agent calls are also needed to be transcribed (sent to the cloud transcription server), then the call flow is complex and adds complexity to call flows requiring all calls to route via a CUBE.

• Inbound calls
  • use CUBE between CVP and CUCM
  • using e164 map and config file it should be possible to configure just the relevant extensions
  • https://community.cisco.com/t5/ip-telephony-and-phones/e164-pattern-map-maximum-patterns-supported/td-p/2614890
• Outbound calls
  • likely difficult it would need to match on ANI and not dialled number - more work needed.
• Internal Calls
  • All internal calls would need to route via CUBE but again needs to match on ANI and not Dialled number - more work needed.

There are issues / design flaws with using the media proxy which hopefully Cisco will fix in future versions of this product.

• The reference document above states one of the restrictions as Concurrent use with CUBE B2BUA SBC features. - from discussions with Cisco this means that the CUBE has to be 100% dedicated as a Media Proxy and cannot be used for any other CUBE calls - this is far from ideal - but one to watch for supportability.
• Mandatory dial-peer do NOT work once you have any secure dial-peers e.g. media-recording proxy secure 8002
  • You cannot use the mandatory policy command with secure forking configurations.
  • This makes my requirement that the call which routes to the on prem recorder MUST work otherwise it should fail, difficult. i.e. if the call fails CUCM would reroute to an alternative in its Route List e.g. a Secondary CUBE / Media Proxy or maybe direct to the backup RIS Server / Recorder. But this isn't possible with the mandatory feature.
• SIP Server groups are also not supported - but they work on the first dial-peer - but not others? To allow the media proxy to failover to an alternative recorder for resilence is a much needed feature - and could be achieved by support SIP server groups.
  • When using a mix of secure and non secure dial-peers - the secure dial-peer leg is attempted first. This dial-peer works when using SIP Server groups (but could cause Cisco TAC support issues).
  • When using non secure - the first dial-peer (I didn't test a second) can also use SIP Server groups.
    • Note - When using a mix of secure and non secure, the secure dial-peers always are attempted first.
    • when using secure and non secure - the second dial-peer (non secure in my example) does NOT work if using SIP Server groups.
    • So, it looks like the first dial-peer used can be use server-groups but not subsequent ones do not work (O don't understand why) - this missing feature would help improve resilience for this solution (i.e. most customers need this).
    • i.e. Customers need to use SIP Server groups to add resilience. i.e. they might need to send it a transcription solution, which has 2 servers for resilience or likewise to an on prem recorder solution which has a a Primary and Secondary Recorder. We do not want to send it to primary and backup. This capability could be so easily achieved if SIP server groups were supported.
• There is a Bug (waiting for BUG id) - that the dial-peer CANNOT use DNS as a session target. It malforms the SIP FROM header, e.g. instead of <sip:[email protected]; it gets written as <sip:1234@;
  • With DNS it might be possible to achieve some level of load balancing and resilience (if the bug didn't exist) but sip server groups would be a better option.

• Send a recording of a call to an on prem recording solution via the media Proxy, so you can also send a copy or multiple copies to alternative recorders / transcription solutions. In my use case - the alternative is to a cloud transcription service - which will summarise the call.

CUCM sends 2 x SIP one way audio calls to the on prem call recording platform

• CUCM → SIP → Primary Verint RIS Server (verint replies back with Verint Recorder address in SIP/SDP)
  • Agent Phone → RTP → Verint Recorder

CUCM sends 2 x SIP one way audio calls to the on Cisco CUBE Media Proxy

• CUCM → SIP → CUBE Media Proxy
  • Agent Phone → RTP → CUBE Media Proxy

• CUBE Media Proxy (dial-peer 8002) → SIPS → Cloud Transcription SIP Server
  • CUBE Media Proxy (dial-peer 8002) → SRTP → Cloud Transcription Media Server
• CUBE Media Proxy (dial-peer 8001) → SIP → Primary Verint RIS Server
  • CUBE Media Proxy (dial-peer 8001) → RTP → Verint Recorder

The Recording functionality of CUCM and it's phones allows a copy of the audio call to be sent to a Recorder.

• A copy of the call is created by setting up 2 x SIP calls to the recorder. Both of these calls are one way audio.
  • Call 1 - nearend - the agent's audio
  • Call 2 - far end - the customer's audio
  • Both of these SIP call contains the same Meta data (including CUCM Call ID of the call) in the From header which the recorder uses to link the two SIP calls into one stereo audio file. It can then use a CUCM CTI feed to tag the call with more info by using the Call ID to link the call to the feed from the CTI server.

Using the Media proxy - we can send calls to a CUBE instead or directly to a call recorder. The CUBE can then multiple copies of the call to a number of recorders (such as additional recorders or transcription services).

Example - send the call to the existing on prem call recording platform AND to a cloud recorder which could be used for transcription purposes.

With this example it would be typical that the call from CUCM to the CUBE (inbound dialpeer) as well as the outbound dial-peer to the on prem recorder would use SIP and RTP (non secure), while the dial-peer to the cloud recorder would typically require SIPS and SRTPS (secure).

How CUCM sends a call recordings from Agent's phone to an on prem Call recording platform such as Verint / Nice / Redbox etc.

• Call is connected on Agents phone
• CUCM sends the SIP invite to the Recorder (e.g. Verint RIS server)
• the Recorder responds with a 100 Trying and then a 200 OK with SDP which include with the codecs it supports, IP address, UDP ports that the CUCM should send the RTP (audio) to.
• CUCM responds with the codec it wants to use and the IP address where the RTP will be sourced from (in most cases this address will be Agent's phone which using its built in bridge, it could also be a Cisco gateway if using gateway Recording).

Example of one of the two SIP INVITE's which CUCM would to the Recorder for each phone call

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 123.123.123.100:5060;branch=z9hG4bKFBC714B7
Remote-Party-ID: "Telecoms_Agent_1 (Bob Bobster)" <sip:[email protected]>;party=calling;screen=yes;privacy=off
From: "Agent_1 (Bob Bobster)" <sip:[email protected];x-nearend;x-refci=17687488;x-nearendclusterid=ACME-TST-UCCE-V11;x-nearenddevice=SEP000700000009;x-nearendaddr=61001;x-farendrefci=17687487;x-farendclusterid=ACME-TST-UCCE-V11;x-farenddevice=UCCE-CUBE-A;x-farendaddr=+353858712345;x-sessionid=059a1ef36a92e7f3a278d8ba17687488>;tag=4B2E4382-2704
To: <sip:[email protected]>
Date: Mon, 20 Apr 2026 08:37:28 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE:  1800
Cisco-Guid: 0681531776-0522279575-0000005268-0673060874
User-Agent: Cisco-SIPGateway/IOS-17.12.5a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1776674248
Contact: <sip:[email protected]:5060;transport=tcp>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-ID: a39b6d59450b50fca557a2cef4fae6ab;remote=00000000000000000000000000000000
Session-Expires:  1800
Content-Length: 0

The Recording platform uses the SIP FROM Meta data header in the SIP INVITE which contains data such as the CUCM Call ID, Agent extension and Customer phone number. It uses the CUCM Call ID to link the call recording to the CTI events (i.e. it uses the Call ID to link). This enabled the recorder to determine more information about the call such as when the call has been placed on hold, the Calling Party Names etc.

In the above example SIP trace 17687488 is the reference call id.

For each actual Agent phone call - there are two SIP one way audio calls sent to the recorder (or CUBE Media Proxy)

• near end (agent audio stream).
• far end (customer audio stream)
• both calls have the same meta data in the SIP FROM header except that one stats its x-nearend; while the other would be x-farend;

The Call ID used in the SIP From Header, i.e. x-refci=17687488 is the

• GCH
  • Global Call Handle (often corresponds to the CUCM Global Call ID / GCID)
    • Identifies the overall call across related call legs. Remains consistent through transfers, redirects, conferences, etc.
• CH
  • Call Handle (Call ID / Call Handle)
    • Identifies a specific call leg or call instance seen by CTI. New call legs can get new CH values while still belonging to the same GCH.

Here is an example FROM header and a line from the corresponding CTI log showing bothe the GCH and CH IDs

From: "Telecoms_Agent_1 (Bob Bobster)" <sip:[email protected];x-nearend;x-refci=34446813;x-nearendclusterid=ACME-TST-UCCE-V11;x-nearenddevice=SEP0000000000F9;x-nearendaddr=61001;x-farendrefci=34446814;x-farendclusterid=ACME-TST-UCCE-V11;x-farenddevice=SIP-TRK-IPT-CUCM-AB;x-farendaddr=00851231234;x-sessionid=059a1ef36a92e7f3a278d8ba34446813>;tag=6246346~ca582c77-291a-4154-8668-282fb33b0cee-34446818

22887421.000 |09:40:04.921 |SdlSig-I |CtiNewCallNotify                       |ready                          |CTIDeviceLineMgr(1,200,13,1)     |StationCdpc(2,100,198,487)       |1,200,21,747.88107^10.123.123.6^SEP0000000000F9 |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0]  LH=1|1411 GCH=1|21278 CH=2|34446813 Held CH=0|0 State=4(CtiDialtoneState) Reason=1 Origin=4 DeviceName=SEP0000000000F9 CGPN=[ DN=61001 uDN=61001 NumPI=T Part=PH_STD_P VmBox= NumType=48 Name=Telecoms_Agent_1 (Bob Bobster) UniName=Telecoms_Agent_1 (Bob Bobster) NamePI=T Locale=33 PU=2 Device=SEP0000000000F9 GlblCgpn=] CDPN=[ DN= uDN= NumPI=F Part= VmBox= NumType=48 Name= UniName= NamePI=T Locale=1 PU=0 Device=] LRP=[ DN= uDN= NumPI=T Part= VmBox= NumType=0 Name= UniName= NamePI=T Locale=1] OCDPN=[ DN= uDN= NumPI=F Part= VmBox= NumType=48 Name= UniName= NamePI=T Locale=1] AuxData=F FarEndCMId=0 EndpointType=0 RIU=F Privacy=F CallPresent=T FeatPriority=1 Feature=0 AttrType=0 LineId [DN= Part=] IPAddrMode=3 IsConsCallDueToRollover=F UniqCallRef=000000000000531E020D9DDD00000000 CgpnIPv4Addr=0 CgpnIPv6Addr= CallingMultiMediaCap=0F0 CalledMultiMediaCap=0F0 CallingPartyMultiMediaMask=0 CalledPartyMultiMediaMask=0 Session-ID: Device= 059a1ef36a92e7f3a278d8ba34446813; Remote=  AlwaysDisplayOrignalDialedNumber=F OCDPN=[ DN= uDN= NumPI=F Part= VmBox= NumType=0 Name= UniName= NamePI=F Locale=1]

So for this call we have a:

• GCH = 21278
• CH = 34446813

We can see that the ID used in the FROM header is the CH ID and this is how Verint or any other Call Recording platform can use a CTI feed from CUCM to gather more data about the call.

When an agent places a customer on hold - the customer hears hold music. From a recording point if view, CUCM ends (SIP BYE) then 2 x SIP calls to the recorder and when taken off hold new calls are re-established with the same IDs.

Likewise with Consults and Conferences. i.e. when an agent first starts a consult call - the customer goes on hold (so the recording stops) - and then when they connect to the the consulted party - a call recording initiates again the call ends and gets re-established with each new change, e.g. from consult to conference (the far end address is updated with the conference bride ID).

Note: The Call Reference IDs seem to stay the same (for the test call that I made) for the duration of the complete call. Even though there are numerous seperate calls.

No - it is not possible.

In Cisco Finesse we can have a unique Dialog ID for each call. The Dialog ID is the same ID as the ICM/CCE Peripheral Call Key which is based on a GCH Call ID from CUCM.

The Finesse Dialog ID can be calculated by: (CUCM Node ID x 2^24) + GCH

In our example the CUCM node used to make the call was

• node ID 1
• GCH: 21278
• 2 ^ 24 = 16777216

So the Finesse Dialog ID / ICM Peripheral Call Key is calculated as: (1 x 16777216) + 21279 = 16798494

However this means that it is not possible to link the Dialog ID to the audio recording using the reference ID in the SIP From header. The audio recording reference ID uses the CH (Call Handler ID ) and not the GCH ID (Global Call Handler ID).

This means that the only thing we can do to link the call to the agent is the Agent Extension number. A Finesse Gadget could be created to push relevant data at agent login. example:

{ 
 "username" : "012345",
 "firstName": "Bob",
 "lastName" : "Bobster",
 "extension": "51001"
 "action" : "login"
}

Another request could be sent at logout.

It would be technical possible to send other events about call using a Finesse gadget but it would not be possible to link using the dialog ID directly to the recording.

Only the extension number could be used.

For example we could send details on call is active when it becomes active, on hold etc. But whether this could be linked by the Transcription service is not clear.

• If the Secure Dial-peer doesn't respond or is out of service then the other dial-peers are still attempted. In my test this is the non secure dial-peer.
• The EEM script will bring the backup dial-peer into service - however there will be a ~30 second delay in doing this - so this is not as good as SIP Server groups.

• if Secure endpoint doesn't request SRTP by default - we can send an early offer by using a SIP profile which adds a sdp-header “a=sendonly” …. add audio codec list which we know the agent phone will use (this works well if all calls are using G711 alaw etc).

voice class sip-profiles 8002
 request INVITE sdp-header Audio-Attribute add "a=sendonly"

This example config - uses Early offer to the Secure Endpoint - to enforce SRTP - as otherwise the far end is defaulting to RTP (not ideal - the far end SHOULD have an option to require SRTP).

!
voice class sip-profiles 8010
 request INVITE sdp-header Audio-Attribute add "a=sendonly"
!
voice class codec 8000
 codec preference 1 g711alaw
!
voice class sip-options-keepalive 8000
 description ### Verint TCP SIP options PING ###
 down-interval 10
 up-interval 5
 retry 3
 transport tcp
!
voice class sip-options-keepalive 8010
 description ###TLS SIP options PING###
 down-interval 10
 up-interval 5
 retry 3
 transport tcp tls
!
voice class srtp-crypto 8010
 crypto 1 AES_CM_128_HMAC_SHA1_80
!
media profile recorder 8000
 media-recording proxy secure 8011
 media-recording proxy 8001
!
dial-peer voice 8000 voip
 description Inbound CCE CUCM Recording Profile
 session protocol sipv2
 incoming called-number 70012
 voice-class codec 8000
 media-class 8000
!
dial-peer voice 8001 voip
 description Outbound Dial-peer to VerintRIS1 (On Prem Recorder)
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:10.1.1.101
 session transport tcp
 voice-class codec 8000
 voice-class sip options-keepalive profile 8000
!
dial-peer voice 8011 voip
 description Outbound Dial-peer to Cloud Transcription SIP Server
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:52.123.123.101
 session transport tcp tls
 voice-class codec 8000
 voice-class sip early-offer forced
 voice-class sip profiles 8010
 voice-class sip srtp-crypto 100
 voice-class sip options-keepalive profile 8010
 srtp
 no vad
!

EEM Script to needed to allow reslience since SIP Server Groups are not supported !!!! i.e. SIP Server groups seem to work on only work on first dial-peer. It is bonkers that we have to do this!

If and when dial-peer 8001 gets busied out - the backup dial-peer 8002 should be brought into service and vice versa. This means the backup server gets used until it is manually switched back or until the dial-peer 8002 goes out of service, where dial-peer 8001 should be re-enabled and 8002 is shutdown. Likewise with the secure dial-peers 8011 and 8012.

The following syslog occurs when dial-peer 8001 is busied out.

%SIP-5-DIALPEER_STATUS: VoIP dial-Peer <8001> is Busied Out

Here is the config - if we have a primary and a backup dial-peer - where only one is used at time.

• 8001 and 8002 (primary and backup for on prem call recorder)
• 8011 and 8012 (primary and backup for cloud transcription sip service)

!
voice class sip-profiles 8010
 request INVITE sdp-header Audio-Attribute add "a=sendonly"
!
voice class codec 8000
 codec preference 1 g711alaw
!
voice class sip-options-keepalive 8000
 description ### Verint TCP SIP options PING ###
 down-interval 10
 up-interval 5
 retry 3
 transport tcp
!
voice class sip-options-keepalive 8010
 description ###TLS SIP options PING###
 down-interval 10
 up-interval 5
 retry 3
 transport tcp tls
!
voice class srtp-crypto 8010
 crypto 1 AES_CM_128_HMAC_SHA1_80
!
media profile recorder 8000
 media-recording proxy secure 8011 8012
 media-recording proxy 8001 8002
!
dial-peer voice 8000 voip
 description Inbound CCE CUCM Recording Profile
 session protocol sipv2
 incoming called-number 70012
 voice-class codec 8000
 media-class 8000
!
dial-peer voice 8001 voip
 description Outbound Dial-peer to VerintRIS1 (On Prem Recorder)
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:10.1.1.101
 session transport tcp
 voice-class codec 8000
 voice-class sip options-keepalive profile 8000
!
dial-peer voice 8002 voip
 description Outbound Dial-peer to VerintRIS2 (On Prem Recorder)
 shutdown
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:10.1.1.102
 session transport tcp
 voice-class codec 8000
 voice-class sip options-keepalive profile 8000
!
dial-peer voice 8011 voip
 description Outbound Dial-peer to Cloud Transcription SIP Server1
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:52.123.123.101
 session transport tcp tls
 voice-class codec 8000
 voice-class sip early-offer forced
 voice-class sip profiles 8010
 voice-class sip srtp-crypto 100
 voice-class sip options-keepalive profile 8010
 srtp
 no vad
!
dial-peer voice 8012 voip
 description Outbound Dial-peer to Cloud Transcription SIP Server2
 shutdown
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:52.123.123.102
 session transport tcp tls
 voice-class codec 8000
 voice-class sip early-offer forced
 voice-class sip profiles 8010
 voice-class sip srtp-crypto 100
 voice-class sip options-keepalive profile 8010
 srtp
 no vad
!
event manager applet DP8001_DOWN authorization bypass
 event syslog pattern "VoIP dial-Peer <8001> is Busied Out"
 action 10 cli command "enable"
 action 20 cli command "configure terminal"
 action 30 cli command "dial-peer voice 8002 voip"
 action 40 cli command "no shutdown"
 action 50 cli command "dial-peer voice 8001 voip"
 action 60 cli command "shutdown"
 action 70 cli command "end"
 action 80 syslog msg "EEM: Dial-peer 8001 is Busied Out. Enable dial-peer 8002 and disable 8001."
event manager applet DP8002_DOWN authorization bypass
 event syslog pattern "VoIP dial-Peer <8002> is Busied Out"
 action 10 cli command "enable"
 action 20 cli command "configure terminal"
 action 30 cli command "dial-peer voice 8001 voip"
 action 40 cli command "no shutdown"
 action 50 cli command "dial-peer voice 8002 voip"
 action 60 cli command "shutdown"
 action 70 cli command "end"
 action 80 syslog msg "EEM: Dial-peer 8002 is Busied Out. Enable dial-peer 8001 and disable 8002."
event manager applet DP8011_DOWN authorization bypass
 event syslog pattern "VoIP dial-Peer <8011> is Busied Out"
 action 10 cli command "enable"
 action 20 cli command "configure terminal"
 action 30 cli command "dial-peer voice 8012 voip"
 action 40 cli command "no shutdown"
 action 50 cli command "dial-peer voice 8011 voip"
 action 60 cli command "shutdown"
 action 70 cli command "end"
 action 80 syslog msg "EEM: Dial-peer 8011 is Busied Out. Enable dial-peer 8012 and disable 8011."
event manager applet DP8012_DOWN authorization bypass
 event syslog pattern "VoIP dial-Peer <8012> is Busied Out"
 action 10 cli command "enable"
 action 20 cli command "configure terminal"
 action 30 cli command "dial-peer voice 8011 voip"
 action 40 cli command "no shutdown"
 action 50 cli command "dial-peer voice 8012 voip"
 action 60 cli command "shutdown"
 action 70 cli command "end"
 action 80 syslog msg "EEM: Dial-peer 8012 is Busied Out. Enable dial-peer 8011 and disable 8012."
!

Note while the config below - uses the exact same dial-peer to send the call to the transcription server - it should be noted that we do NOT need to include the SIP profile for a=sendonly, as this is done by default when media forking. This isn't the case with the media proxy - as at call setup - it hasn't doesn't yet know the call will be one way (as no audio negotiations have yet started). We are sending the early offer for the transcription server ONLY because it doesn't yet support SRTP as a requiement.

i.e. if using media forking - this profile should be removed!

voice class codec 8000
 codec preference 1 g711alaw
!
!
voice class dpg 9000
 dial-peer 9001
!
media profile recorder 9000
 media-type audio
 media-recording 8011
!
!
media class 9000
 recorder profile 9000 siprec
!
!
voice class sip-profiles 8010
 request INVITE sdp-header Audio-Attribute add "a=sendonly"
!
dial-peer voice 8011 voip
 description Outbound Dial-peer to Servisbot1
 destination-pattern 70012
 session protocol sipv2
 session target ipv4:52.123.123.101
 session transport tcp tls
 voice-class codec 8000
 voice-class sip early-offer forced
 voice-class sip profiles 8010
 voice-class sip srtp-crypto 100
 voice-class sip options-keepalive profile 8011
 srtp
 no vad
!
dial-peer voice 9000 voip
 description Inbound Call from CVP
 session protocol sipv2
 destination dpg 9000
 incoming called-number 5576111147
 voice-class codec 8000
 media-class 9000
!
dial-peer voice 9001 voip
 description Outbound Dial-peer to CUCM
 destination-pattern 5576111147
 session protocol sipv2
 session target ipv4:10.123.123.40
 session transport tcp
 voice-class codec 8000
 voice-class sip options-keepalive profile 8000
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
!

INVITE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 10.123.123.106:5061;branch=z9hG4bK1B81D108E
From: <sip:10.123.123.106>;tag=203F4E45-1E38
To: <sip:[email protected]>
Date: Thu, 18 Jun 2026 16:09:03 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Require: siprec
Min-SE:  1800
Cisco-Guid: 3475675471-1785074161-2954342749-3082674470
User-Agent: Cisco-SIPGateway/IOS-17.12.7b
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1781798943
Contact: <sip:10.123.123.106:5061;transport=tls>;+sip.src
Expires: 180
Allow-Events: telephone-event
Session-ID: ed2249fa849c51ed89319c9064588858;remote=00000000000000000000000000000000
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 2427


--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 2874 94 IN IP4 10.123.123.106
s=SIP Call
c=IN IP4 10.123.123.106
t=0 0
m=audio 17072 RTP/AVP 8
c=IN IP4 10.123.123.106
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendonly
a=label:1
a=sendonly
m=audio 17074 RTP/AVP 8
c=IN IP4 10.123.123.106
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendonly
a=label:2
a=sendonly

a=sendonly
--uniqueBoundary
Content-Type: application/rs-metadata+xml
Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns="urn:ietf:params:xml:ns:recording:1">
    <datamode>complete</datamode>
    <session session_id="27hAFmpmEfGm+eF0mpZLpA==">
        <sipSessionID>059a1ef36a92e7f3a278d8ba17711571;remote=2481ca0a8afe5c32b93734e42a127372</sipSessionID>
        <start-time>2026-06-18T16:09:03.069Z</start-time>
    </session>
    <participant participant_id="27hAFmpmEfGm+uF0mpZLpA==">
        <nameID aor="sip:[email protected]">
            <name xml:lang="en">+353851231234 </name>
        </nameID>
    </participant>
    <participantsessionassoc participant_id="27hAFmpmEfGm+uF0mpZLpA==" session_id="27hAFmpmEfGm+eF0mpZLpA==">
        <associate-time>2026-06-18T16:09:03.069Z</associate-time>
    </participantsessionassoc>
    <stream stream_id="27iOwmpmEfGm/+F0mpZLpA==" session_id="27hAFmpmEfGm+eF0mpZLpA==">
        <label>1</label>
    </stream>
    <participant participant_id="27hAFmpmEfGm++F0mpZLpA==">
        <nameID aor="sip:[email protected]">
            <name xml:lang="en">Telecoms_Agent_1 (Bob Bobster)</name>
        </nameID>
    </participant>
    <participantsessionassoc participant_id="27hAFmpmEfGm++F0mpZLpA==" session_id="27hAFmpmEfGm+eF0mpZLpA==">
        <associate-time>2026-06-18T16:09:03.069Z</associate-time>
    </participantsessionassoc>
    <stream stream_id="27iOwmpmEfGnAOF0mpZLpA==" session_id="27hAFmpmEfGm+eF0mpZLpA==">
        <label>2</label>
    </stream>
    <participantstreamassoc participant_id="27hAFmpmEfGm+uF0mpZLpA==">
        <send>27iOwmpmEfGm/+F0mpZLpA==</send>
        <recv>27iOwmpmEfGnAOF0mpZLpA==</recv>
    </participantstreamassoc>
    <participantstreamassoc participant_id="27hAFmpmEfGm++F0mpZLpA==">
        <send>27iOwmpmEfGnAOF0mpZLpA==</send>
        <recv>27iOwmpmEfGm/+F0mpZLpA==</recv>
    </participantstreamassoc>
</recording>

--uniqueBoundary--

Note how above does NOT send a request for SRTP unlike the SIP invite below (an example SIP invite when using the Media Proxy) - which correctly sends request for SRTP. This is using the EXACT same dial-peer to send the audio to the transcription SIP server - so it not dial-peer configuration issue.

Why send Early offer? Current the Transcription SIP server - supports SRTP but does have an ability to require it. So if it sends it audio requirements (which would be typical - after a 100 trying, i.e. instead of 200 OK) - the audio is setup with RTP and not SRTP.

i.e.

• m=audio 16458 RTP/SAVP 8
  • This line in the SDP states “SAVP”which stands for “Secure Audio Video Profile”
• a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  • and this line states which cypher suits are supported (in this case only one)

INVITE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 10.123.123.146:5061;branch=z9hG4bK108C43D
Remote-Party-ID: "Telecoms_Agent_1 (Bob Bobster)" <sip:[email protected]>;party=calling;screen=yes;privacy=off
From: "Telecoms_Agent_1 (Bob Bobster)" <sip:[email protected];x-nearend;x-refci=34446593;x-nearendclusterid=ACME-TST-UCCE-V11;x-nearenddevice=SEP000700000009;x-nearendaddr=6111147;x-farendrefci=34446594;x-farendclusterid=ACME-TST-UCCE-V11;x-farenddevice=SIP-TRK-IPT-CUCM-AB;x-farendaddr=00851231234;x-sessionid=059a1ef36a92e7f3a278d8ba34446593>;tag=142EAC40-1976
To: <sip:[email protected]>
Date: Tue, 16 Jun 2026 07:55:26 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE:  1800
Cisco-Guid: 3136319616-0522291035-0000010557-0673060874
User-Agent: Cisco-SIPGateway/IOS-17.12.7b
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1781596526
Contact: <sip:[email protected]:5061;transport=tls>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-ID: d6d31ee87bb951adaf3f10a1b9bb7bfd;remote=00000000000000000000000000000000
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 287

v=0
o=CiscoSystemsSIP-GW-UserAgent 3524 365 IN IP4 10.123.123.146
s=SIP Call
c=IN IP4 10.123.123.146
t=0 0
m=audio 16458 RTP/SAVP 8
c=IN IP4 10.123.123.146
a=rtpmap:8 PCMA/8000
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
a=sendonly