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.
A registration is a binding between a SIP URI, or Address Of Record, and one or more contact URIs, which are additional resources to contact to reach the user identified by the Address Of Record.
The SBC supports UE subscribing to registration event package as defined in RFC 3680. This event defines a message-body in NOTIFY which carries UE contact details. The SBC relays the message body appropriately. The SBC also performs V4-V6 interworking (if necessary) for SUBSCRIBE session setup.
If Contact header is transparently passed, there is no special handling needed at P-CSCF. Else, to support this package SBC intercepts and interprets NOTIFY’s message-body and changes the Contact header. This feature assumes that Contact header transparency is enabled along with it.
The SBC can receive SUBSCRIBE message (for registration event package) from a registered UE and relay the message based on stored Service-Route header and perform V6-V4 interworking if access side supports V6 and IMS CN supports V4 (i.e. stored Service-Route header points to V4). For this request, the SBC can:
Similarly, the SBC can receive NOTIFY (for registration event package) towards a registered UE and relay the message towards UE if the contact header transparency is enabled. Note that in the NOTIFY request, the UE IP address is received in Request-URI and the top-most Route header points to the SBC.
When REGISTER is interworked from V6 to V4 or vice versa, or if the contact header transparency is disabled, the SBC changes the Contact header as it egresses the REGISTER request. The Contact address is changed to point to itself. Hence a NOTIFY is received for registration event package in such a scenario, The SBC modifies the Contact header in NOTIFY message-body and send it towards UE.
When the SBC acting as P-CSCF performs IP interworking, it receives NOTIFY (for registration event package) towards a registered UE and relay the same towards UE.
The SBC also supports multiple contact address registrations by UE.
Example:
The following example enables regEventPackage on the core and peer IP signaling profiles.
% set profiles signaling ipSignalingProfile DFL_PCSCF_UE_TG_PROF commonIpAttributes relayFlags regEventPackage enable % commit % set profiles signaling ipSignalingProfile DFL_PCSCF_CORE_TG_PROF commonIpAttributes relayFlags regEventPackage enable % commit % show profiles signaling ipSignalingProfile DFL_PCSCF_UE_TG_PROF commonIpAttributes relayFlags regEventPackage regEventPackage enable; % show profiles signaling ipSignalingProfile DFL_PCSCF_CORE_TG_PROF commonIpAttributes relayFlags regEventPackage regEventPackage enable;
For configuration details, refer to:
To learn more about registrations, see SIP Registration.