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.     ... View more

My current environment has 2 Cisco 3945 CUBEs that each have a SIP connection to our provider, Windstream.  We use a Session Manager Edition (SME) of CallManager (version 9.1.2) to connect to these two 3945’s using two SIP trunks. The two SIP trunks are in a Route Group together.   Last week Windstream had a routing issue where their SBC could not route back (IP routing) to one of our 3945’s. A “debug ccsip messages” trace showed that the 3945 was sending three SIP invites (fairly quickly) to their SBC and not getting anything in return. After those three invites, it sent a SIP 408 (Request Timeout) back to SME.   It appears that at that point SME was returning a busy signal to the user, rather than moving on to the other SIP trunk in the Route Group (which was working). My questions are:   1.        1. Is that the actual default behavior of a CallManager Cluster (upon receiving a SIP 408 to not try to continue routing the call via other SIP trunks)? I’m wondering if this is specific to something in our config or if possibly we were hitting a timeout issue? 2.        2. Is it possible to configure CallManager/SME to try to continue routing (to the next option in the Route Group or move onto the next Route Group in the Route List) in order to connect the call in this scenario?   Thanks! Rob. ... View more