cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
759
Views
15
Helpful
0
Replies
Highlighted
Beginner

Copying SIP Headers in CUBE for Cisco Call Recording

This post is an “answer” rather than a question, in the hopes that it will save someone some time and frustration. I read the documentation on using the CUBE to copy part of a SIP header from an incoming dial peer to an outgoing dial peer, but found it a bit lacking (and – as of May, 2017 incomplete, frankly!)

 

I’ve worked with a few Call Recording vendors and they all say they can’t have traffic routed through a CUBE. I assumed it was more that they simply did not know how, and that is indeed the case. Most SIP-based call recording solutions look for the phone being recorded to provide two separate streams of audio – one from the “near end” (the person speaking into the phone) and one from the “far end” (the person on the other end of the conversation). Within CallManager we have the phone & line configured with:

  • Built In Bridge: On
  • Recording Option: Automatic Call Recording Enabled
  • Recording Profile: SRH_CSMB_Ambulance_Recording
  • Recording Media Source: Phone Preferred
  • Monitoring Calling Search Space: SRH_CSMB_SERVICE_CLASS_ID_0_CSS

 

To allow recording, the phone creates two SIP sessions (two SIP INVITES) to the destination configured on the Recording Profile, in this case 1500099999. In the invitation the “From” field has all the information needed by the call recording server. A sample looks like this:

 

From: "Rob Webber" <sip:6177261970@10.80.1.55;x-nearend;x-refci=151527974;x-nearendclusterid=Cluster4-East;x-nearenddevice=SEPDCA5F48693C9;x-nearendaddr=6177261970;x-farendrefci=151527973;x-farendclusterid=Cluster4-East;x-farenddevice=cluster99-3_trk;x-farendaddr=9782694585>;tag=9061432~b924bea4-3e74-4152-9d4c-5f7c7df0f208-151527987

 

If the SIP trunk is direct from the CallManager to the call recording server all of the above information is passed to the recording server. However if the traffic is routed through a CUBE, by default this information is not passed to the call recording server and the server has no way to identify ‘both’ sides of the conversation and combine them into 1 recording.

 

The CUBE has the ability to “copy” the relevant information in the original “From” field into the INVITE that is sent from the CUBE to the call recording server. That config was not obvious to me, however with some help from the Cisco TAC I was able to get it working.

 

The first part is fairly easy – configuring the CUBE to copy the From field on the INVITE that hits the incoming dial-peer. In our case the incoming dial-peer is 150009998, so the relevant config is:

 

voice class sip-copylist 100

 sip-header FROM

!

dial-peer voice 150009998 voip

 description SRH Cambridge call recording server (incoming leg)

 incoming called-number 1500099999

 voice-class sip copy-list 100

 session protocol sipv2

 session transport tcp

 dtmf-relay rtp-nte

 codec g711ulaw

 no vad

!

 

The next part is a bit trickier. Within the SIP profile config, the request INVITE peer-header sip FROM copy  command copies the portion of the inbound SIP INVITE that you specify, while the request INVITE sip-header FROM modify command modifies the outgoing SIP INVITE. As you can see from the From field (above) we want to capture everything from the “x-nearend;” to the trailing “>”. The tag is unique to the INVITE and does not need to be copied. Initially I tried:

 

voice class sip-profiles 200

 request INVITE peer-header sip FROM copy ".*(x-.*>)" u01

 request INVITE sip-header FROM modify "(.*)>(.*)" "\1;\u01\2"

 

In the request INVITE peer-header sip FROM copy command, everything in quotes is what the CUBE will look through in the SIP From header to try to match what you want. Everything in parenthesis will get stored in variable u01 that you can later use to modify the outgoing SIP INVITE. The first .* is a regular expression that matches any number of characters. It then searches for the exact string  x- and stores that, plus any number of characters (the second .*) until the > is matched. However this captured everything from the last appearance of x- to >,not the first appearance of it. Since every invite has 9 appearances of x-, we can force it to include all 9 of these by using:

 

