Archive | SIP RSS feed for this section

SIP Weirdo Cheatsheet

9 Jun
A list of SIP protocol properties, rules and exceptions.
  1. From and To header fields of a registration request contain the same value.
  2. All the registration requests send from one UA to one registrar would always have the same Call-ID.
  3. As pre 3261(and 3261 alone) Invite is the only request which can initiate a dialog.
  4. Otherwise refer and subscribe requests can also start a Dialog.
  5. A calling UAC might receive any number of 1xx responses.
  6. An invite may or may not carry SDP.
  7. In case of forking, the calling UAC might receive multiple 1XX and 2xx.
  8. ACK is the only request without a response but still a complete transaction.
  9. ACK is a mandatory request in the same direction in which Invite was propagated.
  10. ACK is mandatory for an Invite, and doesn’t become part of any other transaction other than invite.
  11. ACK for all non-successful responses are considered within the Invite transaction.
    For more discussion on ACK visit : My Previous post on ACK
  12. Cancel request can’t be challenged for authentication, as these requests can’t be re-submitted.
  13. ACK and Cancel must have the same RR header field if RR was present in the Invite request.
  14. The request filed in CSEQ for ACK and CANCEL is always invite (3261)
  15. The CSEQ number of ACK and CANCEL is always equal to the CSEQ number of the INVITE request which they are bound with.
  16. Apart from INVITE (3261) the only other request which can be cancelled is an INFO request.
  17. As per 3261′s definition of transaction, the transaction is considered complete when a request is responded by any final response, still intermediate proxies would keep the transaction alive for a time equal to default transaction timer (if not configured otherwise).
  18. There can be no session without a Dialog, but this property is not orthogonal.
  19. you can not cancel the Invite transaction if at-least one 1xx response is not received.
  20. You can not cancel any invite transaction for which there are responses received other than 1xx.
  21. In any case (other than re-writing the complete Invite request) the To  and the From header fields never change in the entire life-time of a dialog.
  22. “z9hG4bk” is a weird string called as magic cookie. Nothing magical about it other than the name. It is used to by proxies to identify if the request complies to 3261 or its older brother 2543.
  23. 3261 doesn’t restrict 100 Trying for any request, so it can be practically issued for any request. Although it makes very little sense.
  24. According to 3261 and 3261 alone, Register is the only request which can be sent out of dialog.
  25. Option request is sent to query the far end of it’s capabilities.

slight deviation, Barging into other RFCs

  1. If offer is sent and no answer received another offer can’t be generated.
  2. if offer received but answer not sent, then another offer can’t be sent.
  3. SDP can be carried by Invite, 200 OK, 183, ACK none other.
  4. SDP answer must have equal number of m-lines.
  5. offer can be rejected but not ignored.

Enough for now, will keep updating this list.

One Bonus.
If worried about SIP with NAT read the rport RFC. Just google.

 

if there is any way in which this article can be improved, please let me know.

Thanks for stopping by.

Source: http://abhishekchattopadhyay.wordpress.com/2014/06/07/sip-weirdo-cheatsheet/

SIP Trunk BandWidth Calculation

9 Jun

Bandwidth

Bandwidth as per Wikipedia is

A measurement of bit-rate of available or consumed data 
communication resources expressed in bits per second or 
multiples of it (bit/s, kbit/s, Mbit/s, Gbit/s, etc.). 
According to Hartley's law, the digital data rate limit 
(or channel capacity) of a physical communication link is 
proportional to its bandwidth in hertz.

Calculating the bandwidth requirement for a TDM network is easy. That is because they are based on either Multiplexing techniques like TDM,  Where each (Digital Signal) DS0 would correspond to one call, and depending on whether you are using T1 or E1 the number of simultaneous calls would be either 24 or 32 respectively. And at the end it boiled down to the number of connected circuits we have between two sites. However the same isn’t applicable for a SIP network when it comes to identifying Bandwidth, as there are no TDM or FDM techniques employed to send data. We’r going to use a century old telecom calculation technique called erlang. An erlang calculator can be found at http://www.erlang.com/calculator/ Prior to determining the bandwidth requirement of a SIP network we’d need to

  1. Determine, maximum simultaneous calls we need to support at any given time.
  2. Busy Hour Traffic (BHT): BHT is the measure of the call traffic at the busiest operational hour. also known as erlang load the Calculation ofBHT = (Average Call Duration(s) * calls per hour )/ 3600
    For example if we have 4000 calls per hour, with an 
    average duration of 180 seconds then BHT would be 
    --> (360 x 180)/ 3600 = 200 Erlang
  3. Determining Blocking: Blocking is the measure of failure of call attempts due to insufficient available resources. (as per definition number of lines).
    For example, a Blocking of 0.05 indicates 5 calls 
    blocked per 100 calls attempted. These blocked 
    calls would hear a busy signal or re-order tone.

The resultant of feeding these numbers in the erlang calculator is the number of trunks required to support the number of calls we wanted at a certain desired Grade of Service. Now if we had been working with TDM, then our calculation would have been complete with this resultant number from the erlang calculator. But since we are dealing with IP telephony and SIP there are a few more steps to be taken. In the next steps we would be converting that number of trunks (which is also equal to the simultaneous calls had it been TDM) into bandwidth. Lets see how.. For doing that we need to identify what codecs we would use. Whether we would use g711, g729 etc. Each codec has its own set of characteristics, which could include the codec’s sampling size, payload type, tolerance etc.. A short comparative list of capabilities of various codecs Codec Bandwidth Sample period                     Frame size                   Frames/ packet                Ethernet Bandwidth G.711 (PCM)              64 kbps                         20 ms                                160 1 95.2 kbps G.723.1A (ACELP) 5.3 kbps                         30 ms                               20 1 26.1 kbps G.723.1A (MP-MLQ) 6.4 kbps                    30 ms                                24 1 27.2 kbps G.726 (ADPCM)      32 kbps                          20 ms                                80 1 63.2 kbps G.728 (LD-CELP)   16 kbps                           2.5 ms                               5 4 78.4 kbps G.729A (CS-CELP) 8 kbps                            10 ms                                10 2 39.2 kbps AMR (ACELP)          4.75 kbps                     20 ms                                12 1 36.0 kbps AMR (ACELP)          7.4 kbps                        20 ms                                19 1 38.8 kbps AMR (ACELP)          12.2 kbps                      20 ms                                31 1 43.6 kbps AMR-WB/G.722.2(ACELP)6.6 kbps       20 ms                                17 1 38.0 kbps Before moving ahead we would also need to know the following

Codec Bit Rate (Kbps) Based on the codec, this is the number of bits per second that need to be transmitted to deliver a voice call. (codec bit rate = codec sample size / codec sample interval).
Codec Sample Size (Bytes) Based on the codec, this is the number of bytes captured by the Digital Signal Processor (DSP) at each codec sample interval. For example, the G.729 coder operates on sample intervals of 10 ms, corresponding to 10 bytes (80 bits) per sample at a bit rate of 8 Kbps. (codec bit rate = codec sample size / codec sample interval).
Codec Sample Interval (ms) sample interval at which the codec operates. For example, the G.729 coder operates on sample intervals of 10 ms, corresponding to 10 bytes (80 bits) per sample at a bit rate of 8 Kbps. (codec bit rate = codec sample size / codec sample interval).
MOS MOS is a system of grading the voice quality of telephone connections. With MOS, a wide range of listeners judge the quality of a voice sample on a scale of one (bad) to five (excellent). The scores are averaged to provide the MOS for the codec.
Voice Payload Size (Bytes) The voice payload size represents the number of bytes (or bits) that are filled into a packet. The voice payload size must be a multiple of the codec sample size. For example, G.729 packets can use 10, 20, 30, 40, 50, or 60 bytes of voice payload size.
Voice Payload Size (ms) The voice payload size can also be represented in terms of the codec samples. For example,a G.729 voice payload size of 20 ms (two 10 ms codec samples) represents a voice payload of 20 bytes [ (20 bytes * 8) / (20 ms) = 8 Kbps ]
PPS PPS represents the number of packets that need to be transmitted every second in order to deliver the codec bit rate. For example, for a G.729 call with voice payload size per packet of 20 bytes (160 bits), 50 packets need to be transmitted every second [50 pps = (8 Kbps) / (160 bits per packet) ]

Ok, The theater is all set now. Let’s jump into some calculations Bandwidth Calculation Total packet size = (L2 header) + (IP/UDP/RTP header) + (voice payload size) PPS = (codec bit rate) / (voice payload size) Bandwidth = total packet size * PPS Sample Calculation For example, the required bandwidth for a G.729 call (8 Kbps codec bit rate) with the default 20 bytes of voice payload is: Total packet size (bytes) = (MP header of 6 bytes) + ( compressed IP/UDP/RTP header of 2 bytes) + (voice payload of 20 bytes) = 28 bytes Total packet size (bits) = (28 bytes) * 8 bits per byte = 224 bits PPS = (8 Kbps codec bit rate) / (160 bits) = 50 pps => Note: 160 bits = 20 bytes (default voice payload) * 8 bits per byte Bandwidth per call = voice packet size (224 bits) * 50 pps = 11.2 Kbps Now let’s say we would have received a number 200 From the the Erlang calculator, then the required bandwidth requirement scales up to (bandwidth per call * total number of trunks that are needed) = 11.2 * 200 = 2240 kbps. On top of that there would be some percentage of additional (in a factor of 20-25%) bandwidth would be considered to compensate for factors like network re-transmissions, variance and collision. Which would eventually lead us to a figure of 28000 Kbps = 2.8 MegaBytes per second. So the bandwidth requirement would be an approximate 3MBps. However since each codec offers an entirely different sampling size it would be possible to achieve the same call rate with the desired GOM. Hope I was able to do some justice to the topic. If there is any way in which this article can be improved, please let me know. Thanks for stopping by. References: http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html#formulae http://www.wekipedia.org http://www.cs.ru.ac.za/courses/honours/RTMM/software/52-VoIP-Bandwidth.pdf the image was taken from http://m.flikie.com/33582293/beautiful-night.html?cid=33554432&order=feellucky Source: http://abhishekchattopadhyay.wordpress.com/2014/06/07/sip-trunk-bandwidth-calculation/

LTE means rethinking security in the All-IP world

2 Jun

As communications service providers (CSPs) continue to build and deploy 4G LTE networks, they are finding that they need to understand some critical concepts as they move from circuit switched 2G and 3G networks to all IP packet switched networks.  Of these, IP security rides high on that list of technologies to master. The Internet has become an open environment susceptible to malicious activity. If your assets are not secured, you are guaranteed to be attacked and compromised by one or more unscrupulous organisations. 

They may do it for financial gain, selling the stolen data to parties, as a paid service, for your competitors to disrupt your business, or even just for personal enjoyment because they found that they could compromise your infrastructure. We may not use resources such as the M61 Vulcan shown in the picture, it is important to develop and implement the proper security tools to protect the latest wireless networks.

Growth in the Data Plane

While many CSPs already have solutions in place to protect parts of the packet data network (PDN) infrastructure, they often do not understand how the implementation of a 4G LTE network architecture changes the security requirements. The S/Gi interface, or the part of the network connecting the mobile subscribers to the Internet will have a significant increase in data volumes as more LTE enabled mobile devices are used. In addition, with the increased speeds available, we expect to see 4G wireless technologies competing with fixed-line data services such as DSL and cable. This will change the type of content seen and the mobile CSP will need to develop enhanced policies to manage and secure these services.

Another concern is that LTE expects the mobile devices to be IPv6 enabled, while much of the PDN is still expected to be using IPv4 technologies for some time.  This requires the ability to translate IPv6 addresses to IPv4 addresses using a carrier-grade NAT (CGNAT) technology, while maintaining a proper security infrastructure. This includes the ability to protect the pool of IPv4 addresses being used in the CGNAT solution and all of the devices’ communications being translated.

Packets in the Control Plane

More significantly, the control plane of the LTE network will change from a circuit-switched network to an IP-based architecture.  Diameter, SIP and DNS are the primary protocols that will be used to manage the control plane as the CSPs start implementing voice over LTE (VoLTE).  Securing and managing this infrastructure will be critical to the services delivered to the subscribers and protecting their privacy.  The Home Subscriber Service (HSS) and Policy Charging and Rules Function (PCRF) depend on Diameter, an open standardised protocol used on IP networks, while the Call Session and Control Function (CSCF) systems and Application Servers (AS) within the IP Multimedia Subsystem (IMS) utilise another public standardised communication technology called Session Initiation Protocol (SIP).

f5_pic2

Figure 1. The complexity of the IMS network architecture

It is important to note that third-party applications developed by independent people in addition to the subscribers and their LTE device will have direct access to the IMS network components through the SIP protocol. This means that potential malicious or poor programming will have the ability to directly affect and access the control plane of the LTE network and be able to disrupt it or obtain unauthorised access to private information such as subscriber profiles, unless proper security measures are put in place.

The CSPs need to understand the implications of migrating to an IP network infrastructure and how the packet-based network must be managed significantly differently from the legacy circuit-switched environment. Proper planning and testing is required to successfully build a robust and secure 4G LTE network. It is important to leverage the existing work done on IP networks over the past 20 years, utilise the knowledge of your colleagues and vendors. Apply the proper availability and security practices learned from these resources to design the next generation wireless networks.

Source: http://lteconference.wordpress.com/tag/f5/

SIP over Weblogic, using Brekeke as Registrar Developers Lab Environment

9 Mar

telecom_developers_scenario

Figure depicts a typical setup required for any telecom software developer

Detailed Explanation of components is as follows :

JSR 116 – SIP Servlet 1.0

SIP Servlet 1.0 API

  • JSR 116
  • Built into the Servlet container that also hosts portlets and HTTP Servlets.
  • SIP Servlet API developed under the JCP (Java Community Process) as JSR 116 (Java Specification Request), as a set of neutral interfaces

Servlet Container

  • Environment in which a servlet can exist
  • Loads and initializes a servlet
  • Invokes the appropriate methods when SIP messages arrive

Servlets

  • Class with a service method, compiled into a Servlet Archive File (SAR)

Deployment descriptors

  • XML based file with configuration information
  • message matching rules

Screenshot making a sip servlet . The project is a SAR file

4321

Logical Entity diagram for JSR116 , sip servlet version 1.0

jsr116

SIP response methods and  flows

SIP Response methods and flows

SIP messages life-cycle process , ie init() , service() , destroy()

Bea Weblogic

• J2EE application server and also an HTTP web server by BEA Systems for Unix, Linux, Microsoft Windows, and other platforms,

•supports Oracle, DB2, Microsoft SQL Server, and other JDBC-compliant databases

•WebLogic Server supports WS-Security and is compliant with J2EE 1.4
•The most reliable server is no doubt BEA’s WebLogic Application Server. It is the only one which can resist to over 3000 concurrent clients without throwing exceptions
Use Weblogic when ,
•The WebLogic Server is the most reliable server and complex application server and offers the best support for the real-world applications.
•Although it needs a higher level of understanding of the J2EE concepts, has a complex configuration and is very expensive, this server is the best choice for a secure and fault-tolerant application.

BEA WebLogic Server is part of the BEA WebLogic Platform™.

weblogic

The other parts of WebLogic Platform are :

a) Portal, which includes Commerce Server and Personalization Server   (which is built on a BEA-produced Rete rules engine),

b) WebLogic Integration,

c) WebLogic Workshop, an IDE for Java, and d) JRockit, a JVM for Intel CPUs.

Brekeke SIP Server – SIP Proxy, Registrar Server

  • Based on the Session Initiation Protocol (SIP), the Brekeke SIP Server provides reliable and scalable SIP communication platform for Enterprises and Service Providers.
  • Brekeke SIP Server provides functionality of SIP Registrar Server, SIP Redirect Server, and SIP Proxy Server.
  • Brekeke SIP Server is a Stateful Proxy that maintain session status therefore performs optimum processing for call control

