Tag Archives: SIP

VoIP – PSTN Gateways and How They Do the Translation

9 Mar

PSTN and VoIP networks have co-existed for some time now. Calls can be made from one platform to the other with the help of translation signaling/media gateways. But how is this translation done and what are the main functions of a gateway?

PSTN and VoIP are two very different technologies. PSTN uses SS7/ISUP protocol for signaling and transfers media over traditional TDM channels on E1/T1 trunks.  VoIP on the other hand, uses SIP protocol for signaling and RTP protocol for the media. A gateway’s duty is to convert those protocols and formats from one to the other.

A gateway has three main functions:

  • Signaling Gateway (SG)
  • Media Gateway Controller (MGC)
  • Media Gateway (MG)

 

The picture below depicts the functional structure of a typical gateway.

VoIP PSTN gateway

The Signaling Gateway receives the ISUP messages from the PSTN side (that are transferred over MTP according to the SS7 protocol suite), encapsulates them into IP messages (by replacing the MTP part of the message with IP) and forwards them to the Media Gateway Controller.

The Media Gateway Controller performs the actual translation between ISUP and SIP protocols as well as AAA (Authentication Authorization Accounting) tasks. It is also responsible for communicating and controlling the Media Gateway with the help of the Media Gateway Control Protocol (MGCP), which is a client-server, text-based signaling and control protocol, used for administration of the media gateway.

Finally, the Media Gateway translates the PSTN voice stream to RTP packets to be transferred over the IP network.

This post described the three main gateway functions for the translation between PSTN and VoIP networks. There are different implementations of gateways that can support also other/extra functionalities in order to cover various telephony scenarios.

Source: http://telconotes.wordpress.com/2014/03/04/voip-pstn-gateways-and-how-they-do-the-translation/

Advertisements

Calculating Bandwith for Video Calls

25 Oct

A few weeks ago I wrote a blog on determining the bandwidth used by voice calls in Calculating Bandwidth for SIP Trunks.  Now, while voice is an extremely important aspect of SIP communications, the beauty of SIP is that it isn’t limited to strictly voice.  On my various PC and smart phone clients I do voice, presence, instant message, and video.  While communications forms such as instant message and presence do consume some network bandwidth, it’s extremely low and neither is of a real-time nature.   However, video is very real-time in nature and will typically consume far more data than even the most data intensive wide band voice codec.

Video codecs have a number of distinguishing characteristics, but in terms of bandwidth utilization we are concerned with two major factors – resolution and frame rate.  Resolution is expressed by the pixel height and pixel width of the rendered image.  Frame rate is expressed in image frames per second.  Clearly, more pixels sent more often produces the best image.  This, of course, leads to greater bandwidth consumption and possibly less video calls on your network.

It is my experience that the following five video codes are the ones you will most often encounter with video calls – Divx, H.263, H.263+, H.264, and MPEG-4.  Each of these codes offer different resolution and frame rate values that ultimately create different quality experiences and bandwidth requirements.

For DviX codecs you will commonly find the following variations:

Client Setting

Resolution

Frames / sec

Quality

Bandwidth (kbps)

Average (kbps)

Very low bandwidth

160 x 120

2

Very low

10 – 20

15

Low bandwidth

160 x 120

10

Low

60 – 120

80

Medium bandwidth

320 x 240

10

Medium

150 – 300

200

High bandwidth

352 x 288

15

High

400 – 800

600

For H.263, H.263+, H.264, and MPEG-4 it looks like this:

Client Setting

Resolution

Frames / sec

Quality

Bandwidth (kbps)

Very low bandwidth

176 x 144

2

Very low

10

Low bandwidth

176 x 144

10

Low

64

Medium bandwidth

352 x 288

10

Medium

192

High bandwidth

352 x 288

15

High

512

Very high bandwidth

640 x 480

30

Very high

768

At this point you need to determine the number of simultaneous video calls and the quality level of those calls.  Unlike your voice traffic, these numbers might not be as easy to determine.  Video is still a relatively new form of communication and you may not have the empirical knowledge required to do a full analysis.  This means that you will have to take your best guess and be prepared to add or remove bandwidth as users become more comfortable with making and receiving video calls.

However, I will take a stab at a few estimates that may form the basis of your best guess approach.

Expected Video Sessions:

Subscribers

Sessions

10

8

25

12

50

17

75

23

100

27

250

54

500

95

750

134

1000

171

1250

210

Your number may vary quite a bit from these.  The important thing is to do the best job you can in determining the number of sessions.

Next, you need to translate those sessions into bandwidth requirements.  Given the above data I come up with the following video requirements in Mbit/sec.

Sessions

Very Low

Low

Medium

High

Very High

8

0.1

.6

1.6

4.8

6.1

12

0.2

1.0

2.4

7.2

9.2

17

0.3

1.4

3.4

10.2

13.1

23

0.3

1.8

4.6

13.8

17.7

27

0.4

2.2

5.4

16.2

20.7

54

0.8

4.3

10.8

32.4

41.5

95

1.4

7.6

19.0

57.0

73.0

134

2.0

11

27.0

80.0

103.0

171

2.6

14

34.0

103.0

131.0

210

3.2

17

42.0

126.0

161.0

To determine your particular bandwidth needs, I suggest the following:

  • Estimate the total number of SIP video subscribers that will be using each video quality level.
  • From this estimate, determine the number of video sessions using the above table.
  • Using the bandwidth requirements table, determine the bandwidth for each expected codec.  Sum those numbers.
  • Note.  Rather than trying to estimate for each video codec type, pick an average codec and multiply by the expected number of video sessions.

You then need to ensure that your switches, routers, queues, and uplinks are sized to meet the expected video traffic.  Also, make sure that you apply the proper QoS settings to ensure the best video experience possible.

I hope this helps you understand what you need in terms of bandwidth for your video roll-out.  It’s important to realize that video is not going away and the demand for quality, well-behaved video calls will be growing every year.  Do it right and your users will be happy.  Fail to plan and configure your network appropriately and you risk a help desk nightmare.

 

Source: http://andrewjprokop.wordpress.com/2013/10/24/calculating-bandwidth-for-video-calls/?blogsub=confirmed#blog_subscription-2

Advantages to Customers of SIP Trunking

23 Apr

SIP stands for Session Initiation Protocol and is a technology at the enterprise level for delivering multiple voice connections to a PBX or key system over an IP data connection. In order for a business to utilize SIP they must have a PBX with a SIP-enabled trunk side and their data provider must be able to deploy and switch SIP.

Hot Desk, GTi, University of GlamorganSIP Trunks at the enterprise level of the network replace PRIs between the central office andPBXs. A PRI is a dedicated T-1 transport circuit and can support 23 bearer paths for voice, but aSIP trunk connection typically rides an existing data circuit and can be used to carve out as many voice paths as are wanted within the limits of the bandwidth available.

Following are the reasons that businesses want SIP trunks, and thus for carriers to sell them. This list is discusses the advantages for the small and medium business customer.

Saves Money. SIP generally saves money. SIP trunks replace PRIs which are inefficient. It is not unusual for a customer with a PRI to be using only part of the capacity and yet they have to pay for it all since it is a linear product. SIP trunks are typically carved out of a company’s data or Internet connection and can be sized as needed within the constraints of the bandwidth. It is typical for a business to cut their costs at least in half using SIP trunks compared to PRIs due to the efficiency.

More Efficient Use of the Data Connection. Most businesses will already have an Internet connection and SIP trunks are carved from those connections. Most businesses use their data connections in a bursty fashion, meaning there are times of the day when they use a lot of their bandwidth, but also many times when they use very little. SIP trunking can take advantage of the unused capacity in most company data connections. Companies often do not need to increase the bandwidth they are buy SIP trunks and can fit them into their existing data product.

Enables Unified Communication. SIP enables all of the various features that comprise unified communications such as access to the phone system from cell phones or tablets, integrated voicemail and email, video chat, instant messaging and other features that make businesses more productive.

Enables Upgrade to an IP PBX. Businesses more and more want the kinds of features that are available with an IP PBX and IP handsets. Many businesses are choosing to buy an IP PBX to get these features rather than buy IP Centrex from their telco provider. The general advantage for a business to have their own IP PBX is the ability to customize their communications network, something that many service providers do not offer with IP Centrex.

Allows Multiple Locations to Act like One. With SIP trunks and an IP PBX a business with more than one location can have a unified telephone system that brings the data and voice together for all locations.