request INVITE peer-header sip FROM copy ".*(x-.*x-.*x-.*x-.*x-.*x-.*x-.*x-.*x-.*>)" u01

 

The only way it can match a string that has all 9 appearances of x- is to start capturing at the very first appearance of x-. So this will capture everything from the first appearance of x- to the trailing >, which is exactly what we want. Now to modify the outgoing SIP header we use:

 

request INVITE sip-header FROM modify "(.*)>(.*)" "\1;\u01\2"

 

Everything in the first set of quotes is the From header the CUBE would have used before modification, everything in the second set of quotes is what the CUBE actually uses (after modification). So the initial "(.*)>(.*)" means chop up the initial From header and all of the characters (.*) before the > will be character string #1, and all of the characters (.*) after the > will be character string #2.

 

The modified header will be "\1;\u01\2". Before any modification (by default) the CUBE would have used a From header of:

 

From: "Rob Webber" <sip:6177261970@10.249.200.46>;tag=DB960AEA-53E

 

The \1 means use character string 1 (the \ is an escape character to tell the CUBE use character string 1, not an actual 1). So that is:

 

From: "Rob Webber" <sip:6177261970@10.249.200.46

 

Then ; the means add an actual semi-colon, then the \u01 means add in what is stored in variable u01 (which for us is x-nearend;x-refci=151527974;x-nearendclusterid=Cluster4-East;x-nearenddevice=SEPDCA5F48693C9;x-nearendaddr=6177261970;x-farendrefci=151527973;x-farendclusterid=Cluster4-East;x-farenddevice=cluster99-3_trk;x-farendaddr=9782694585>). Finally the\2 means add in the original character string 2, which is ;tag=DB960AEA-53E. The final result is that the original outgoing header:

 

From: "Rob Webber" <sip:6177261970@10.249.200.46>;tag=DB960AEA-53E

 

Gets changed into:

 

From: "Rob Webber" <sip:6177261970@10.249.200.46;x-nearend;x-refci=151527974;x-nearendclusterid=Cluster4-East;x-nearenddevice=SEPDCA5F48693C9;x-nearendaddr=6177261970;x-farendrefci=151527973;x-farendclusterid=Cluster4-East;x-farenddevice=cluster99-3_trk;x-farendaddr=9782694585>;tag=DB960AEA-53E

 

We then just need to apply it to the outbound dial-peer:

 

dial-peer voice 150009999 voip

 description SRH Cambridge call recording server (outgoing leg)

 destination-pattern 1500099999

 voice-class sip profiles 200

 session protocol sipv2

 session target ipv4:172.20.162.38

 session transport tcp

 dtmf-relay rtp-nte

 codec g711ulaw

 no vad

!

 

So the final config needed for this is:

 

voice class sip-profiles 200

 request INVITE peer-header sip FROM copy ".*(x-.*x-.*x-.*x-.*x-.*x-.*x-.*x-.*x-.*>)" u01

 request INVITE sip-header FROM modify "(.*)>(.*)" "\1;\u01\2"

!

voice class sip-copylist 100

sip-header FROM

!

dial-peer voice 150009998 voip

 description SRH Cambridge call recording server (incoming leg)

 incoming called-number 1500099999

 voice-class sip copy-list 100

 session protocol sipv2

 session transport tcp

 dtmf-relay rtp-nte

 codec g711ulaw

 no vad

!

dial-peer voice 150009999 voip

 description SRH Cambridge call recording server (outgoing leg)

 destination-pattern 1500099999

 voice-class sip profiles 200

 session protocol sipv2

 session target ipv4:172.20.162.38

 session transport tcp

 dtmf-relay rtp-nte

 codec g711ulaw

 no vad

!

 

The Cisco syntax on the 2 INVITEs for call recording (near end and far end) are different, but both have the 9 appearances of x-, so the above config works for both sides of the recorded conversation.

 

Hope this helps! Rob.

 

 

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards