Monthly Archives: July 2013

WebRTC layers

WebRTC stands for Web Real-Time Communications and  introduces  a real-time media framework in the browser core alongside associated JavaScript APIs for controlling the media frame and HTML5 tags for displaying.

From a technical point of view, WebRTC will hide all the complexity of real-time media behind a very simple JavaScript API . 

WebRTC simplified :

In simple words its a phenomenal thing , that will revolutionize internet telephony .  Also it will emerge to be platform independent ( ie any browser , any desktop operating system any mobile Operating system ) .

WebRTC allows anybody to introduce real-time communication to their web page as simply as introducing a table.

Codec Confusion :

Audiio Codecs

Currently VP8 is the codec of choice since it is royalty free. In mobility today, the codec of choice is h264. H264 is not royalty free. But it is native in most mobile handsets due to its high performance.

Voice Codecs

Opus is a lossy audio compression format developed by the Internet Engineering Task Force (IETF) targeting a broad range of interactive real-time applications over the Internet, from speech to music. As an open format standardized through RFC
6716, a reference implementation is provided under the 3-clause BSD license. All known software patents Which cover Opus are licensed under royalty-free terms.
G.711 is an ITU (International Telecommunications Union) standard for  audio compression. It is primarily used in telephony. The standard was released in 1972. It is the required standard in many voice-based systems  and technologies, for example in H.320 and H.323 specifications.
Speex is a patent-free audio compression format designed for speech and also  a free software speech codec that is used in VoIP applications and podcasts. Some consider Speex obsolete, with Opus as its official successor, but since
significant content is out there using Speex, it will not disappear anytime soon.
G.722 is an ITU standard 7 kHz Wideband audio codec operating at 48, 56 and 64 kbit/s. It was approved by ITU-T in 1988. G722 provides improved speech quality due to a wider speech bandwidth of up to 50-7000 Hz compared to G.711 of 300–3400 Hz.

AMR-WB Adaptive Multi-rate Wideband is a patented wideband speech coding standard that provides improved speech quality due to a wider speech bandwidth of 50–7000 Hz. Its data rate is between 6-12 kbit/s, and the codec is generally available on mobile phones.

Architecture :

WebRTC offers web application developers the ability to write rich, realtime multimedia applications (think video chat) on the web, without requiring plugins, downloads or installs. It’s purpose is to help build a strong RTC platform that works across multiple web browsers, across multiple platforms.

WebRTCpublicdiagramforwebsite

Web API – An API to be used by third party developers for developing web based videochat-like applications.

WebRTC Native C++ API – An API layer that enables browser makers to easily implement the Web API proposal.

Transport / Session

The session components are built by re-using components from libjingle, without using or requiring the xmpp/jingle protocol.

RTP Stack – A network stack for RTP, the Real Time Protocol.

STUN/ICE – A component allowing calls to use the STUN and ICE mechanisms to establish connections across various types of networks.

Session Management

An abstracted session layer, allowing for call setup and management layer. This leaves the protocol implementation decision to the application developer.

VoiceEngine

VoiceEngine is a framework for the audio media chain, from sound card to the network.

iSAC / iLBC / Opus

iSAC: A wideband and super wideband audio codec for VoIP and streaming audio. iSAC uses 16 kHz or 32 kHz sampling frequency with an adaptive and variable bit rate of 12 to 52 kbps.

iLBC: A narrowband speech codec for VoIP and streaming audio. Uses 8 kHz sampling frequency with a bitrate of 15.2 kbps for 20ms frames and 13.33 kbps for 30ms frames. Defined by IETF RFCs 3951 and 3952.

Opus: Supports constant and variable bitrate encoding from 6 kbit/s to 510 kbit/s, frame sizes from 2.5 ms to 60 ms, and various sampling rates from 8 kHz (with 4 kHz bandwidth) to 48 kHz (with 20 kHz bandwidth, where the entire hearing range of the human auditory system can be reproduced). Defined by IETF RFC 6176.

NetEQ for Voice– A dynamic jitter buffer and error concealment algorithm used for concealing the negative effects of network jitter and packet loss. Keeps latency as low as possible while maintaining the highest voice quality.

Acoustic Echo Canceler (AEC) – The Acoustic Echo Canceler is a software based signal processing component that removes, in real time, the acoustic echo resulting from the voice being played out coming into the active microphone.

