CUBE SIP header manipulation - will 'add' action take variables?

[helloguys]

The "Cisco-Gucid" header exists in one call leg (first appears in the "100 Trying" response), but not in another (a new INVITE).  I'm trying to use SIP profile to copy the header over (from dial-peer 2010 to dial peer 9012).

But the result was - CUBE added the header as "Cisco-Gucid:\u01" instead of escaping the variable u01.  My questions are:

• Does the 'add' action honor (escape) the variables?
• If not, what are the alternatives?

voice class sip-copylist 100
 sip-header Cisco-Gucid

voice class sip-profiles 9012
 request INVITE peer-header sip Cisco-Gucid copy "Cisco-Gucid:(.*)" u01
 request INVITE sip-header Cisco-Gucid add "Cisco-Gucid:\u01"

dial-peer voice 2010
 description Inbound Instance 1 - CUCM - CVP
 voice-class sip copy-list 100
 
dial-peer voice 9012 voip
 description SIP-REC TCP ( INT-1 )
 voice-class sip profiles 9012

[Roger Kallberg]

Split your SIP profile into two parts, one used inbound on your inbound dial peer to copy the value and another that uses what was copied earlier on the outbound dial peer to add what was copied earlier. For this you’ll need to turn on use of inbound SIP profiles as it normally does not work in the inbound direction. See this document for more information. Explain Cisco IOS and IOS XE Call Routing 

[helloguys]

Thank you for your suggestion.  I'll try that.  But that didn't answer my question - will the "ADD" action honor the variable?  i.e. can I use variables with "ADD" action?  Thanks!

[Roger Kallberg]

Yes that should work.

[helloguys]

But it does not.  I have a TAC case opened.  They have no clue.

[Roger Kallberg]

Try with what I suggested.

[b.winter]

Maybe a workaround could be, that you have 2 rules:
rule 1 to add an empty header with "add"
and rule 2 to modify the header with the value of the variable

[Roger Kallberg]

This is what I think that you need to have.

voice service voip
 sip
  sip-profiles inbound
!
voice class sip-copylist 100
 sip-header Cisco-Gucid
!
voice class sip-profiles 2010
 request INVITE peer-header sip Cisco-Gucid copy "Cisco-Gucid:(.*)" u01
!
voice class sip-profiles 9012
 request INVITE sip-header Cisco-Gucid add "Cisco-Gucid:\u01"
!
dial-peer voice 2010
 description Inbound Instance 1 - CUCM - CVP
 voice-class sip copy-list 100
 voice-class sip profiles 2010 inbound
!
dial-peer voice 9012 voip
 description SIP-REC TCP ( INT-1 )
 voice-class sip profiles 9012

Try it out and let me know how it goes.

[helloguys]

Roger,

Thank you for your suggestion.  I tried that but didn't seem to work.  TAC said they need to clarify with the developers to see if this is supported.  Here is my use case:

1. I have a call center environment use SIPREC recording.
2. In bound call from PSTN hits CUBE (1st INVITE from the top).
3. CUBE sends the call to CVP (2nd INVITE)
4. CVP responds with "100 Trying" and "200 Ok".  Both response has (same) "Cisco-Gucid" tag, which is a CVP customer tag.
5. Call established.  PSTN caller hears CVP greetings.
6. Based on the SIPREC recording profile configured on CUBE, CUBE automatically fork the call to recording server (3rd INVITE).  But this INVITE does not contain the custom CVP tag "Cisco-Gucid".

I want to copy the Cisco-Gucid header from the "100 Trying" (or "200 Ok") to the 3rd INVITE.  TAC said it's probably not supported as the "100 Trying" and "200 Ok" are on an outgoing dial-peer (though the messages are incoming). The "sip copy-list" only takes effect on incoming dial-peer.

I was under the impression that the copy-list takes effect on "incoming message". From software design perspective, we just need to make sure the "copy from" event happens before the "add to" event.  In this case, the "copy from" events are the "100 Trying" and "200 Ok" (circled in the diagram).  The "add to" even is in the INVITE (also circled), which will not happen until the call to CVP is established.

I'm following https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/copy_sip_headers.html.  Is there another way to achieve my goal? Thanks!

[Roger Kallberg]

These messages are inbound on the outbound call leg. It’s imperative to comprehend the concept that there are always two call legs, one inbound and another one outbound. As you yourself wrote the copy is limited to work on the inbound call leg, that is as well stated in the documentation I shared earlier, but you should wait for confirmation from the BU at Cisco as they should have the detailed insight into how this operates.