brekeke

SOFTPHONES  –  X-LITE and KAPANGA

A soft phone is a software program for making telephone calls over the Internet using a general purpose computer, rather than using dedicated hardware. Often a soft phone is designed to behave like a traditional telephone, sometimes appearing as an image of a phone, with a display panel and buttons with which the user can interact.

To communicate, both end-points must have the same communication protocol and at least one common audio codec. Many service providers use the Session Initiation Protocol (SIP) standardized by the Internet Engineering Task Force (IETF).

xliteX-Lite is a proprietary freeware VoIP soft phone that uses the Session Initiation Protocol.

 

 

 

Kapanga is a Session Initiation Protocol (SIP) software phone capable of voice, fax, and video over IP communications. As a SIP phone, Kapanga can be used on Voice over IP networks to interact with traditional Public Switching Telecommunication Networks (PSTNs) and future IP-based telecommunication devices. This document explains how to use Brekeke SIP Server with the Kapanga Soft Phone.

kapanga

Source: http://altanaitelecom.wordpress.com/2014/03/07/sip-over-weblogic-using-brekeke-as-registrar/

Call forwarding/redirection in FreeSWITCH

9 Mar

Consider you have two different contexts in your dialplan for inbound and outbound calls: the “public” context transfers the calls into “XXX_inbound” (XXX being your organization name), and the user directory has “XXX_outbound” as “user_context” variable.

Having two contexts, you have more flexibility in defining the short dial strings and outbound destinations.

But there’s a little problem: if the SIP client redirects the ringing call, or if the user makes an attended transfer, FreeSWITCH would initiate a new outbound leg in the same context where the call was bridged toward the SIP client.

As a solution, you need to define a new extension in your XXX_inbound context which would match PSTN outbound numbers. The channel will already have all custom variables which were set before bridging toward the SIP client, so you can set an additional condition criteria to make sure that this is the redirected call. This example would be placed at the bottom of the inbound context, and “directory_ext” is the variable that was earlier in the same context before the call was bridged to the SIP client:

    <extension name="call_forward">
      <condition field="destination_number" expression="^\d+$"/>
      <condition field="${directory_ext}" expression="^70\d$">
        <action application="set" data="hangup_after_bridge=true"/>
        <action application="set" data="continue_on_fail=false"/>
        <action application="bridge" data="${outgw}/${destination_number}"/>
      </condition>        
    </extension>

-
Source: http://txlab.wordpress.com/2014/02/16/call-forwardingredirection-in-freeswitch/


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

Calling from PSTN to VoIP

2 Sep

TelcoNotes

As VoIP services are growing, traditional (PSTN) and IP telephony need to co-exist. Users can belong either to one or the other network, and inter-working between the two technologies is necessary. That requires translation between the different protocols used, which is provided by signaling/media gateways. This post makes first a quick introduction to the signaling process of a PSTN call, and then it describes a call scenario where a PSTN subscriber calls a VoIP user.

Traditional telephony (PSTN network) uses a signaling protocol called ISDN User Part (ISUP). When a user initiates a call, an Initial Address Message (IAM) is sent in order to reserve a circuit for the call. The destination switch receives the IAM, initiates ringing to the called party and sends back to the caller an Address Complete Message (ACM). When the called party picks up the phone, an Answer Message (ANM) is sent back to the caller. Finally, when a…

View original post 150 more words

What is a Session Border Controller (SBC)?

22 Jul

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. But what are an SBC’s main functions and advantages?

session border controller (SBC)

  • Topology hiding

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.

  • Security

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.

  •  Interoperability

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.

This post covered the most essential and basic functionalities in an SBC. There are many more purposes that an SBC serves, for example billing, quality-of-service, policy-based routing, etc.

Source: http://telconotes.wordpress.com/2013/07/20/what-is-a-session-border-controller-sbc/

SIP for Beginners