Noise Reduction (NR) -The Noise Reduction component is a software based signal processing component that removes certain types of background noise usually associated with VoIP. (Hiss, fan noise, etc…)

VideoEngine 

VideoEngine is a framework video media chain for video, from camera to the network, and from network to the screen.

VP8 –Video codec from the WebM Project. Well suited for RTC as it is designed for low latency.
Video Jitter Buffer – Dynamic Jitter Buffer for video. Helps conceal the effects of jitter and packet loss on overall video quality.
Image enhancements -For example, removes video noise from the image capture by the webcam.


w3c

—Media Stream Functions

—API for connecting processing functions to media devices and network connections, including media manipulation functions.

—Audio Stream Functions

—An extension of the Media Stream Functions to process audio streams (e.g. automatic gain control, mute functions and echo cancellation).

—Video Stream Functions

—An extension of the Media Stream Functions to process video streams (e.g. bandwidth limiting, image manipulation or “video mute“).

Functional Component Functions

—API to query presence of WebRTC components in an implementation, instantiate them, and connect them to media streams.

—P2P Connection Functions

—API functions to support establishing signalling protocol agnostic peer-to-peer connections between Web browsers

  • API specification Availability

WebRTC 1.0: Real-time Communication Between Browsers –  Draft 3 June 2013 available

  • -Implementation Library: WebRTC Native APIs

Media Capture and Streams – Draft 16 May 2013

  • Supported by Chrome , Firefox , Opera in desktop of all OS ( Linux , Windows , Mac )
  • Supported by Chrome , Firefox  in Mobile browsers ( android )

ietf

  • —Communication model
  • —Security model
  • —Firewall and NAT traversal
  • —Media functions
  • —Functionality such as media codecs, security algorithms, etc.,
  • —Media formats
  • —Transport of non media data between clients
  • —Input to W3C for APIs development
  • Interworking with legacy VoIP equipment

WG RFC   Date

  • draft-ietf-rtcweb-audio-02      2013-08-02
  • draft-ietf-rtcweb-data-channel-05      2013-07-15
  • draft-ietf-rtcweb-data-protocol-00      2013-07-15
  • draft-ietf-rtcweb-jsep-03      2013-02-27
  • draft-ietf-rtcweb-overview-07      2013-08-14
  • draft-ietf-rtcweb-rtp-usage-07     2013-07-15
  • draft-ietf-rtcweb-security-05      2013-07-15
  • draft-ietf-rtcweb-security-arch-07      2013-07-15
  • draft-ietf-rtcweb-transports-00      2013-08-19
  • draft-ietf-rtcweb-use-cases-and-reqs-11      2013-06-27
  • Plus over 20 discussion RFC drafts

Next -> webRTC business benefits


Advertisements

JAIN SLEE

•Jain SLEE :- JAIN is a Sun Java standards initiative and part of the Java Community Process.
JAIN specifies a comprehensive range of APIs that target converged IP and PSTN networks, including APIs for

– High-level application development (such as service provider APIs and the Service Logic Execution Environment (SLEE))

– call control

– signalling at the protocol level (such as SIP, MGCP and SS7)

•For telephony, data and wireless communications networks, the Java APIs defined through.

– service portability

– network independence

– open development

•A Service Logic Execution Environment (SLEE) is high-throughput, low-latency, event-processing application environment.
•JAIN SLEE  is designed specifically to allow implementations of a standard to meet the stringent requirements of communications applications (such as network-signaling applications).

Goals of JAIN SLEE are:

– Portable services and network independence.

– Hosting on an extensible platform.

– services and SLEE platform available from many vendors.

Key Features are  :

•Industry standard :- JSLEE is the industry-agreed standard for an application server that meets the specific needs of telecommunications networks.
•Network independence:-The JSLEE programming model enables network independence for the application developer. The model is independent of any particular network protocol, API or network topology.
•Converged services:- JSLEE provides the means to create genuinely converged services, which can run across multiple network technologies.
•Network migrations :-As JSLEE provides a generic, horizontal platform across many protocols, independent of the network technology, it provides the ideal enabler technology for smooth transition between networks.
•Global market—global services:-JSLEE-compliant applications, hosted on a JSLEE application server are network agnostic. A single platform can be used across disparate networks
•Robust and reliable:- As with the enterprise application server space, deploying applications on a standard application server that has been tested and deployed in many other networks reduces logic errors, and produces more reliable applications
•Standard object orientated component  architecture

Scope of JAINSLEE applications

•The principal features of the JSLEE programming model are :

– programs written in Java

-asynchronous programming paradigm

-well-defined event-delivery semantics

-component-based, object-oriented approach

-transactional model

-“profiles” of information, which represent provisioned data

-usage interfaces that support gathering service statistics

-support for standard Java APIs (such as JNDI and JDBC), and optionally, support integration with J2EE

-standard facilities for traces, alarms and timers, for use by the applications that are hosted on the SLEE

Resource adaptors

-The JSLEE provides integration capabilities using a plug-in architecture known as the resource adapter

architecture. Resource adaptors (RAs) provide interconnection with the “outside” world, for example,

interfaces to communication protocol stacks, directory services or external systems.

•SLEE management

-The JSLEE specification also defines the management capabilities of the SLEE. It adopts the Java standard

in this area, Java for Management Extensions (JMX).

————————————————————————————————————————

SIP based architecture

SIP solutioning and architectures  is a subsequent article after SIP which can be found here .  A VOIP Solution is designed to accommodate the signalling and media both along with integration leads to various external endpoints such as various SIP phones ( desktop, softphones , webRTC )  ,  telecom carriers  , different voip network providers  , enterprise applications  ( Skype , Microsoft Lync  ) , Trunks etc .

The article outlines VOIP architecture  from 3 viewpoints :

  • from Infrastructure standpoint
  • from core voice engineering perspective
  • and accompanying external components required to run and system

Infrastructure Requirements

  • Data Centers with BCP ( Business Continuity Planning ) and DR ( Disaster Recovery )
  • Servers and Clusters for faster and parallel calculating
  • Virtualization
    VMs to make a distributed computing environment with HA ( high availability ) and DRS ( Distributed Resource Scheduling )
  • Storage
    SAN with built in redundancy for resiliency of data.
    WORM compliant NAS for storing voice archives over a retention period.
  • Racks, power supplies, battery backups, cages etc.
  • Networking
    DMZs ( Demilitarised Zones)  which are interfacing areas between internal servers in green zone and outside network
    VLANs for segregation between tenants.
    Connectivity through the public Internet as well as through VPN or dedicated optical fibre network for security.
  • Firewall configuration
  • Load Balancer ( Layer 7 )
  • Reverse Proxies for security of internal IPs and port
  • Security controls In compliance with ISO/IEC 27000 family – Information security management systems
  • PKI Infrastructure to manage digital certificates
  • Key management with HSM ( hardware security Module )
  • truster CA ( Certificate Authority ) to issue publicly signed certificate for TLS ( Https , wss etc)
  • OWASP ( Open Web Application Security Project )  rules compliance

Integral Components of a VOIP SIP based architecture

sip entities

  • Call Controller
  • Media Manager
  • Recording
  • Softclients
  • logs and PCAP archives
  • CDR generators
  • Session Borer Controllers ( SBCs)

 

Detailing some of the protocols apart from SIP used in VOIP solution

RTP ( Real Time Transport Protocol )

RTP handles realtime multimedia transport between end to end network components . RFC 3550 .

Packet structure of RTP     Image result for RTP packet structure

RTP Header contain timestamp , name of media source , codec type and sequence number .

Image result for RTP header structure

RTCP

DTMF( Dual tone Multi Frequency )

delivery options:

  • Inband –  With Inband digits are passed along just like the rest of your voice as normal audio tones with no special coding or markers using the same codec as your voice does and are generated by your phone.
  • Outband  – Incoming stream delivers DTMF signals out-of-audio using either SIP-INFO or RFC-2833 mechanism, independently of codecs – in this case the DTMF signals are sent separately from the actual audio stream.

SIP Gateways:

A SIP gateway is an application that interfaces a SIP network to a network utilizing another signaling protocol. In terms of the SIP protocol, a gateway is just a special type of user agent, where the user agent acts on behalf of another protocol rather than a human. A gateway terminates the signaling path and can also terminate the media path .

sip gaeways

To PSTN for telephony inter-working
To H.323 for IP Telephony inter-working
Client – originates message
Server – responds to or forwards message

 

Logical SIP entities are:

User Agent Client (UAC): Initiates SIP requests  ….
User Agent Server (UAS): Returns SIP responses ….
Network Servers ….

