2014 innovaphone different protocols for different things

H.323, SIP, H460.17, ICE, DTLS-SRTP, WebRTC… different protocols for different things

Unified Communications by innovaphone

Jueves, 9 de Octubre 2014 Victor M. Moracho Oliva vmo@innovaphone.com Area Sales Manager IBERIA

Fabricante Alemán

Empresa tecnológica oriententada al sector profesional

Comunicaciones IP para empresas cuidando el diseño y un manejo

intuitivo: Diseño e Innovación.

Fundada en 1997 por el Consejo Directivo actual.

Las oficinas centrales se hallan en Sindelfingen (Stuttgart)

y con otras 5 sedes en toda Europa.

innovaphone AG no cotiza en Bolsa y es 100% capital privado.

Bajo la marca „innovaphone PBX“ se engloba una completa solución de

comunicaciones IP (Comunicaciones Unificadas - UC) para empresas.

innovaphone AG

Agenda: Different Protocols for Different Things

SIP vs. H.323

H.460.17 & STUN Server

ICE & DTLS-SRTP

WebRTC & ORTC

The Real Time Multimedia Questions:

Where am I and how do I find someone else?

Am I allowed to make/receive a call?

What sort of session – voice, video, messaging?

– Endpoint Registration and Call Routing

– Call Admission Control & Establishment

– Media Negotiation & Media Transport

Unified

Communications

IP-DECT

SIP Provider

PBX

Legacy

PBX

WiFi

Analog Adapter

ISDN

Mobile

Integration

IP Phones

IP PBX

ISDN

Cloud - IPVA

innovaphone Complete Solution

SIP & H.323: Multiprotocolo y estándares

Mayor escalabilidad e interoperabilidad máxima!

Gateway Interfaces ISDN/Analog

DSPs para Transcoding/Conferencing Relay para registros de números de llamada

PBX H. 323 Gatekeeper / SIP Proxy

Telco-Interfaces LDAP Server

Conectores para 3rd Party Applications

Linux Application Plattform

Fax to Email Exchange Connector

Reporting más…

Aplicaciones UC

myPBX UC Client (CTI/Presence/Chat/Video)

Voicemail Audioconference Server

Mobilityfunktion Queue Monitor

The „VoIP War“: SIP vs. H.323

SIP H.323

1996

SIP and H.323 are equivalent

Similarities

- Use RTP and RTCP for media transport

- Support call routing through

proxies/gatekeepers using username,

phone numbers or URLs

- Similar flows

Differences

- ITU and IETF

- Encoding (ASN.1 vs.Text)

- Standardized Feature sets - Conference control

- Attended and blind transfer

- Caller Preferences

H.323 SIP

SIP and H.323: pros and cons

Advantages

- H.323 is more teleco-oriented and provides decentralized (GWs, terminals,.)

and well-defined architecture supporting peer-to-peer

- SIP is more flexible (internet-oriented) and easier to develop and

requiresonly a proxy server to route calls.

While SIP is extremly flexible and can be adapted for the use of other

applications, H.323 offers better network management and call control.

INTEROPERABILITY!!!

Disadvantages

- H.323 any update of the standard requires backward compatibility with the

existing standard.

- SIP can result in interoperability problems due to different implementations

of the standard.

Both of them, SIP & H.323, are necessary to provide universal access

and to support value-add IP services.

H.460.17

STUN Server

H.460.17

Basic protocol „without fireworks“, however you can set up a telephony

scenario very easily.

The innovative application:

– So far for H.323 with UDP for RAS and TCP for H.225

– Now is used from RAS inside H.225

– Thereby can reach the TCP/TLS connection to the well-known Port

1720/1300

– In order to let the Signaling in a Private Network over the inbound

Mapping

Advantages

– Still safe and secure through TLS

– The PBX can check external Devices Certification

– For Siganalling no VPN is needed.

Configuration: directly on the Phone

STUN Server Configuration

Actually you don‘t need one of your own, but you can use any if you still

want to connect it.

But: For test purposes we

used one STUN Server.

It was very easy to

implement

(<100 Lines Code)

It is not neccesary to

depend on foreign

infrastructure as

necessary

For this case the STUN

server is part of the NAT

router so only one

public IP address is

needed

H.460.17/STUN

Internet

PBX

STUN

NAT NAT

Fritz-Box

Private Network 192.168.0.x outgoing call

H.323 goes thru NAT via

STUN in order to build the RTP Mapping

Private Network 172.16.x.x

NAT. Inbound Mapping for H.323/H.460.17

STUN carries out the RTP Mapping

Note: Only works with ICE because it depends on where are the Phones and each

of them is required to provide location

STUN (Session Traversal Utilities for NAT) is a network protocol to allow an end

host to discover its public IP address if it is located behind a NAT.

The STUN server allows NAT clients to find out their public address. A STUN

server allows IP Phones behind a firewall to setup calls outside of the local

network.

H.460.17/STUN in a Home Office Szenario

Home Office integration is realized currently over

PPTP – Often desire for higher security (eg. IPSEC)

– Architecture challenge, since PPTP is not always

possible? (GuestWLAN etc.)

The answer:: – Use of a standardized H.323 registration directly over

the Internet via H.460.17

– Admitted even in high security environments such

Banks

www

PSTN

1. Telefon registriert sich über

das Internet via H.323/TLS an

der PBX

2. Der Ende zu Ende Weg

erfolgt verschlüsselt via

DTLS

ICE

DTLS-SRTP

ICE (Interactive Connectivity Establishment):RFC 5245

Protocol to find and select the network way between two terminals.

DTLS-SRTP (DTLS Extension to Establish Keys for SRTP): RFC 5245

Setup an encrypted conversation over an unsafe infrastructure

What's this?

Two new standards for connection of media channels

Focus on communication over the public Internet, instead of only on the local network

Why do we need now?

Mandatory for WebRTC

Meaningful standards, solve the problems that affect us

Compatibility with peers in the future

ICE & DTLS-SRTP: Motivation

The siganlling provide for each side an IP-Adress

In local Networks is not problem to can set up a call

ICE – Problem Solving

The problem come when both sides are in different Networks

Or what happens if both side have different IP versions.

Candidates are all network addresses (incl. Port), under which an endpoint could be reached.

ICE – Candidates

a=candidate:1 1 UDP 2130706431 172.16.4.62 16394 typ host

a=candidate:1 2 UDP 2130706430 172.16.4.62 16395 typ host

a=candidate:2 1 UDP 1694498815 145.253.157.4 50096 typ srflx raddr 172.16.4.62 rport 16394

a=candidate:2 2 UDP 1694498814 145.253.157.4 50097 typ srflx raddr 172.16.4.62 rport 16395

a=candidate:3 1 UDP 2121609471 fec0:9033::290:33ff:fe2f:3da 16394 typ host

a=candidate:3 2 UDP 2121609470 fec0:9033::290:33ff:fe2f:3da 16395 typ host

a=candidate:4 1 UDP 2121609471 2002:91fd:9d04:0:290:33ff:fe2f:3da 16394 typ host

a=candidate:4 2 UDP 2121609470 2002:91fd:9d04:0:290:33ff:fe2f:3da 16395 typ host

Check the connectivity of each candidate pair using STUN

Selection of an effective path through the controller

ICE – Connectivity check

ICE – Interconnection

The media stream is started on the selected path

In case there is not working path, the call is terminated.

Benefits

RTP through NAT boundaries without VPN or Media Relay

Selection of the network interface

Selection between IPv4 and IPv6

Prevent one-way audio and no audio

For encrypted calls (SRTP) both endpoints require a shared key.

How to transfer the key safe from one end point to another?

SRTP – „Key Exchange“

Key exchange with the signaling

Hop-by-hop encryption

All PBXs see the SRTP key

SDES – „Key Exchange“

A compromised PBX can forward key and link data to an attacker.

The attacker can then decrypt and listen and record conversations.

SDES – Attack scenario

Key exchange in the media inband channel using DTLS

End-to-end encryption

Only the endpoints see the key in plain text

DTLS-SRTP - „Key Exchange“

Advantages

End-to-end encryption

No confidence necessary in infrastructure

Manual detection of man-in-the-middle attacks by Key Fingerprint

Suitable for Internet telephony!

Disadvantages

Computational intensive

Additional delay at the beginning of a conversation

DTLS-SRTP – Assessment

Configuration

What is WebRTC?

Open standard for real-time communication

within a web browser WITHOUT additional

plugins

Driven by Google, Mozilla

Foundation and Opera Software

WebRTC based on HTML5 and JavaScript

WebRTC based based on various open-source

codecs: Opus (Audio)

VP8 (Video)

Source Wikipedia:

WebRTC was taken as an attack on the

monopoly from Skype on the VoIP Desktop

Appliccations,[7] when Microsoft wanted to put

with Skype itself appears WebRTC.[8]

How does WebRTC work?

WebRTC, establishes beyond corporate boundaries point-to-point

connections. Several architectutal limitation were solved:

Find direct ways behind different routes via STUN and ICE

Support of required codecs

(We focus on the G.711 audio)

End to end encryption using DTLS

Signalling Signalling

Media

Technological structure of WebRTC @ innovaphone

PSTN

2. innoWebphone

registers with the PBX

as to Audio / Video

Device.

3. User selects

WebRTC as

Device to be

controlled from

1. Browser innoWebphone

Ask for perimission to use Micro/Headset

and Camera.Fragt einfach per Kontext nach

Zugriffserlaubnis auf Headset / Kamera

(later can be omitted)

4. call setup

to another subscriber

via G.711

innovaphone WebRTC external

www

PSTN

1. Browser innoWebphone

Ask for perimission to use Micro/Headset

and Camera.Fragt einfach per Kontext nach

Zugriffserlaubnis auf Headset / Kamera

(can also be a customized javascript

widget in an individual design )

2. Browser application

innoWebphone

Registers with the PBX

as audio / video device to

3. The end-to-end path for

audio / video data to that

device will be establisched

(STUN und ICE)

4. This device can be like any other

innovaphone device, achieved and

controlled.

Call Me

Innovaphone WebRTC DEMO

Very easy Configuration: Objects plus WebRTC capability

Advantages and additional Options with WebRTC

Due to a more secure encryption method with DTLS a "key pair" is only

known at the endpoints.

innoWebphone can be much easier implemented as a „Javascript Widget“

into any existing website as a communication path.

WebRTC allows through the option DATA to transfer other encrypted

Content. Since innovaphone Application Sharing (View) is also based

exclusively on browser technology, you don’t need any plugin.

WebRTC will be supported on all browsers and is therefore usable across

platforms (MacOS, Linux, Android, etc.). Interoperability

Thanks to the support in the innovaphone PBX, it is possible to carry out an

end-to-end connectivity without gateways and other "bottlenecks“.

How are other Vendors position in WebRTC

Source: onsip

http://www.onsip.com/files/images/Telecom-WebRTC-Infographic-OnSIP.png

WebRTC is here to stay

Why is so attractive for developers: Manage multiple media channels

HighPerforming Audio&Video by adapting to network

Conditions

Use in concert with HTML5 to create communications

apps

Easily create videoconferencing solutions

Ensures that collaborating parties have the same

technology

Alliviates privacy and security fears of downloading

plugins

Disagreement with the use of SDP (Session

Description Protocol) in WebRTC.: unneeded – much too high level an API

arcane format – legacy and problematic

offer/answer

incompatibilities

lack of API contact

doesn’t truly solve goal of compatibility to legacy systems

The Future of WebRTC: ORTC (Object RTC)

The Future Work

2015

innovaphone AG

Böblinger Straße 76

D-71065 Sindelfingen

Germany

www.innovaphone.com

info@innovaphone.com

Vielen Dank für Ihre Aufmerksamkeit!