Service policies

Using the Service Policy feature, your administrators can adjust PortaSIP to operate with third-party VoIP equipment based on their various peculiarities and/or you can also fine-tune service the provisioning to your customers. This tool provides additional flexibility for network management and helps you improve the quality of services.

Please consult the PortaBilling Administrator Guide for more information about the Service Policy functionality.

Sometimes one of your termination partners sends an improper SIP response if, for some reason (e.g., due to their gateway malfunctioning), they cannot terminate a call. Or, you need to define whether to try to connect a call if a user does not answer or declines it.

To handle these cases, adjust call routing by using the service policies for outgoing connections. Define the SIP response codes (e.g., 486 (Busy Here) or 603 (Declined)) for the hunt_stop_codes attribute and assign the service policy to the “Calls to Vendor via SIP” connection. When this connection is tried and PortaSIP receives a response with the code that matches the one defined, further routing for the call is stopped.

Service providers may face a one-way audio issue with particular PBX equipment.

For example, such a situation was observed with the Samsung OfficeServ 7070 PBX. It was proven that the issue was produced because this particular PBX violates the RFC and sends a different SDP during call setup. As a result, a one-way audio issue occurs.

PortaSwitch allows service providers to successfully manage such equipment’s behavior. To handle this, use the allow_callee_early_sdp_change attribute in service policies.

With this attribute enabled, a B2BUA updates the RTP session if or when an SDP change takes place. This ensures that an appropriate set of parameters is used to establish a media stream.

When this attribute is disabled, B2BUA behaves according to RFC6337 – once the SDP has been received in a SIP response, SDP in subsequent SIP responses are discarded.

Privacy headers are used when, for example, a caller’s identity must be hidden from a called party, but a vendor still requests this information. In this case, identity information can be included in the privacy header that indicates that the caller’s info must be withheld from the called party.

Configure the service policy to define whether the p asserted-identity (pai) and remote-party-id (rpid) headers are included in outgoing INVITE requests.

• The identity_outgoing_headers_trusted attribute determines whether to include one or both of these headers in a request sent to trusted remote connections.
• The identity_outgoing_headers_untrusted attribute determines whether to include them in a request sent to untrusted remote connections.

Different vendors require and can properly process different privacy headers. Thus, being able to specify which privacy header to send to trusted/untrusted vendors gives you the ability to satisfy both an end user’s request for anonymity and a vendor’s request for identity data.

To secure your VoIP system, PortaSIP’s B2BUA component usually strips unknown or potentially unsafe headers from incoming requests.

For example, it strips the alert-info header that provides an alternative ring tone for the UA because it may introduce the risk of exposing a callee to dubious content if someone were to exploit the URI it contains inappropriately.

However, you may still want to use this header if you are sure that the origin of its content is not questionable.

For this, use the Passthrough headers attribute in service policies to configure conveniently which headers B2BUA must let through. PortaSIP will accept all the headers listed in this attribute and forward them on to vendors.

Control over the list of headers permitted lets you engage with a variety of partners and use equipment whose features depend on custom SIP headers. This presents further opportunities for your business.