Registrar Server

A registrar server accepts SIP REGISTER requests; all other requests receive a 501 Not Implemented response. The contact information from the request is then made available to other SIP servers within the same administrative domain, such as proxies and redirect servers. In a registration request, the To header field contains the name of the resource being registered, and the Contact header fields contain the contact or device URIs.

regsitrar server

Proxy Server

A SIP proxy server receives a SIP request from a user agent or another proxy and acts on behalf of the user agent in forwarding or responding to the request. Just as a router forwards IP packets at the IP layer, a SIP proxy forwards SIP messages at the application layer.

Typically proxy server ( inbound or outbound) have no media capabilities and ignore the SDP . They are mostly bypassed once dialog is established but can add a record-route .
A proxy server usually also has access to a database or a location service to aid it in processing the request (determining the next hop).

proxy server

 1. Stateless Proxy Server
A proxy server can be either stateless or stateful. A stateless proxy server processes each SIP request or response based solely on the message contents. Once the message has been parsed, processed, and forwarded or responded to, no information (such as dialog information) about the message is stored. A stateless proxy never retransmits a message, and does not use any SIP timers

2. Stateful Proxy Server
A stateful proxy server keeps track of requests and responses received in the past, and uses that information in processing future requests and responses. For example, a stateful proxy server starts a timer when a request is forwarded. If no response to the request is received within the timer period, the proxy will retransmit the request, relieving the user agent of this task.

  3 . Forking Proxy Server
A proxy server that receives an INVITE request, then forwards it to a number of locations at the same time, or forks the request. This forking proxy server keeps track of each of the outstanding requests and the response. This is useful if the location service or database lookup returns multiple possible locations for the called party that need to be tried.

Redirect Server

A redirect server is a type of SIP server that responds to, but does not forward, requests. Like a proxy server, a redirect server uses a database or location service to lookup a user. The location information, however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes the transaction. Contact header in response indicates where request should be tried .

redirect server


External components to setup a VOIP solution apart from Core voice Servers and gateways

  • Payment Gateways
  • Billing and Invoice
  • Fraud Prevention
  • Contacts Integration
  • Call Analytics
  • API services
  • Admin Module
  • Number Management ( DIDs ) and porting
  • Call Tracking
  • Single Sign On and User Account Management with Oauth and SAML
  • Dashboards and Reporting
  • Alert Management
  • Continuous Deployment
  • Automated Validation
  • Queue System
  • External cache

SIP ( Session Initiation Protocol )

Update :

At the time of writing this article on SIP and related VOIP technologies I a newbie in VOIP domain , probably just out college . However over the past decade , looking at the steady traffic to these articles , I have tried updating the same with new RFC standards and market trends .


SIP ( Session Initiation Protocol) negotiates session between 2 parties.  It primarily exchanges headers that are used for making a call session such as example of outgoing telephone call from SIP session invite . It is a L

Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:altanai@telecomcompany.com;transport=tcp SIP/2.0
Method: INVITE
Request-URI: altanai@telecomcompany.com;transport=tcp
        Request-URI User Part: altanai
        Request-URI Host Part: telecomcompany.com
        [Resent Packet: False]

Message Header

Via: SIP/2.0/TCP 1.2.3.4:5080;rport;branch=z9hG4bKceX7a2H2866cN
        Transport: TCP
        Sent-by Address: 1.2.3.4
        Sent-by port: 5080
        RPort: rport
        Branch: z9hG4bKceX7a2H2866cN

Max-Forwards: 41

From: "+16014801797" <sip:+16014801797@1.2.3.4>;tag=7HKgjNQ6y2FSj
        SIP Display info: "+16014801797"
        SIP from address: sip:+16014801797@1.2.3.4
                SIP from address User Part: +16014801797
                E.164 number (MSISDN): 16014801797
                        Country Code: Americas (1)
                SIP from address Host Part: 1.2.3.4
        SIP from tag: 7HKgjNQ6y2FSj

To: <sip:altanai@telecomcompany.com;transport=tcp>
        SIP to address: sip:altanai@telecomcompany.com;transport=tcp
        SIP to address User Part: altanai
        SIP to address Host Part: telecomcompany.com
        SIP To URI parameter: transport=tcp