Any carrier that sells enterprise data service to businesses should offer SIP trunks. Even if you sell IP Centrex, customers who prefer to have their own phone system are going to want SIP trunks.

Source: http://potsandpansbyccg.com/2013/04/23/advantages-to-customers-of-sip-trunking/

The big idea

14 Apr
Virtually every communications service provider on the planet is engaged (at some level) in a transition from a legacy TDM circuit-switch network built on TCAP and ISUP signaling to a next-generation multi-service core based on SIP and DIAMETER signaling.  As an industry, we’ve been making slow but patient progress in this transition for the past 15 years but we’re still just at the early stages of the process.  The transition from TDM to SIP has become more of a journey than a destination.  The goal of this blog is to fully explore two crucial aspects of this journey – specifically the role that centralized-routing andcentralized-database services play in the core of the next-generation network.  Content for this blog will come from a combination of my personal experience as Founder of NetNumber and from a group of guest authors from around the communications world.  In this first posting I will lead-off with trying to answer the following essential question:

Why should I invest the time and money to implement a centralized-routing and database services engine into my next-generation network?”

Let’s start by looking at the legacy that we’ve inherited as an industry. Over the past 100 years our network deployment model has been to distribute both routing-instructions and subscriber-information out to the edge of the network in the form of “in-switch” routing and subscriber data.  There are of course exceptions to every rule but in general, networks have been designed with a routing-database and subscriber-database in every switch in the network.  Consider the following typical example:

In the TDM network, when a user on a given switch dials a number the originating switch first checks its own local subscriber database to determine if the destination user is served on the local switch.  If not, the switch checks its own local routing database to determine how to route the call to the next-hop.  The next-hop switch follows the same logic using its own in-switch routing database until the call reaches the destination switch that serves the subscriber. 

This model of hop-by-hop routing has been working for decades and it enabled the TDM network to span the globe.  Given the success of this legacy “in-switch” model, why should we consider changing to a centralized-routing model in the next-generation network?  I’ve encountered four powerful and compelling arguments that make the decision obvious.

  1. Operating Cost Savings:  Centralized-routing allows all routing instructions and subscriber profiles to be provisioned and managed via a single logical system in the network.  As a result, the network operations team and business support team only need to learn one provisioning method and one routing engine architecture to support any number of network elements.  By comparison, the old “in-switch” model required the operations and business support teams to learn a different routing model for every type of switch in the network and every vendor in the network.  The long term cost savings of centralized routing are both significant and permanent in the next generation network.
  2. Vendor independence:  Integrating a new network platform (SBC, MGC, AS, xCSCF, SMSC, MMSC, Softswitch, etc.) into the network is greatly simplified by removing the routing-database and subscriber database component from eachnetwork element.  In a centralized-routing environment each network element simply selects a standard protocol to access its routing instructions (AIN, CAP, ENUM,INAP, MAP, SIP, WIN, etc.).  As a result, carriers/operators can quickly and efficiently introduce new network elements and new vendors into the network with minimum increase in operational costs.
  3. Faster deployment of new services:  Centralized-routing empowers a carrier/operator to implement new value added services by changing service-logic in just one logical location.  No need to schedule upgrades to every network element to deliver a new value added service.  This concept was first introduced into the SS7/C7 network with the delivery of SCP (service control points) and it has been perfected in the next-generation network through use of centralized routing and database services.
  4. Real time routing updates:  Routing changes are provisioned in one spot in the network and are made available in real-time to any number of distributed network elements via any number of standard query protocols.  By comparison, the old in-switch routing model required a laborious process of updating every switch in the network in an organized fashion.  Roll-back was equally tedious and fraught with risk.

Despite the obvious elegance of a centralized routing architecture, many customers find it difficult to break away from the long history of provisioning a separate in-switch routing database for each switch in the network.  Using an “in-switch” routing engine seems simple at first but it leads to a network where cost and complexity grow with the deployment of every new network element.  On top of that, as networks converge and new services are introduced, it becomes apparent that many in-switch routing engines contain functional limitations that hamper growth.  The challenge of growth in the “in-switch” routing model is higher-operating cost and slower deployment of services.  By comparison, the reward of migrating to centralized-routing is lower operating costs and faster deployment of new services.

The NetNumber team has found that the transition from “in-switch” routing to “centralized-routing” typically takes place over a period of time.  The migration from TDM to SIP services is providing carriers and operators with the perfect opportunity to grow into the new centralized routing architecture.  The NetNumber team has been working with carriers and operators for the past 13 years to help facilitate this transition through the delivery of a multi-protocol, multi-service, centralized routing application called TITAN.  I’ll use real world use—cases from TITAN deployments as a mechanism for exploring how different operators are making use of a CRF or Centralized Routing Function.

Below is a diagram that shows one use-case example of how the NetNumber TITAN is commonly deployed to fulfill the role of a multi-protocol CRF in a converted TDM and SIP network.  TITAN is a widely deployed example of a centralized routing engine so it offers us a large set of real-world use cases that we can leverage to fully explore this subject in detail.  I’ll refer back to this high-level architecture in future posts to this blog when I discuss real-world use-cases.

TITAN Architecture

In summary, practical carrier/operator experience has shown that there are four compelling reasons to include a centralized routing function (CRF) in the next-generation network (Operational Cost Savings, Vendor Independence, Faster Deployment of New Services and Real-Time Routing Updates).  Although the high-level benefits are obviously compelling the process of moving an industry from 100-years of “in-switch routing” to “centralized routing” is likely to take an extended time to complete but the journey is well underway.

Source: http://centralizedrouting.wordpress.com/2013/04/12/the-big-idea-2/

WebRTC: a double-edged sword for mobile operators!

28 Jan

The world is never going to look the same for the mobile industry. After three decades of an effectively closed service environment, everything but the bit pipe is now up for grabs. With the rise of Smartphones capable of running applications with access to internet-enabled services, a world of new and disruptive technologies has become available.  As HTML evolves towards HTML5, the line between browser and application gets blurred.

WebRTC has been heralded as a major disruptor to the mobile value chain, enabling real time voice and video (and data) services through a well-defined API. Web developers can nimbly create communication applications and plug them into existing web pages enhancing the user experience. These apps will run in the browser on any (low spec) mobile or computing device, independently of network or device user interface implementation, possibly augmented from the cloud.

A disruptor for the industry, clearly, but when mobile operators play to their strengths, WebRTC creates a unique value-add and therefore business opportunity. This comes from the signaling and session management layer being left open for the application developer. For this layer there are several choices that can be made, the most attractive for mobile operators is naturally SIP.

Offering a web-socket based SIP connection from WebRTC to the operator’s IMS infrastructure can add significant value to WebRTC based consumer and enterprise services, such as:

  • Rendezvous: Provide the current IP address for the addressed party (an essential detail!)
  • Facilitate multi-party (conference) connections
  • Provide interworking among telco domains (RCS, SMS, MMS) and XMPP
  • Ensure appropriate Quality of Service

The question now is not, can mobile operators risk not taking part – instead, given the opportunity and advantage, why would they not?

Source: http://theartofmessaging.com/2013/01/25/webrtc-a-double-edged-sword-for-mobile-operators/

VoLTE billing architecture explained

25 Sep

Charging is an important aspect for VoLTE calls and a must for commercial deployment— but it literally pays to get it right. As the same session flows through PGW in LTE network and IMS core there is a danger that subscribers could be double charged for both data and voice for the same call.

IMS nodes provide the necessary means to solve the billing issues. During the SIP call establishment or message transaction IMS nodes generates an IMS correlation id for each and every event. IMS correlation ids are included in the CDR for each VoLTE calls. During dedicated bearer establishment for VoLTE calls PCSCF and PGW exchange ICID and GCID through PCRF Rx/Gx messages. Based upon VoLTE APN bearer establishment PGW can redirect all the VoLTE charging information to a different billing server to avoid double charge of voice and data sessions.

ICID and GCID in CDR help to correlate the call in the IMS and access network. IMS charging information is transferred to billing system through Diameter or ISC interfaces.

Charging can be based on

• Duration Based Charging

• Event based charging

• Volume based charging

Single call with different access legs can be easily correlated by billing servers since all the calls are anchored by IMS.

Source: http://lteconference.wordpress.com/2012/09/24/volte-billing-architecture-explained/ 24 Sep 2012 Written by dancoleinforma

%d bloggers like this: