SBC-BASICS
The Session Border Controller (SBC) is a SIP B2BUA entity that is commonly used in the borders of network providers. The SBC receives and processes requests as a UAS, which then regenerates and sends as a UAC. In this way it is acting as an intermediary between the origin and destination of VoIP sessions.
The Session Border Controller (SBC) is a SIP B2BUA entity that is commonly used in the borders of network providers. The SBC receives and processes requests as a UAS, which then regenerates and sends as a UAC. In this way it is acting as an intermediary between the origin and destination of VoIP sessions.
- Topology hiding
- Security
- Interoperability
BACKGROUND Of SBCs :
These functions include :
a) perimeter defense ( access control, topology hiding, and denial-of-service prevention and detection )
b) functionality not available in the endpoints (NAT traversal, protocol interworking or repair)
c) traffic management (media monitoring and quality of service (QoS) ).
some of these functions may also get integrated into other SIP elements.
SIP - based SBCs typically handle both signaling and media. SBCs often modify certain SIP headers and message bodies that proxies are not allowed to modify. some SBCs modify the session description carried in the message and insert a Record- Route entry. Other SBCs replace the value of the contact header field with the SBCs address and generate a new Call-ID and new To and From tags.
An SBCs provides functions such as controlling and protecting access to the inner network from the outer network.
Peering Scenario :
A typical peering scenario involves two network operators who exchange traffic with each other.An originating gateway (GW-A1) in operator A's network sends an INVITE that is routed to the SBC in operator B's network. Then, the SBC forward it to the softswitch (SS-B). The softswitch responds with a redirect (3xx) message back to the SBC that points to the appropriate terminating gateway (GW-B1) in Operator B's network. If operator B does not have an SBC, the redirect message would go to the operator A's originating gateway. After receiving the redirect message, the SBC sends the INVITE to the terminating gateway.
Access Scenario :
The SBC is placed at the border between the access network (outer network) and the operator's network (inner network) to control access to the operator's network, protect its components ( media servers, application servers, gateways, etc.) from unauthorized use and DoS attacks, and monitor the signaling and media traffic.
Topology Hiding :
Topology hiding consists of limiting the amount of topology information given to external parties. Operators have a requirement for this functionality because they do not want the IP addresses of their equipment ( proxies, gateways, application servers, etc.) to be exposed to outside parties.
The most common form of topology hiding is the application of header privacy , which involves stripping Via and Record-Route headers. replacing the contact header, and even changing Call-IDs. However, in deployments that use IP addresses instead of domain names in headers that cannot be removed ( e.g., From and To headers ) , the SBC may replace these IP addresses with its own IP address or domain name.
Example :
The current way of implementing topology hiding consists of having an SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of topology information (e.g., Via and Record-Route entries ) from outgoing messages.
Then, the SBC performs a topology hiding function. In this scenario, the SBC removes and stores all existing Via and Record-Route headers, and then inserts Via and Record-Route header fields with its own SIP URI. If the SBC loses state ( e.g., SBC restarts for some reason ), it may not be able to route messages properly(note : some SBCs preserve the state information also on restart). For example , if the SBC removes Via entries from a request and then restarts, thus losing state; the SBC may not be able to route responses to that request, depending on the information that was lost when the SBC restarted.
Media traffic management is the function of controlling media traffic. Traffic management helps the creation of different kinds of billing models (e.g., video telephony can be priced differently than voice-only calls) and it also makes it possible for operators to enforce the usage of selected codecs.
Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description. By modifying the session description, the SBC can force the media to be sent through a media relay which may be co-located with the SBC. This kind of traffic management can be done.
Architectural issues :
Implementing traffic management in this manner requires the SBC to access and modify the session descriptions (i.e.,offers and answers ) exchanged between the user agents.
Example :
Traffic management may be performed in the following way : The SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, in the media path.
Consider the following example scenario: the SBC receives an INVITE request from the outer network, which in this case is an access network.
V=0
O=Owner 2890844526 2890842807 IN IP4 192.0.2.4
C=IN IP4192.0.2.4
m=audio 49230 RTP/AVP 96 98
a=rtpmap : 96 L8/8000
a=rtpmap : 98 L16/16000/2
In this example, the SBC performs the media traffic management
Fixing Capability Mismatches :
SBCs fixing capability mismatches enable communications between user agents with different capabilities or extensions.
Example :
The inner network is an access network using IPv4 and the outer network is using IPv6. The SBC receives an INVITE request with a session description from the access network
Then, the SBC performs a capability mismatch fixing function. In this scenario, the SBC inserts Record-Route and Via headers and rewrites the "c=" line from the sessions descriptor.
Maintaining SIP-Related NAT Bindings :
NAT traversal in this instance refers to the specific message modifications required to assist a user agent in maintaining SIP and media connectivity when there is a NAT device located between a user agent and a proxy/registrar. SBCs NAT traversal function is required in scenarios where the NAT is outside the SBC (i.e, not in cases where SBC it self acts as a NAT).
Note that the SBC does not need to relay all the REGISTER requests received from the user agent to the registrar. The SBC can generate responses to REGISTER requests received before the registration is about to expire at the registrar. Moreover, the SBC needs to deregister the user agent if this fails to refresh its registration in time, even if the registrar would still be valid.
SBCs can also force taffic to go through a media relay for NAT traversal purposes.
Example :
The SBC resides between the UA and Registrar. previously, the UA has sent a REGISTER request ot the Registrar, and the SBC receives the registration response.
when performing the NAT traversal function, the SBC may rewrite the expiry time to coax the UA to re-register prior to the intermediating NAT deciding to close the pinhole.
Naturally, other measures could be taken in order to enable the NAT traversal (e.g., non-SIP keep alive messages), but this example illustrates only one mechanism for preserving the SIP-related NAT bindings.
Access Control :
This function can be implemented by protecting the inner network with firewalls and configuring them so that they only accept SIP traffic from the SBC. Access control can be applied to either only the signaling or both the signaling and media. If it is applied only to the signaling, then the SBC might behave as a proxy server. If access control is applied to both the signaling and media.
A key part of media layer access control is that only media for authorized sessions is allowed to pass through the SBC and/or associated media relay devices.
Protocol Repair :
Operators may wish to support protocol repair, if they want to support as many clients as possible. It is noteworthy that this function affects only the signalling component of on SBC, and that the protocol repair function is not the same as protocol conversion.
Media Encryption :
SBCs are used to perform media encryption/decryption at the edge of the network. This is the case when media encryption (e.g., Secure Real-time Transport Protocol (SRTP) ) is used only on the access network (outer network) side and the media is carried unencrypted in the inner network.
Advantages:
These functions include :
a) perimeter defense ( access control, topology hiding, and denial-of-service prevention and detection )
b) functionality not available in the endpoints (NAT traversal, protocol interworking or repair)
c) traffic management (media monitoring and quality of service (QoS) ).
some of these functions may also get integrated into other SIP elements.
SIP - based SBCs typically handle both signaling and media. SBCs often modify certain SIP headers and message bodies that proxies are not allowed to modify. some SBCs modify the session description carried in the message and insert a Record- Route entry. Other SBCs replace the value of the contact header field with the SBCs address and generate a new Call-ID and new To and From tags.
An SBCs provides functions such as controlling and protecting access to the inner network from the outer network.
Peering Scenario :
A typical peering scenario involves two network operators who exchange traffic with each other.An originating gateway (GW-A1) in operator A's network sends an INVITE that is routed to the SBC in operator B's network. Then, the SBC forward it to the softswitch (SS-B). The softswitch responds with a redirect (3xx) message back to the SBC that points to the appropriate terminating gateway (GW-B1) in Operator B's network. If operator B does not have an SBC, the redirect message would go to the operator A's originating gateway. After receiving the redirect message, the SBC sends the INVITE to the terminating gateway.
Access Scenario :
The SBC is placed at the border between the access network (outer network) and the operator's network (inner network) to control access to the operator's network, protect its components ( media servers, application servers, gateways, etc.) from unauthorized use and DoS attacks, and monitor the signaling and media traffic.
Topology Hiding :
Topology hiding consists of limiting the amount of topology information given to external parties. Operators have a requirement for this functionality because they do not want the IP addresses of their equipment ( proxies, gateways, application servers, etc.) to be exposed to outside parties.
The most common form of topology hiding is the application of header privacy , which involves stripping Via and Record-Route headers. replacing the contact header, and even changing Call-IDs. However, in deployments that use IP addresses instead of domain names in headers that cannot be removed ( e.g., From and To headers ) , the SBC may replace these IP addresses with its own IP address or domain name.
Example :
The current way of implementing topology hiding consists of having an SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of topology information (e.g., Via and Record-Route entries ) from outgoing messages.
Then, the SBC performs a topology hiding function. In this scenario, the SBC removes and stores all existing Via and Record-Route headers, and then inserts Via and Record-Route header fields with its own SIP URI. If the SBC loses state ( e.g., SBC restarts for some reason ), it may not be able to route messages properly(note : some SBCs preserve the state information also on restart). For example , if the SBC removes Via entries from a request and then restarts, thus losing state; the SBC may not be able to route responses to that request, depending on the information that was lost when the SBC restarted.
* Media Traffic Management
General Information and Requirements :Media traffic management is the function of controlling media traffic. Traffic management helps the creation of different kinds of billing models (e.g., video telephony can be priced differently than voice-only calls) and it also makes it possible for operators to enforce the usage of selected codecs.
Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description. By modifying the session description, the SBC can force the media to be sent through a media relay which may be co-located with the SBC. This kind of traffic management can be done.
Architectural issues :
Implementing traffic management in this manner requires the SBC to access and modify the session descriptions (i.e.,offers and answers ) exchanged between the user agents.
Example :
Traffic management may be performed in the following way : The SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, in the media path.
Consider the following example scenario: the SBC receives an INVITE request from the outer network, which in this case is an access network.
V=0
O=Owner 2890844526 2890842807 IN IP4 192.0.2.4
C=IN IP4192.0.2.4
m=audio 49230 RTP/AVP 96 98
a=rtpmap : 96 L8/8000
a=rtpmap : 98 L16/16000/2
In this example, the SBC performs the media traffic management
Fixing Capability Mismatches :
SBCs fixing capability mismatches enable communications between user agents with different capabilities or extensions.
Example :
The inner network is an access network using IPv4 and the outer network is using IPv6. The SBC receives an INVITE request with a session description from the access network
Then, the SBC performs a capability mismatch fixing function. In this scenario, the SBC inserts Record-Route and Via headers and rewrites the "c=" line from the sessions descriptor.
Maintaining SIP-Related NAT Bindings :
NAT traversal in this instance refers to the specific message modifications required to assist a user agent in maintaining SIP and media connectivity when there is a NAT device located between a user agent and a proxy/registrar. SBCs NAT traversal function is required in scenarios where the NAT is outside the SBC (i.e, not in cases where SBC it self acts as a NAT).
Note that the SBC does not need to relay all the REGISTER requests received from the user agent to the registrar. The SBC can generate responses to REGISTER requests received before the registration is about to expire at the registrar. Moreover, the SBC needs to deregister the user agent if this fails to refresh its registration in time, even if the registrar would still be valid.
SBCs can also force taffic to go through a media relay for NAT traversal purposes.
Example :
The SBC resides between the UA and Registrar. previously, the UA has sent a REGISTER request ot the Registrar, and the SBC receives the registration response.
when performing the NAT traversal function, the SBC may rewrite the expiry time to coax the UA to re-register prior to the intermediating NAT deciding to close the pinhole.
Naturally, other measures could be taken in order to enable the NAT traversal (e.g., non-SIP keep alive messages), but this example illustrates only one mechanism for preserving the SIP-related NAT bindings.
Access Control :
This function can be implemented by protecting the inner network with firewalls and configuring them so that they only accept SIP traffic from the SBC. Access control can be applied to either only the signaling or both the signaling and media. If it is applied only to the signaling, then the SBC might behave as a proxy server. If access control is applied to both the signaling and media.
A key part of media layer access control is that only media for authorized sessions is allowed to pass through the SBC and/or associated media relay devices.
Protocol Repair :
Operators may wish to support protocol repair, if they want to support as many clients as possible. It is noteworthy that this function affects only the signalling component of on SBC, and that the protocol repair function is not the same as protocol conversion.
Media Encryption :
SBCs are used to perform media encryption/decryption at the edge of the network. This is the case when media encryption (e.g., Secure Real-time Transport Protocol (SRTP) ) is used only on the access network (outer network) side and the media is carried unencrypted in the inner network.
Advantages:
One
of the advantages of an SBC is that it can provide topology hiding,
which means that it works like a NAT, translating all IP addresses (on
IP and SIP level) that the SIP messages contain, between the core
(private network) and public side. In this way, the core network can be
protected, since it can keep its “identity” private.
An
SBC can be considered as a “SIP/RTP Firewall”. It protects the core
network from unwanted messages with the help of access-lists (on IP and
SIP level) as well as it provides admission control in order to put
restrictions in the VoIP traffic (for example restrict the amount of
concurrent calls, in order not to overload the network). Such
restrictions help also in the protection of the network from attacks,
for example DoS attacks. Finally different traffic policies can be
applied in order to control better the RTP/media traffic.
An
SBC usually provides the possibility to change/manipulate the SIP
messages that are coming through it. That means that an SBC can change
the content of the SIP messages by manipulating the SIP or SDP headers.
This functionality is particularly useful in order to achieve
interoperability between different vendor implementations.
SIP Call flow without SBC:
SIP CALL FLOW With SBC:
No comments:
Post a Comment