Call-ID: e10306be-0cfd-4b38-af3c-b2ada0827cef
CSeq: 126144925 INVITE
Contact: <sip:mod_sofia@1.2.3.4:5080;transport=tcp>
User-Agent: phone1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: path, replaces
Allow-Events: talk, hold, conference, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 249
SIP Display info: "+16014801797"
SIP PAI Address: sip:+16014801797@1.2.3.4

The SIP philosophy :

  • reuse Internet addressing (URLs, DNS, proxies)
  • utilize rich Internet feature set
  • reuse HTTP coding
  • text based
  • makes no assumptions about underlying protocol:
    TCP, UDP, X.25, frame, ATM, etc
  • support of multicast

SIP URI can either be in format of sip:altanai@telecomcompnay.com (RFC 2543 ) or sips:altanai@telecomcompany.com ( secure with TLS over TCP RFX 3261) . Additionally SIP URI resolution can either be

  • DNS SRV based such as altanai@telecomcompnay.com with SIP servers locating record for domain “telecomcompnay.com ” or
  • FQDN ( Fully qualified domain name ) / contact / ip address based such as altanai@2.2.2.2 or altanai@us-west1-prod-server . Both of which do not need any resolution for routing.

Tags are pseudo-random numbers inserted in To or From headers to uniquely identify a call leg

Max forwards  is a count decremented by each proxy
that forwards the request.When count goes to zero, request is discarded and 483
Too Many Hops response is sent.Used for stateless loop detection.

Content-Type indicates the type of message body attachment. In this case application /SDP but  others could be text/plain, application/cpl+xml, etc.)

Content-Length indicates the octet (byte) count of the message body

Firewalls can sometimes block SIP packets , change TCP to UDP or change IP address of the packets. Record-Route can be used , ensures Firewall proxy stays in path . Clients and Servers copy Record-Route and put in Route header for all messages

Message body is separated from SIP header fields by a blank line (CRLF).

sip arch

SIP transaction

A SIP transaction occurs between a UAC and a UAS. The SIP transaction comprises all messages from the first request sent from the UAC to the UAS up to a final response (non-1xx) sent from the UAS to the UAC

Branch

The branch parameter is a transaction identifier. Responses relating a request can be correlated because they will contain the same transaction identifier.

Dialog

The initiator of the session that generates the establishing INVITE generates the unique Call-ID and From tag. In the response to the INVITE, the user agent answering the request will generate the To tag. The combination of the local tag (contained in the From header field), remote tag (contained in the To header field), and the Call-ID uniquely identifies the established session, known as a dialog. This dialog identifier is used by both parties to identify this call because there could be multiple calls set up between them.

Components of SIP Solution

Screen Shot 2018-08-16 at 10.11.14 PM

SIP Request methods :

  1. INVITE : Initiates negotiation to establish a session ( dialog). Usually contains SDP payload. Another invite during an existing session ( dialog) is called an RE-INVITE. A RE-INVITE can be used for
    • hold / resume a call
    • change session parameters and codecs in mid of a call
  2. ACK : Acknowledge an INVITE request by completing the 3 way handshake . If an INVITE did not contain media contain then ACK must contain it .
  3. BYE : Ends a session ( dialog).
  4. CANCEL : Cancels a session( dialog)  before it establishes  .
  5. REGISTER : Registers a user location (host name, IP) on a registrar SIP server.
  6. OPTIONS : Communicates information about the capabilities of the calling and receiving SIP phones ( methods , extensions , codecs etc )
  7. PRACK : Provisional Acknowledgement for provisional response as 183 ( session in progress) . PRACK only application to 101- 199 responses .
  8. SUBSCRIBE : Subscribes for Notification from the notifier. Can use Expire=0 to unsubscribe.
  9. NOTIFY : Notifies the subscriber of a new event.
  10. PUBLISH : Publishes an event to the Server.
  11. INFO : Sends mid session information.
  12. REFER : Asks the recipient to issue call transfer.
  13. MESSAGE : Transports Instant Messages.
  14. UPDATE : Modifies the state of a session ( dialog).

Some SIP responses :

1xx = Informational SIP Responses
100 Trying
180 Ringing
183 Session Progress

2xx = Success Responses
200 OK – Shows that the request was successful

3xx = Redirection Responses

4xx = Request Failures
401 Unauthorized
404 Not Found
405 Method Not Allowed
407 Proxy Authentication Required
408 Request Timeout
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
482 Loop Detected
483 Too Many Hops