12 Jul

I realize that I sometimes write about the SIP and SIP services as if everyone in the world has the same background and experiences as me.  That isn’t meant as a brag.  There are lots of important things that I haven’t a clue about.  I do know SIP, though, and it’s essential that I write with the understanding that my audience consists of people from all walks of the communications life.

To help things along I’ve put together this quick SIP primer.  It’s not meant to be exhaustive, but I strive to cover what I think is important.  Some of these things I have already written about in previous blogs and I intend to dig deeper into the remaining topics over the next several weeks and months.

Session Initiation Protocol

The Session Initiation Protocol (SIP) is a signaling protocol used to establish, modify, and tear-down communication sessions in an IP network.  These sessions can be as simple as a two-way call or as involved as a multi-party web conference complete with audio, video, and a shared whiteboard application.

SIP was modeled after the Hypertext Transfer Protocol (HTTP) and contains many of the basic tenets of that protocol.  First, SIP is an English-like, text-based protocol that is not only easy to read, but is also easy to understand, debug, and extend.  New features can be added to SIP without the need to modify any of the SIP server entities that might exist within any particular call path.  Second, and perhaps most importantly, SIP is media agnostic.  In other words, SIP can be used to establish sessions of nearly any media type imaginable.  As communications move well beyond that of a simple phone call, SIP is fully equipped to support any and all media (voice, video, instant message,  SMS text, etc.) that might come along.

Additionally, SIP has been extended to allow for first and third-party call control.  This means that SIP can be used by one entity to control the call flow of another entity.  In its most basic sense, this means that applications can be written that direct endpoints to create (e.g. make a call), manage (e.g. answer an incoming call), and terminate sessions (e.g. release call).

To learn about the different SIP components, please refer to SIP Servers and Services.

Rich Communications

In the same way that HTTP allows a web browser to deliver a wide variety of content types to a PC or web-enabled device, SIP-enabled devices can support media from many different sources.  Built into SIP is the notion of session description which allows SIP to establish a session independent of the underlying media stream.  This allows for session escalation whereby a user might start communicating with an instant message and then later on add voice, file transfer, and multi-party video.  SIP has been designed to support any communications means that a user may require.

SIP is perfect for dealing with the explosion of consumer-grade communications devices that are making their way into the enterprise.  Imagine a world where your personal iPhone or iPad can be securely integrated into your communications system.  With SIP that world exists and solutions are available today.

SIP Trunks

In traditional wireline telephony, phone calls are passed to and from an enterprise and the Public Switched Telephone Network (PSTN) over a dedicated line or a bundle of circuits.  These could be analog trunks such as loop or ground start lines or digital trunks such as T1, E1, ISDN, or PRI.  Since SIP is an IP protocol, it runs on the same network that data traffic runs on.  This convergence of voice and data means that a SIP trunk is a logical concept that has more to do with bandwidth than physical wires or circuits.

The benefits of SIP trunks over traditional trunks are many:

  • Converged voice and data
  • Rich communications
  • Equipment reduction which leads to reduced power and space requirements
  • Flexible costs due to burst pricing
  • Improved reliability and failover strategies

User Centricity

Computer Telephony Integration (CTI) has traditionally been endpoint centric where applications controlled and monitored physical endpoints regardless of who might be using that device.  However, with the explosion of communications interfaces a user might employ numerous different devices throughout the day.  For instance, the manager of a sales department will typically have an office phone, a cell phone, a soft phone (a computer phone such as Avaya’s One-X Communicator or Microsoft’s OCS or Lync clients), and an instant messaging client.  With SIP, a single application can manage that user’s devices along with the presence status generated by those devices (e.g. on a call, in an instant messaging session, etc.) as a whole.  This user centric model is a break from the device centric model where each device is treated as a separate entity with no particular connection to its owner.

A related discussion can be found here.

Security

In the same way that you would never allow a PC to connect to the Internet without the proper security tools such as a firewall and virus checker, Voice over IP (VoIP) requires protection from malicious activity.  SIP has a number of security mechanisms that are either built into SIP or work alongside SIP to create a rock solid means of defense.  For example, SIP itself can be encrypted and individual SIP messages can be challenged with authentication requests.  SIP media streams can also be encrypted to prevent preying eyes and ears.  Finally, SIP-based components such as a Session Border Controllers (SBC) can be deployed as a perimeter defense appliance similar to how an enterprise would deploy a network firewall.

For a deeper dive, please read  my articles  on Practicing Safe SIP and Choosing the Right SBC.

Why Not H.323?

Since the early 2000’s, IP telephony was built around the H.323 standard.  H.323 is a feature-rich protocol that allowed the IP PBX to deliver a user experience identical to that of older digital telephones.  However, H.323 is not media independent like SIP and cannot be extended beyond voice and video.  So, while H.323 a powerful protocol in terms of delivering traditional voice features, it is not capable of being extended to support the multimedia requirements of the modern enterprise.  As the communications expectations of employees and customers evolve, H.323 devices will be supplanted by SIP devices which are purpose fit for today’s world of smart phones, mobility, and context aware devices.

I take this discussion a little further in Intelligent SIP Endpoints.

That’s probably enough for now.  If I haven’t lost you, please keep coming back for more.  I still have a lot to say.  :-)

Source: http://andrewjprokop.wordpress.com/2013/07/12/sip-for-beginners/

SIP 101: Preparing for successful deployment

11 May

I often hear questions from customers about SIP. SIP can mean different things to different people. SIP trunking, end to end SIP, SIP for voice and video, SIP in the contact center –those are just a few of the variations that come to mind. For purpose of this post and others to follow, as well as my upcoming presentation at International Avaya Users Group (IAUG, where I’ll be speaking next month in Orlando, FL) I am going with end to end SIP for voice as a starting point.

When I talk about end to end SIP I am looking at SIP all the way in from the carrier trunks, through the core infrastructure, and out to the phones (hard phones or soft phones). With that out of the way, let’s talk more about some of the questions that need to be answered and some of the key things that you, the customer, need to do in order to make your SIP deployment successful.

First, there are a few core design choices to consider up front to ensure long term goals are met. For instance, when looking at the design of my network, do I want to put SIP trunks from a managed service provider directly to each site or SIP trunks into a core set of data centers and then drive traffic out to my remote sites via a MPLS network? The answer to this partially is determined by size of both the organization and the sites that need to be supported.

Another consideration in answering this question is what level of autonomy each site can handle from a IT/Telecom perspective, but also from a failover perspective. Obviously SIP directly to each site provides more autonomy, but then you may not get some of the economies of scale and support that a centralized SIP based solution can offer. Unless you go with redundant suppliers to each site you still have a single point of failure, but then much of the cost savings that you were hoping for may be gone. I typically see a more centralized SIP deployment with redundant sites and carriers to each site.

The next set of choices deals with the now and the future: do we want to have a converged network for voice, data, video, etc.? This needs to be thought of ahead of time even if this is not the goal of the first stage of your deployment. You will want to design and choose vendors that support your end vision.

Related to this is how you handle codec choices where bandwidth and quality tradeoffs occur. Even if the network is just “voice,” you need to make the choice between G.711 (“toll quality”), G.729 (compressed), G.722 (“HD voice”). When making this choice, the thing most people look at the tradeoff between quality and bandwidth. However, there are other considerations to take into account, like fax and how it will behave over your IP network (that is if people still use faxes in your company).

One other major component you need to understand is E911 for emergency calls. Understanding how it is handled by your carriers and your vendors, and how the location of the caller affects how the call makes it to the appropriate PSAP are key elements to consider when designing your solution.

Those are some of the core concepts and questions I usually take into consideration. Please post your thoughts on things you think I missed in the comments below.

Coming soon, I will talk about top tips for a successful SIP implementation. Keep an eye out for it!

For more information, learn about Getting the Most Out of Your Migration to SIP Trunking.

Source: http://blog.empirix.com/2013/05/10/sip-101-preparing-for-successful-deployment/

%d bloggers like this: