IPSP Transparency Flags

IMPORTANT

The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.

Refer to the SBC SIP Transparency Implementation Guide for additional information.

Transparency flags are provisioned on IP Signaling Profiles associated with egress SIP Trunk Groups, and indicate whether specific SIP headers are transparently copied from the ingress SIP message to the egress SIP message. Transparency flags include:

acceptContactHeader	acceptHeader	alertInformationHeader	authcodeHeaders
callInfoHeader	contactHeader	errorInfo	fromHeader
geolocation	geolocationError	geolocationRouting	historyInfo
maxForwardsHeader	mwiBody	pAccessNetworkInfoHeader	pCalledPartyID
pChargingVectorHeader	pEarlyMedia	pVisitedNetworkIDHeader	passCompleteContactHeader
pathHeader	qsigBody	reasonHeader	referredByHeader
requestURI	routeHeader	serviceRouteHeader	sipBody
sipfragBody	toHeader	toneBody	unknownBody
unknownHeader	userToUserHeader	viaHeader

To enable a transparency flag, use the following CLI syntax:

% set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes transparencyFlags <transparencyFlag_name> enable

The following SIP headers cannot be controlled using relay or transparency flags in relay scenarios:

Accept-Language	Alert-Info	Also
Anonymity	Authorization	Contact
Content-Length	Diversion	Error-Info
Event	Expires	From
Max-Forwards	Min-Expires	Min-SE
Path	P-Charge-Info	P-DCS-Billing-Info
P-K-Cfl	P-K-Cfo	P-Preferred-Identity
Proxy-Authenticate	Proxy-Authorization	Proxy-Require
P-Sig-Info	RAck	Reason
Record-Route	Remote-Party-ID	Reply-To
Requested-By	Require	Resource-Priority
Retry-After	RSeq	Service-Route
Session-Expires	Subscription-State	To
Via	Warning	WWW-Authenticate

For configuration details, see:

Space shortcuts

Page tree