5xx = Server Errors
500 Server Internal Error
503 Service Unavailable

6xx = Global Failures
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

SIP callflow diagram for a Call Setup and termination using RTP for media and RTCP for control.

Screen Shot 2018-08-16 at 10.17.57 PM

SIP Transport Layers

We know the ISO OSI layers  which servers as a standard model for data communications .

sip 3

  1. Physical Layer : Ethernet , USB , IEEE 802.11  WiFi, Bluetooth  , BLE
  2. Data Link Layer : ARP ( Address Resolution Protocol ) ,  PPP ( point to point protocol ) , MAC ( Media Access control ) , ATM , Frame Relay
  3. Network Layer :  IP (IPv4 / IPv6), ICMP, IPsec
  4. Transport : TCP , UDP , SCTP
  5. Session : PPTP ( Point to point tunnelling protocol) , NFS, SOCKS
  6. Presentation : Codecs such as JPEG , GIFF , SSL
  7. Application : Application level like Call -manager/ softphone  as HTTP , FTP , DNS , SIP  , RTSP , RTP , DNS

SDP ( Session Description Protocol)

SIP can bear many kinds of MIME attachments , one such is SDP. It uses RTP/AVP Profiles for common media types . Specified by RFC 3264 . It defines media information and capabilities such as codecs , termination points .

Contains connection headers used for establishing the session . Sample SDP payload for Invite SIP above :

Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): FreeSWITCH 1532932581 1532932582 IN IP4 1.2.3.4
        Owner Username: FreeSWITCH
        Session ID: 1532932581
        Session Version: 1532932582
        Owner Network Type: IN
        Owner Address Type: IP4
        Owner Address: 1.2.3.4
Session Name (s): FreeSWITCH
Connection Information (c): IN IP4 1.2.3.4
        Connection Network Type: IN
        Connection Address Type: IP4
        Connection Address: 1.2.3.4
Time Description, active time (t): 0 0
        Session Start Time: 0
        Session Stop Time: 0
Media Description, name and address (m): audio 29398 RTP/AVP 0 101
        Media Type: audio
        Media Port: 29398
        Media Protocol: RTP/AVP
        Media Format: ITU-T G.711 PCMU
        Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
        Media Attribute Fieldname: rtpmap
        Media Format: 0
        MIME Type: PCMU
        Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
        Media Attribute Fieldname: rtpmap
        Media Format: 101
        MIME Type: telephone-event
        Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
        Media Attribute Fieldname: fmtp
        Media Format: 101 [telephone-event]
        Media format specific parameters: 0-16
Media Attribute (a): silenceSupp:off - - - -
        Media Attribute Fieldname: silenceSupp
        Media Attribute Value: off - - - -
Media Attribute (a): ptime:20
        Media Attribute Fieldname: ptime
        Media Attribute Value: 20

 v=0  indicates the start of the SDP content.

o=FreeSWITCH 1532932581 1532932582 IN IP4 1.2.3.4 , is session origin and owner’s name

c=IN IP4 1.2.3.4 is connect information Specifies the IP address of a session.  

m= is Media type – audio, port – 29398, RTP/AVP Profile – 0 and 101

Attribute profile – 0, codec – PCMU, sampling rate – 8000 Hz and Attribute profile – 101, telephone-event

SIP Authorization

authentication , security , confidentiality and integrity form the basic requirement for any communication system .

To protect against hacking a user account and Denial of service attacks  , SIP uses HTTP digest authentication mechanism. Here the SIP request is responded with challenge and nonce . The sender has to resend the request with MD5 hash of nonce and password ( password id never send in clear ) . Thus preventing man-in-middle attacks.

Challenge / Response Scheme :

  • Sends REGISTER   and receives 407 Challenge + nonce                           
  • Again sends REGISTER + MD-5 hash (pw + nonce) get a 200 OK

To prevent spoofing ie impersonating as server , SIP provides server authentication too. Required by ITSP’s  ( Internet telephony service providers ) .

Mobility

To provide session mobility SIP endpoints send Register request to their respective registrar as they move and update their location.

As User changes terminals , they registers themselves to the appropriate server
Location server tracks the location of user
Redirect servers prioritize the possible locations of the user
Users keep same services as located at home server, while mobile
Call is processed by home servers using RECORD-ROUTE

NAT

National Address Translator , defined by RFC 3022 to conserve network space as most packets are exchanged inside a private network itself .

