IP SIP Header Passing on Cisco CUBE

[Kid8082]

I am looking for someone to confirm the function of a given command for me in a Cisco CUBE configuration.  The documentation I found is not specific enough to provide me an answer.  Unfortunately, I don't have access to the equipment to confirm this for myself by trying this.  The command in question is header-passing, this command is applied in the global configuration mode under voice services voip under SIP.

Below is the URL to the command guide that outlines the command.

Cisco IOS Voice Command Reference - D through I - H [Cisco Unified Border Element] - Cisco

 Specifically, I need to configure a CUBE to allow me to pass UUI information contained in the User-to-User SIP header between an inbound and outbound peer-path with-in a CUBE.   Per my understanding by default the CUBE passes all of the Supported Mandatory SIP Headers between inbound and outbound dial-peers.  However, in order to pass the Supported Non-Mandatory Headers and the Unsupported Headers one has to enable that action.

Below is a URL that talks about this action of the CUBE as they pertain to SIP headers and defines the Supported SIP Mandatory and Suportted Non-Mandatory Headers.

Cisco Unified Border Element (Enterprise) SIP Support Configuration Guide, Cisco IOS XE Release 3S - Configurable Pass-Through of SIP INVITE Parameters [Cisco Unified Border Element] - Cisco

Here are my questions....

Is the User-to-User SIP header considering an "Unsupported" header in CUBE? I don't see it on the list of either Mandatory or Non-Mandatory header tables in the URL above.

Does enabling the header-passing command allow for the passing of all SIP headers in a given INVITE, SUBSCRIBE, and NOTIFY message?  Is this applicable to Mandatory, non-Mandatory and unsupported Headers? 

If the answer is yes to the question above is there a benefit of using this method versus using a sip-hdr-passthrulist on an inbound dial-peer? 

 Appreciate the feedback in advance

[b.winter]

The command "header-passing" has nothing to do with your scenario and normally isn't need at all, only if you have the scenario in the command description:

This command is used to allow the passing of SIP headers to IOS-based TCL applications, which otherwise do not have access to such information.

As this command doesn't work for your scenario, you need to work with the method and commands described in your 2nd link.

[Kid8082]

Are you sure about that?  There is some ambiguity in the command description.  This is what is in the command guide.

The purpose of the command header-passing , which is configured under the voice service voip , is to pass the data contained within SIP headers arriving at the gateway to VXML applications hosted on the gateway or third-party servers.

I agree that the "arriving at the gateway to VXML applications hosted on the gateway" applies to what you stated.  What is implied by "or third-party servers"?  I assume that the "third-party servers" would be IP reachable off the CUBE via outbound dial-peer.

Do you know how the CUBE qualifies the User-to-User header that carries the UUI?  Is that field considered an unsupported SIP header or a supported non-Manditory SIP header?

[b.winter · Accepted solution]

I don't know, what is meant by "third party servers", but again, the command doesn't do what you need.

If I understand the RFC 7433 correctly, User-to-User is just a SIP header field (call it a parameter or tag, ... in the SIP header) and not a SIP header itself => SIP header is not equal to SIP header field.
Therefore, your question about supported or unsupported header is not applicable here.

Taking the example from the RFC:

History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1

In this case, the SIP header would be the "History-Info" header, which is in the table 4 of supported non-mandatory SIP headers and the UUI information is a paramter in this SIP header.

[telecastle]

What is implied by "or third-party servers"? What's implied is "the VXML applications hosted on third-party servers."