Upload
voip2day
View
124
Download
2
Embed Size (px)
DESCRIPTION
H.323, SIP, H460.17, ICE, DTLS-SRTP, WebRTC… different protocols for different things
Citation preview
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 [email protected] 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
Vielen Dank für Ihre Aufmerksamkeit!