All internet users whether they are using Wifi , 3G/LTE,  home AP, any other telecom data packet network  by TSP or ISP , are assigned a private IP address , which is unreachable from out side world .Addresses are assigned by Internet Assigned Numbers Authority (IANA). Private address blocks are in format of 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

Therefore when they access the Internet , this address is converted into a  globally unique public IP address through a NAT for external communication

Screen Shot 2018-08-18 at 4.33.06 PM

SIP Issues around NAT

NATs modify IP addresses (Layer 3)- SIP/SDP are Layer 7 protocols – transparent to NAT

SIP Via:, From: and Contact: headers use not-routable private addresses
SDP states that originator wishes to receive media at not-routable private addresses
If destination on the public internet tries to send SIP or RTP traffic to those private address
Traffic will be dumped by first router

Solution are to use  either Application level gateway (ALG) or STUN or Universal Plug and Pray (UPnP)

To rewrite all SIP/SDP source addresses

  • SIP Via:, From: and Contact: headers use public NAT address
  • SDP addresses use NAT public address
  • Use SIP over TCP

Use draft-ietf-sip-symmetric-response-00 and “Symmetric” SIP/RTP
Use same UDP port number for incoming/outgoing
Hold ports open for call duration
Send UDP packet typically every 30 seconds
SIP over UDP uses 30 second re-INVITE, REGISTER or OPTIONs
RTP sends at much higher frequency by default

NAPT ( Network Address Port Translator )

  • Can map multiple private IP addresses and ports to one public IP address and ports

SIP Flows

Registration

Localization Server  –Used by the Proxy Server and Redirect Server to obtain the location of the called user (one or more addresses)

Registration Server- Accept registration requests from the client applications . Generally, the service is offered by the Proxy Server or Redirect Server

DNS Server – Used to locate the Proxy Server or Redirect Server

Screen Shot 2018-08-18 at 12.46.14 PM

Call Redirection

Sending Call invite but as Redirect Server responded with 302 moved temporary , a new destination address is returned. The invite is forwarded to another proxy server which connects the sip endpoints again after consultation with Redirect server .

Screen Shot 2018-08-18 at 10.37.38 AM

In this stage of we see the call getting connected to sip endpoint via 2 proxy servers . The redirect server doesnt get into path once the initial sip request is send.

Screen Shot 2018-08-18 at 11.12.17 AM

After communication the endpoints send BYE to terminate the session

Screen Shot 2018-08-18 at 11.13.59 AM

 

Forking

This callflow deals with the use-case when a user maybe registered from multiple SIP phones ( perhaps one home phone , one car and one office desk etc ) and wants to receive a ring on all registered phone ie fork a call to multiple endpoints .

Screen Shot 2018-08-18 at 11.17.19 AM

In the above diagram we can see a forked invite going to both the sip phones . Both of them reply with 100 trying and 180 ringing, but only 1 gets answered by the user .

Screen Shot 2018-08-18 at 11.17.26 AM

After one endpoint sends 200 ok and connects with session , the other receiver a cancel from the sip server .

Screen Shot 2018-08-18 at 11.17.33 AM

Click to Dial

A web or desktop application which has HTTP can fire a API call which is interpreted by the controller or SIP server  and call is fired .

Screen Shot 2018-08-18 at 1.23.36 PM

The API can contain params for to and from sip addresses as well as any authentication  token that is required for api authentication and validation .

Source code for some of the SIP application can be found on github 

https://github.com/altanai/sip-servlets

 

SIPMLE

SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)

  • several vendors who intend to implement SIMPLE
  • provides for presence and buddy lists
  • Instant Messaging in the enterprise
  • telephony enabled user lists

 

Using SIP based Call routing algorithms and flows , one can build carrier grade communication solution . SIP solutions can hook up with existing telecom networks and service providers to be backward compatible . Also has untapped unlimited potential to integrate with any external IP application or service to provide converged , customised control both for signalling and media planes.

References :

  1. SIP by Henning Schulzrinne Dept. of Computer Science Columbia University New York
  2. International Institute of Telecommunications 2000-2004
  3. Introduction to SIP by Patrick Ferriter from ZULTYS
  4. Internet Draft, IETF, RFC 2543
  5. NTU – Internet Telephony based on SIP

Unified Communications and Collaborations ( UC&C )

The rapidly changing scene of telecoms operations , brings to light many challenges faced by an telcos and service providers as they cater to the end users , with swift and innovative services , while at the same time keeping surcharge operational costs at bay .
Today a client expects converged orchestrated harmonized applications bringing call control and customizing features, all under one roof .

What is Unified Communication ? 

Unified Communications solutions bring together voice, messaging, video, and desktop applications to enable companies to quickly adapt to market changes, increase productivity, improve competitive advantage and deliver a rich-media experience across any work space.

Unified Communications (1)

Unified Communications

Components of Unified Communications.

The latest UCC solutions are based on open standards such as  SIMPLE/XMPP protocols or socket.io and REST webservices

  • Communications:                                        Voice, data, and video
  • Messaging:                                                     Voice, email, video, and IM
  • Conferencing:                                               Online, audio, and video
  • Application integration:                          Microsoft Office and CRM
  • Presence:                                                       IP phone, desktop clients, and call connectors
  • Common user experience:                     Desktop, phone, and mobility
  • Cloud / Virtualization                               Network Provisioning , Virtualized Applications

Video feature of UCC further has many aspects

  • Codecs : H323,H264,vp8/vp9 for video
  • Scalable Video Coding (SVC)
  • USecase : Call , conference , Broadcasting , Livestreaming

Audio aspects

  • Codecs like OPUS, AAC
  • Service like : voice Mail , IVR , auto attendant with Voice XML

 

What is the need of Unified communication ?

Currently the mode of communication across various users differs such as emails , SMS, VOIP call , GSM call , message on other platform etc .
These random forms of communication cannot be tracked and hamper fast decision making .

uc

Challenges with Unified Communications

  • Adds complexity in to already complex infrastructure
  • Lack of standardization
  • Organization Infrastructure and Bandwidth Limitations
  • Integration of services from different application platforms like emails
  • migrating existing communication infrastructure like desk phones
  • Interfacing of telephony applications with Business Applications such as CRMs

Types of UCC solutions

There exists broadly two types of UC&C solution – On-premise and cloud based . The fundamental difference is the location of the backend infrastructure supporting the communication system . Some more differences are outlined in table below:

On -premise Cloud Based
Mostly in SaaS nature ( software as a service )

Hosted by the consumer / business unit itself
more customizability and flexibility
more investment and maintenance

Service provider offers his infrastructure to the consumer as a service  
bills monthly / yearly etc
quick setup
lower upfront payment
billing is either per user basis or on consumption .
data is synced to cloud servers for storage and can be fetched from there when required such as cloud synced Call-logs or contact-book

Device / Platform Agnostic

The UCC clients are designed keeping mobility in mind . Thus UC  Solutions are made compatible with online provisioning / portal system , native mobile apps like android /ios , Desktop app for linux, mac, windows etc .

Unified Communications

UC&C + CRM

UC&C models integrates with Enterprise and Customer Relation Management Systems (CRM). Therefore provides unified messaging across teamspace/workspace/workflow management systems . It is trackable and can be used for realtime notification and analytics .

SRS TFX service suite (2)

SRS TFX service suite

SRS TFX service suite (1)

This directly ensures boost in sales and profitability by quick communication between customers / partners / eco-system / sales-rep / developers / field agents and others part of the communication system.

SME adopt UCC solutions

SME ( Small and Medium Enterprises) are first to adopt UC&C due to absence of  already setup traditional communication infrastructure like PSTN lines , desktop phones , special handsets etc .

Factors like :

  • quick setup
  • low budget of UC&C solutions
  •  BYOD ( Bring your Own Device ) to work

enable SMEs to adopt UC&C solution much faster and readily.
It has multiple advantages like:

  1. All information is stored in one place therefore easier to retrieve
  2. Increased Productivity
  3. Greater flexibility
  4. Faster Response and Information delivery

Future of UCC

  1. Context Driven + Real Time Analytics
  2. Monitization by cross vertical integration
  3.   Integration with IOT
  4. Automation for Billing and Operation – OSS/BSS
  5. Machine Learning
  6. Big Data Management

 

In conclusion UC&C is aimed at providing inter operable communications with ubiquitous coverage for applications and devices such as desktops , IP phones , smartphones, smart watches , kisosk etc . It means web , native apps and IP phones having the ability to create, share and participate in integrated multimedia ( like audio, video , desktop, files ) collaboration.