SIP profiles on Cisco CUBE: modify, add and remove headers

CollabPlane engineering notes

A SIP profile rewrites a message as it leaves or enters a Cisco CUBE. It is the tool for the last interoperability problem on a trunk: the carrier wants a header in a form the call manager does not send.

What a rule looks like

Each rule names the message it applies to, the header or SDP line, an action, and for a change, a pattern and a replacement.

voice class sip-profiles 100
 request INVITE sip-header From modify "@.*>" "@example.com>"
 request INVITE sip-header X-Trunk-Group add "X-Trunk-Group: east"
 request INVITE sip-header Cisco-Guid remove
 response 200 sdp-header Audio-Attribute modify "sendonly" "sendrecv"

• request or response, followed by the method or response code. ANY applies to all of them.
• sip-header or sdp-header, followed by the header name.
• modify, add, remove or copy.

Where to apply it

• On a dial-peer with voice-class sip profiles 100. This is the usual choice, because it limits the change to one trunk.
• On a tenant, to cover every dial-peer that uses it.
• Globally under voice service voip, sip. Use this rarely.

A profile applies to messages the CUBE sends. To change messages it receives, enable inbound profiles under voice service voip, sip and add the inbound keyword where the profile is applied.

Patterns and groups

Patterns are regular expressions in double quotes. Groups use plain parentheses and are reused as \1, \2. This is different from voice translation rules, where the parentheses need a backslash. A double quote inside a pattern is written \".

To carry a value from one header to another, a copy rule stores the matched text in a numbered variable, and a later modify rule writes it into the second header.

Why a rule does nothing

• It is on the wrong dial-peer. The call matched a different one. Check the match first.
• The header is not in the message. modify changes an existing header. It does not create one.
• The pattern does not match the header as sent. Copy the header text from a debug and test against that, with its exact spacing and angle brackets.
• Direction. The rule is written for an outbound message and the problem is on an inbound one.
• Order. Rules run in sequence, and an earlier rule changed the text a later rule was written to match.

Check the result

Run debug ccsip messages and place one call. The debug shows the message as it was sent, after the profile ran. Compare it with the same message on the other leg to see the change.

Change one thing per rule and test each rule alone. A profile that grew by ten rules in one sitting is hard to trust.

Where Workbench helps

SIP Profile Builder writes the rules from a description of the change. SIP Profile Tester runs a profile against a real message and shows the message before and after, so you can test without placing a call. A profile pushed from Workbench is recorded with a backup and can be rolled back.