IMPORTANT

Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as 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

  • No labels