UK VoIP Interconnect - White Paper
There are two possible network architectures that can be used, as shown below in the two sides of the schematic:
In the first option, shown on the left hand side above, the Call Agent controls the Media Boundary Function using a Midcom protocol, such as the ETSI standardised H.248 package. In this option, the Signalling Boundary Function could be a normal firewall. However, the Call Agent has to present a publicly routable IP address to the peer Service Providers and there is no protection at the signalling layer within the Service Providers network. Access to other parts of the Service Providers infrastructure is prevented by the firewall.
More importantly in the context of this discussion document, it requires a H.248 control connection from the Call Agent to the Media Boundary Function at the network edge. Today, this protocol technology has not yet been developed, so this option is not readily available for early adopters.
In Option 2, the same protocol is used from a back-to-back User Agent (B2BUA) implementation in the Signalling Boundary Function to control the Media Boundary Function. Fortunately, this has been developed and is readily available in the 1460 session border controller, and so can be implemented by early adopters.
The Newport 1460 SIP SignallingProxy is aligned with the Signalling Boundary Function and the 1460 MediaProxy is the Media Boundary Function.
The 1460 product offers and easy evolution path between the two architectures allowing for cost effective deployment and growth. Additionally, the 1460 SignallingProxy can be deployed as a SIP signalling firewall, further protecting and securing the Service Provider network.
Creating Resilient Interconnects
In this diagram, both the Signalling and Media Boundary Functions are duplicated to provide a resilient interconnect. The Call Agents decide which interconnect function to use, depending on load and whether or not the particular boundary function is operational. It is also possible, in Option 2 on the right hand side of the diagram below, that a Signalling Boundary Function could control many Media Boundary Functions within a Service Provider's network (not shown here).
Signalling Protocols
The signalling protocol chosen by the NICC is SIP-I in the interconnect space. The Call Agent or the Signalling Boundary Function inspects the protocol and creates a pinhole to open in the interconnect for media flows as appropriate using the Megaco Gate Control Protocol package. The media pinhole is open for the duration of the call.
SIP-I can be carried over UDP or TCP, with SCTP having also been proposed within the NICC, as a feature rich alternative.
At present it looks like UDP or TCP will be chosen by the NICC initially, albeit that SCTP would be a superior choice. This is because of the pressure to deploy combined with the current lack of availability of SCTP capable SIP devices.
SCTP has the benefit of being capable of supporting the required 500 millisecond failure detection times and also supports a layer 4 based multi-homing capability that is intended to offer easy to use standby switchover in the case of failure. TCP and UDP, on the other hand will be much slower to respond without careful configuration and do not support multi-homing at the protocol level. They are, however, much more widely used and available.
While the multi-homing capability within networks is seen as quite useful in Service Provider interconnect applications, it does not deliver the commercial benefits that can be delivered by a least cost routing scheme that supports alternate routes at the application layer (e.g. the Softswitch). There is a school of thought that the choosing of an alternate path should be done by the Softswitch/Call Agent and that the choice of secondary path should be made on grounds of cost.
In the SIP-I environment, TCP has few advantages over UDP. If the message size exceeds 1300 bytes, by convention, either TCP is used or the message is fragmented. In UDP environments fragmentation is regarded as being unreliable due to the possibility of out of sequence messages. However, SIP will discover bad messages and a repeat transmission of the message will be made. So unless there are a lot of bad messages above 1300 bytes in length that are discarded, there is little downside to using UDP. It is not foreseen that the SIP-I messages in the interconnect space will ever exceed 1300 bytes, so the choice of TCP or UDP may in come cases come down to the capability of the source / destination Softswitch.
|
IPsec and VoIP
