VoIP

Transcrição

VoIP

VoIP – Voice over IP
Prof. Dr.-Ing. habil. Lutz Winkler
Fakultät Elektro- und Informationstechnik
https://www.telecom.hs-mittweida.de
[email protected]
2015-11
Ziel und Inhalt der Vorlesung

Ziel
–
–
–

Prinzip von VoIP, Unterschiede zur klassischen Telefonie
Implementationsansätze von ITU und IETF
Funktion und Nutzung typischer Protokolle
Inhalt
Einführung ...............................................................................................................................................
Standardisierung .....................................................................................................................................
ITU-H.323-Lösung ...................................................................................................................................
ITU-H.323-Beispiel ..................................................................................................................................
IETF-SIP/SDP-Lösung ............................................................................................................................
IETF-SIP/SDP-Beispiele .........................................................................................................................
IETF-SDP ................................................................................................................................................
RTP …………….......................................................................................................................................
Probleme bei VoIP durch NAT/NAPT …………………............................................................................
STUN, TURN .........................................................................................................................................
Literatur ...................................................................................................................................................
Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
3
10
12
20
23
47
46
67
72
78
85
2
Einführung: VoIP – Voice over IP

Bisher wurde Sprachkommunikation über leitungs- und kanalvermittelnde Netze
abgewickelt, z.B.  Fernsprechnetze, Funkfernsprechnetze.

VoIP ist:
– Realisierung von Sprachkommunikation über paketvermittelnde Netze, z.B. Internet.
– Diese Idee wird von verschiedenen Standardisierungsgremien und Firmen verfolgt.
– Es gibt eine Vielfalt von VoIP-Lösungen und eine VoIP-Begriffsvielfalt.

Grundsätzlich sind dabei folgende Probleme zu lösen:
– Signalgabe: wie kommt eine Session zwischen Endgeräten zustande?
– Nutzsignalübertragung: wie werden analoge Signale codiert und in Echtzeit über ein
Paketnetz übertragen.

Seit Jahren gibt es schon Internet-Telefonie für PC‘s:
– „Internet Phone“ (VocalTec, 1995), proprietäre Codecs, Protokolle und Verzeichnisdienste,
– "NetMeeting" (Microsoft, 1998) basierend auf H.323,
– “Skype“ (2003 schwedische/dänische Firma, später Microsoft) , proprietäre Codecs, Protokolle und
Verzeichnisdienste.

Wichtige Lösungsansätze für kommerzielle VoIP-Lösungen lieferten und liefern:
– ITU, IETF, Firmen (z.B. CISCO).
3
Einführung: Telefonie über das Fernsprechnetz – Szenario
OVSt
A/D
a/b-Telefon
S0-Bus
NT
ISDN-Telefone
CuDAn
A/D
Steuerung




FVSt
Nutzkanäle
64 kbit/s
Signalgabekanäle
OVSt
Nutzkanäle
64 kbit/s
Steuerung
Signalgabekanäle
D/A
D/A
a/b-Telefon
CuDAn
NT
S0-Bus
ISDN-Telefone
Steuerung
Das Fernsprechnetz stellt analoge (a/b) und digitale (ISDN) Anschlüsse bereit.
Ortsvermittlungen sind über Fernvermittlungen (FVSt) untereinander erreichbar.
Vermittlungssteuerungen nutzen zur Kommunikation untereinander ein Paketnetz.
Jeder Teilnehmer hat eine Rufnummer nach E.163/164 (12-/15-stellig).
E.163_164_address = <Landeskenner><Ortsnetzkenner><Teilnehmernummer>
z.B.
49
3727
551155,
43
1
88024352

Eine Kommunikationsbeziehung hat drei Phasen:
–
Verbindungsaufbau per Signalgabe:
•
•
–
–
das Netz routet einen Weg und schaltet im Erfolgsfall
eine Duplexverbindung zwischen A- und B-Teilnehmer.
Nutzung dieser 64-kbit/s-Verbindung (cs, circuit switched)
Verbindungsabbau über Signalgabe Auslösen der Duplexverbindung
4
Einführung: Telefonie über das Fernsprechnetz – Merkmale
01101111 01001111 11100011 0100010
0101010
64 kbit/s
Fernsprechnetz
Stimmt das?

11111010 00011010 11111111 01010101 01010101
ähhh
PLUS:
– Garantierte QOS, es stehen 64 kbit/s pro Richtung exklusiv zur Verfügung.
– hohe Verfügbarkeit des Fernsprechnetzes und der Endgeräte.

MINUS:
– Schlechte Kanal-Nutzung zu etwa 70% wird „Nichts“ übertragen (Sprechpausen , Duplex).
– 64-kbit/s-Kanäle werden geschaltet, neue Kodierungen benötigen geringere Datenraten:
• ADPCM benötigt nur 32 kbit/s (Adaptive Differenz PCM)
• LD-CELP 16 kbit/s (Code-Excitation Linear Predictive Coding, Sprachzeitabschnitt wird durch Parameter beschrieben).
• LD-ACELP 8 kbit/s.
– Übertragungskapazität der Cu-DA‘n wird bei ab-/ISDN-Fernsprechen „verschwendet“.
– Bei DSL-Nutzung bis zu 50 Mbit/s, bei ISDN-Nutzung 160 kbit/s.
5
Einführung: VoIP Szenario, Ablauf
VoIP-Domain-Controller
VoIPSoftPhone
VoIP-Domain-Controller
VoIPSoftPhone
IP-Router
G
G
VoIPTelefon
VoIPTelefon
IP-Router
Domain a.de
IP-Netz
Domain b.de

Domain-Controller-Aufgaben: Nutzeranmeldung, Adressauflösung SIP-URIIP,
Berechtigungssteuerung, Verbindungsauf-/-abbau usw.

Teilnehmeradressierung ist vielfältiger, gezeigt am Beispiel von SIP:
sip_address = "sip:" (<user>|<phone_number>)"@"(<domain>|<host>|<ip-address>)
• sip:[email protected]
•

...
3-Phasen-Kommunikation:
– Sitzungsanbahnung über Signalgabe zu dem gewünschten B-Teilnehmer.
– Nutzung: digitalisierte Sprache wird paketiert gesendet (ps-cl, packed switched-conectionless)
– Sitzungssabbau über Signalgabe Auslösen der Beziehung.
6
Einführung: VoIP - Prinzip
VoIP-Proxy
a.de
Wahl u. Hörer
abnehmen
A/D
PH
A/D
PH
Nutzung
Sitzungsaufbau
VoIP-Telefon
VoIP-Telefon
SIP+SDP: INVITE
SIP+SDP: INVITE
SIP+SDP: INVITE
SIP: 180 RINGING
SIP: 180 RINGING
SIP: 180 RINGING
SIP+SDP: 200 OK
SIP+SDP: 200 OK
SIP+SDP: 200 OK
SIP: ACK
SIP: ACK
SIP: ACK
IP-Router
RTP: Sprachdaten
RTP: Sprachdaten
IP-Router
RTP: Sprachdaten
RTP: Sprachdaten
usw.
Abbau
Hörer wird aufgelegt



VoIP-Proxy
b.de
IP-Router
RTP: Sprachdaten
RTP: Sprachdaten
RTP: Sprachdaten
RTP: Sprachdaten
usw.
es klingelt
Hörer wird
abgenommen
PH
A/D
PH
A/D
usw.
SIP-Signalgabe: BYE
SIP-Signalgabe: 200 OK
Per SIP-Signalgabe wird über die Domain-Proxies (oder direkt) eine Session errichtet.
Per SDP (Session Description Protocol) werden Parameter ausgehandelt (z.B. Codecs).
Sprachsignale werden in den Endgeräten digitalisiert, packetiert (z.B. 160 Byte,
entspricht 20 ms PCM-codierte Sprache) und mittels RTP/UDP/IP gesendet.
7
Einführung: VoIP - Merkmale

PLUS
– Ein einheitliches paketorientiertes Netz für alle Dienste möglicher Kostenvorteil,
– Mobilität und begleitende Dienste möglich.

MINUS
– Eingeschränkte QOS:
• Codierungs-/Decodierungs-/Laufzeit-Verzögerungen
• Jitter durch unterschiedliche Paketlaufzeiten, Paketverlust
– Verfügbarkeit eingeschränkt (z.B. bei Stromausfall).
packet handler
Datagram i
Datagram x
PH
PCMA/D
R
01010101
00011010
11111010
R
PH
01010101
00011010
11111010
Datagram 1
01101111 01001111 11100011 01000100 01010101
PH
R
01010101
00011010
11111010
R
Datagram 1
01010101
00011010
11111010
Datagram j
PH
PCMA/D
Datagram y
01100001 01001001 11111111 01011100 01000101
8
Einführung: Drei Basisszenarien für VoIP
VoIPVoIP
IP-Netz (Internet)
VoIPGatewayPhone
VoIP/PhoneGateway
IP-Netz
CS-Netz (PSTN)
2
5
P
7
8
0
PhoneVoIPGatewaysPhone
Phone/VoIPGateway
2
5
P
7
8
0
CS-Netz
VoIP/PhoneGateway
Internet
CS-Netz
2
5
P
7
8
0
CS
Circuit Switched (Leitungs-, kanalvermittelt)
PSTN Public Switched Telephony Network (Öffentliches Telefonnetz)
9
VoIP-Standardisierung


Hauptsächlich durch ITU-T, IETF und Firmen (z.B. Cisco).
ITU-T:
– Seit Anfang der 90-er Jahre Basisideenführerschaft
– Grundlegende Verfahren und Komponenten wurden standardisiert in:
• H -Serie: „Audiovisual and multimedia systems“
• G -Serie: „Transmission systems and media, digital systems and networks“
• Q -Serie: „Switching and signalling“
– H.323 (1996): "Packet based multimedia communication systems"
als Sammelbezeichner (umbrella standard) für eine große Anzahl von Standards.

IETF:
– Seit Ende der 90-er Jahre Standardisierung zunehmend Anwendungsführerschaft
• RFC 1889 (1996): RTP - Real Time Protocol Transport von MultiMedia-Echtzeitdaten
• RFC 2327 (1998): SDP - Session Description Protocol Beschreibung einer MM-Session
• RFC 2543 (1999): SIP - Session Initiation Protocol Anbahnung einer MM-Session
– Der IETF-Ansatz liefert einfachere Signalgabeprotokolle gegenüber H.323.
– Inzwischen gibt es Kooperation mit ITU-T, z.B.
• H.248.1/RFC3015 (2000): Megaco – Media Gateway Control Protocol.
• Nutzung ausgewählter ITU-Standards der G-Serie (Codierung) und Q-Serie
(Signalgabe).
10
VoIP-Standardisierung

CISCO: SCCP - Skinny Client Control Protocol
– proprietäres Signalgabeprotokoll zwischen IP-Telefonen und dem so genannten CallManager.
– Endgeräte senden/empfangen einfache Nachrichten die durch den Call Manager
interpretiert/erzeugt werden, wodurch sie auch weniger angreifbar als SIP- oder H.323Endgeräte sind.
– Die Endgeräte sind relativ einfach und benötigen wenig Rechenleistung.
– Nachrichtenbeispiele http://www.protocols.com/pbook/VoIPFamily.htm#Skinny :
SCCP-Messages vom Endgerät
Register Message
Unregister Message
Key Pad Button Message
Enbloc Call Message
Off Hook Message
On Hook Message
– Der Call-Manager nutzt dann aber SIP/SDP
bzw. H.323 als Signalgabeprotokoll.
SCCP-Messages zum Endgerät
Display Text Message
Clear Display Message
Start Tone Message
Stop Tone Message
Set Ringer Message
Set Lamp Message
Endgeräte
Call-Manager
SCCP
SIP/SDP oder
H.323
11
ITU: Multimedia Teleconferencing Standards

Ziel ist Multimedia-Kommunikation Sprache Video Daten

Wichtige Standardserien sind:
– Netzübergreifend, über verschiedene Netze,
– über Netze mit und ohne QoS (Quality of Service),
– Sprachkommunikation ist nur ein Teil.
H.323
H.320
H.324
T.120
(Packet-based Multimedia
Conferencing Systems)
(Narrow-band Visual
Telephone Systems and
Terminal Equipment)
(Terminal for low bit rate
Multimedia Conferencing)
(Data Protocols for
Multimedia Conferencing)
MultimediaKonferenzen über
Netze, die keine
garantierte QOS
bieten
das ISDN unter
Nutzung eines oder
mehrerer B- oder
H-Kanäle
das analoge
Fernsprechnetz
MultimediaKonferenzen
zwischen Terminals
an verschiedenen
Netzen (Filetransfer,
Shared Applications,
Chat, Standbild, Audio,
Video),
12
ITU - H.323: Merkmale

H.323 ist ein (so genannter) Umbrella-Standard und beschreibt Einrichtungen und
Verfahren:
– zur Anbahnung von Sitzungen,
– zur Übertragung von Echtzeitsprache, -video und/oder Daten.

H.323-Standardisierung
– V.1: 1996, „Visual telephone systems and equipment for local area networks which
provide a non guaranteed quality of service “
– V.2,3,4: 1998, 1999, 2000 „Packet-based multimedia communications systems “

H.323-Einrichtungen arbeiten zusammen über folgende Protokolle:
– Managementzwecke und Signalgabe: RAS (Registration, Admission and Status) , Q.931
– Übertragung von Sprach- und Videodaten: RTP (Real Time Protocol).

Über Gateways können H.323-Geräte zusammenarbeiten mit Endgeräten:
– an Fernsprechnetzen,
– an Funknetzen.

H.323-Endgeräte können Teil eines PC‘s oder eine extra Gerät sein.
13
ITU - H.323: Szenario

4 wesentliche Funktionsgruppen – auch Endsysteme
genannt:
H.323H.323–
–
–
–
Terminals
Gatekeeper
MCU
Gateway
Terminal
2
5
7
P
Terminal
2
5
P
7
8
0
8
0
Terminaladapter
Scope
of H.323
Packet switched network
H.323Gatekeeper
H.323-MCU
(Multipoint Control Unit)
Switched
Telephone
Network
H.324
Terminal
Terminal für die MultimediaKommunikation mit geringen
Bitraten. Standards für VideoCodecs mit geringen
Datenraten, die über V.34 mit
analogen Telefonleitungen
arbeiten
H.323Gateway
QOS
LAN
Speech
Terminal
H.322
Terminal
Visual telephone
systems and terminal
equipment for local area
networks which provide
a guaranteed quality of
service
Narrow
ISDN
Speech
Terminal
H.320
Terminal
Funknetze
Terminal
Narrow-band visual
telephone systems
and terminal
equipment
14
ITU - H.323 : Gatekeeper, Multipoint Control Unit (MCU)

Gatekeeper (GK) ist ein (optionaler) Server mit den Aufgaben:
– Zonenmanagement: Registrierung aller Endsysteme oder Endpunkte (Terminals, Multiple
Control Units und Gateways).
– Adressenauflösung: Ermittlung der Transportadresse (IP) aus einem URI.
– Zulassung, Ablehnung von Verbindungen: AdmissionRq, AdmissionCf, AdmissionRj,
innerhalb einer Zone.
– Bandbreitensteuerung: Bandwidth_Rq/Cf/Rj, zur Anforderung/Änderung/Zurückweisung
von Bandbreite.
– Gebührenerfassung.
– Call Management: der GK kann Liste aktiver Terminals führen. Kommt Call für aktives
Terminal wird zurückgewiesen/umgeleitet/zur Sprachbox weitergeleitet.

Multipoint Control Unit (MCU) Konferenzen mit drei und mehr Endpunkten.
– Eine MCU besteht aus:
• einem Multipoint Controller (MC) für Signalisierung zwischen Endpunkten.
• und mehreren Multipoint-Prozessoren (MP‘s)
– Ein MP mixt, kodiert um und vermittelt Audio-, Video- und/oder Datenbits zu den
Teilnehmern einer Konferenz.
15
ITU - H.323 : Gateway

Gateways
–
–
–
bilden Netzübergang zu anderen Netzen (Fernsprechnetze, Funknetze, …)
Verhalten sich aus Sicht der H.323-Zone wie ein H.323-Terminal und aus Sicht z.B. des ISDN wie ein
ISDN-Terminal.
Anpassung der Signalgabe und der Nutzdaten in beide Richtungen.
Voice over CS-Zone
Sprache: PCM, circuit switched
2
5
P
7
8
0
OVSt oder
TK-Anlage
H.323-SoftPhone
2
5
P
7
8
0
Fernsprechnetz- Signalgabe
H.323-Gatekeeper
FVSt oder
TK-Anlage
H.323Gateway
Terminaladapter
2
5
P
7
8
0
VoIP- Signalgabe
Sprache: XX, packet-switched
IP-Netz
H.323-Multipoint
Control Unit
H.323-HardPhone
H.323-Zone - Voice over PS-Zone
16
ITU - H.323 : Terminal und Stack
Data
Applications
System Control User Interface
System Control
Data Interface
T.120
H.245
BearerControl
H.225.0
CallControl
Microphone,
Speaker
Camera,
Display
Audiocodec
G.711, G.728,
Videocodec
H.263, H.261
H.225.0
RAS
TCP
 Anwendungsprotokolle
RTP (RTCP)
UDP
 Transportprotokolle
IP

 Anwendungsteile
Ein Terminal besteht max. aus den gezeigten Funktionsgruppen. Mindestens aber:
– Aus der System Control mit User Interface
– Headset (Micro, Speaker) mit Audiocodecs
– Folgende Audiocodecs müssen mindestens unterstützt werden
• G.711 (A- u. µ-law) und G.728 (LD-CELP, 16 kbps)
• Zulässig: A-Tln. verwendet G.711 und B-Tln. G.728.


Nutz-Transportweg MikroCodecRTP,UDP,IP und umgekehrt
Signalgabe nächste Seite
17
ITU - H.323 : System Control nutzt 3 Protokolle

H.225.0-RAS: Registration, Admission (Zugang, Erlaubnis) and Status
– Finden eines Gatekeepers (GK): GateKeeper_Request/Confirm/Reject,
– An-/Abmelden eines TE beim GK: Registration_Request/Confirm/Reject,
DisEngage_Request/Confirm/Reject
– Kommunikationserlaubnis vom GK einholen: Admission_Request/Confirm/Reject.
– Bandbreite beim GK anfordern: Bandwith_Request/Confirm/Reject

H.225.0-Q.931: Signalgabe zum Sitzungsauf- und –abbau zwischen Terminals
über oder ohne Gatekeeper unter Verwendung von Q.931-Messages, z.B.
SETUP, CALL_PROCeeding, ALERTing, CONNect, INFOrmation,
RELease_COMplete, PROGress, FACility

H.245: Signalisierungsprotokoll zum:
– Austausch von Terminaleigenschaften TerminalCapabilitySet
– Auf-/Abbau logischer Kanäle zur Sprach-/Videoübertragung (z.B. RTP/RTCP-Kanäle):
OpenLogicalChannel, CloseLogicalChannel
– Ermittlung des Round Trip Delay (Umlaufverzögerung der Datenpakte):
RoundTripDelay_Request/Response

T.120: Optional, weitere Datenkanäle für Shared Whiteboard, Chat, Filetransfer
18
ITU - H.323: Prinzip der Protokollnutzung (Kanalnutzung)
Kanal/Aufgabe
AUFBAU
suchen, anmelden, Kommunikations-Erlaubnis,
▲ Bandbreite freigeben, abmelden
Call Signalling Channel:
2
3
Transport Service
H.225.0
UDP
RAS-Channel:
▼ GK
1
Standard
▼ Verbindung
zu B-Tln. herstellen bzw. ▲ abbauen
12
Q.931
TCP
11
Control-Channel
▼ Terminaleigenschaften
austauschen,
logische Kanäle öffnen bzw. ▲ schließen
10
H.245
TCP
4
9
Audio-Channels
G.7xx
RTP,RTCP/UDP
5
6
8
Video-Channels
H.26x
RTP,RTCP/UDP
User-Data-Channels
T.120
TCP
7
ABBAU
nach /STEFFEN/
19
ITU - H.323 : H.245-RAS (GK-Erkundung, An-/Abmeldung am GK)
GK 1
Terminal, MCU, GW
GK 2
Terminal
IP-Netz
GK-Erkundung (GRq, GCf, GRj)
•
IP-Multicastmessage
•
Nichtzuständige GK Reject
•
Mehrere positive Antworten sind
möglich, da GK-Doppelung
(Sicherheit)
•
TE wählt einen GK aus.
•
Option: TE kann GK per DNS
ermitteln
Registrierung beim GK (RRq,RCf,RRj);
Parameter:
•
callSignalAddress: IP-Addr
•
terminalType: TE, MCU, GW
•
terminalAliases: PhoneNr, E-Mail
•
timeToLive: gewünschte Dauer
DeRegistrierung beim GK
(URq,UCf,URj)
Gatekeeper_Rq
IP-Multicast 224.0.1.41, UDP 1718
Gatekeeper_Rj
Gatekeeper_Cf
IP-Unicast-Adresse des GK2
Gatekeeper_Cf
IP-Unicast-Adresse des GK1
Registration_Rq(caSigAddr,teType,teAliases,tToLive)
IP-Unicast, UDP 1719
alt
Registration_Cf(timeToLive)
Registration_Rj(rejectReason,alternateGK)
Unregistration_Rq()
Unregistration_Cf()
alt
Unregistration_Rj(rejectReason)
Weitere Details /BADACH/, /STEFFEN/
224.0.1.41 = Multicastadresse
für H.225 Gatekeeper Discovery
20
ITU - H.323 : H.245-RAS (Location, Admission, Disengage, Bandwidth)
GK 1
Terminal, MCU, GW
Endpunkt-Lokalisierung (LRq,LCf,LRj)
•
Auflösung einer aliasAddress auf
eine callSignalAddress
•
Ein Endpunkt übergibt GK aliasAddr,
die dieser, auch im Zusammenwirken
mit anderen GKs, auf die
callSignalAddress (IP) auflöst.
Erlaubnis einholen (ARq,ACf,ARj)
•
Endpunkte dürfen nur dann gehende
Verbindungen herstellen, bzw.
kommende Verbindungen annehmen,
wenn dies der GK erlaubt.
•
Request-Parameter
•
callModel: direct, gatekeeperRouted
•
bandWidth: AV_bandwidth
GK 2
Terminal
IP-Netz
Location_Rq(aliasAddress)
IP-Multicast 224.0.1.41, UDP 1718
Location_Cf(callSignalAddress)
alt
Location_Rj(rejectReason)
Admission_Rq(callModel,bandWidth)
Admission_Cf(callModel,bandWidth)
alt
Admission_Rj(rejectReason)
DisEngage_Rq()
Verbindungsende (DRq,DCf,DRj)
•
Das Ende einer Kommunikation und
damit Freigabe der Bandbreite muss
dem GK angezeigt werden.
•
War der Endpunkt nicht angemeldet,
reagiert der GK mit Reject
Bandbreitenänderung (BRq,BCf,BRj)
•
Anforderung einer veränderten
Bandbreite gegenüber der, die bei
Admission_Rq gefordert wurde.
DisEngage_Cf()
alt
DisEngage_Rj(rejectReason)
Bandwidth_Rq(bandWidth)
Bandwidth_Cf()
alt
Bandwidth_Rj(rejectReason)
Weitere Details /BADACH/, /STEFFEN/
21
ITU - H.323 : Call Setup and Control (ohne GK)
Terminal, MCU, GW
GK
Terminal
IP-Netz
Wahl u. Hörer
abnehmen
Admission_Rq
Admission_Cf
Kommunikationsablauf
Q.931_SETUP
•
Q.931_CALL_PROC
In diesem Beispiel wird der Call direkt
zwischen den Endpunkten ausgehandelt.
Admission_Rq
Admission_Cf
 Im Admission_Rq
callModel: direct
•
Es ist auch möglich, das der gesamte
Verbindungsaufbau, einschließlich der
Nutzdatenübertragung über den GK
geht.
 callModel: gatekeeperRouted
•
Dieser Fall ist hier nicht
dargestellt!
Q.931_ALERT
es klingelt
Q.931_CONNECT
Hörer
abnehmen
H.245-Channel öffnen
Austausch Terminal_Capabilities
Austausch Terminal_Capabilities
RTP-Kanal öffnen
RTP-Kanal öffnen
Bidirektionaler RTP/UDP-Kanal für Sprache
Kommunikation
Kommunikation
RTP-Kanal schließen
Hörer
auflegen
RTP-Kanal schließen
H.245-Channel schließen
Q.931_RELEASE
Q.931_RELEASE_COMPLETE
DisEngage_Rq()
DisEngage_Cf
DisEngage_Rq()
DisEngage_Cf
22
IETF : VoIP-Protokollübersicht
AnwendungsOberfläche
VoIP-HardPhone/-SoftPhone
AnwendungsTeile
AnwendungsProtokolle
TransportProtokolle
Signalgabe
SIP
Nutzdaten
SDP
Session Description
+ Updates
Protocol
Session Initiation Protocol
RTP
RTCP
Real Time Protocol
RT Control Protocol
TLS
DTLS
Transport Layer Security
Datagram Transport Layer Security
TCP
UDP
IP
Übertragungsnetzwerk (LAN, DSL, Modem)
23
IETF : VoIP-Signalgabeprotokolle und Helfer

SIP Protokoll zur Anbahnung von Multimedia-Sessions aller Art.
–
–
–
–
RFC 3261, 2002 (löste ab den RFC 2543, 1999)
Updated by: 3265, 3853, 4320, 4916, 5393, 5621, 5626, 5630, 5922, 5954, 6026, 6141, 6665, 6878
RFC 3665, 2003 SIP Basic Call Examples
RFC 5359, 2008 SIP Service Examples

SIPS SIP über TLS (Transport Layer Security, hervorgegangen aus SSL - Secure Socket Layer)

SDP Protokoll zur Parametrisierung von Multimedia-Sitzungen.
– RFC 4566, 2006 (löste ab den RFC 2327, 1998)
– SDP-Informationselemente (z.B. Sitzungsname, -inhalt, -zeit, beteiligte Medien, …) werden im SIPMessage Body übermittelt.
– Die Parameter werden ausgehandelt: AngebotAnnahme/Ablehnung
– RFC 3264, 2002 „An Offer/Answer Model with the Session Description Protocol (SDP)”

A Presence Event Package for the Session Initiation Protocol (SIP)
– RFC 3856, 2004
– Server, an dem sich momentan erreichbare Teilnehmer anmelden können. Diese
Erreichbarkeit kann an interessierte Abonnenten verteilt werden.
– Funktion wie “Kontakte” bei Skype: Online-/Offline-Anzeige.
24
IETF : VoIP-Protokolle zur Nutzdatenübertragung

RTP Protokoll zur Übermittlung der Echtzeit-Multimediainhalte, UDP nutzend.
– RFC 3550, 2003 (RFC 1889, 1996)
– Updated by: 5506, 5761, 6051, 6222, 7022, 7160, 7164
– Wichtige Informationselemente:
•
•
•
•

Payload Type: wie sind die Daten codiert
Sequence Number: zur Sicherung der Reihenfolge und Vollständigkeit
Timestamp: zur Zeitsynchronisation
…
SRTP The Secure Real-time Transport Protocol
– RFC 3711, 2004
– Ist ein Profil des RTP, womit Vertraulichkeit, Nachrichtenauthentifizierung RTPDatenverkehr und den Steuerverkehr (RTCP) realisiert werden kann.

RTCP Protokoll zur "Steuerung" von RTP.
– RFC 3550, 2003, Kapitel 6
– Informationselemente: Sender Report, Receiver Report, Source Description und weitere.
– Mit diesen Elementen werden zyklisch ausgetauscht:
• Qualitätsparameter,
• Informationen zu Session-Teilnehmern,
• …
25
IETF: Aufbau SIP-Request-Messages

SIP-Instanzen kommunizieren über Messages.
Man unterscheidet: Request-Messages und Response-Messages.

Request-Messages:
RFC 3261
Request Line
Message Headers
vom Typ: General, Request, Entity
method SP request-URI SP SIP-version CRLF
*( header-name ":" header-value CRLF )
Leerzeile
CRLF
RFC 4566
"v=" (protocol version) CRLF
"o=" (owner/creator session_id) CRLF
"c=" *(connection information) CRLF
...
[Message Body
SDP-Protokoll ]
26
IETF: SIP-Standard-Request-Methoden

Im RFC 3261 werden sechs grundlegende Request-Methoden festgelegt.
Basismethoden
INVITE
Bedeutung



ACK
CANCEL


RFC
Initiierung einer Session. Header-Informationen werden zur Kennzeichnung der Sitzung
genutzt.
INVITE enthält z.B. die SIP-Adresse beider Teilnehmer, einen CallID,
Authentikationsinformationen, …
Im SIP-Message-Body werden SDP-Informationselemente zur Parametrisierung der
Nutzverbindung übertragen.
3261
Finale Empfangsbestätigung einer INVITE-Methode.
Der Empfang von ACK hat keine Response-Message (Statusinformation) zur Folge!
3261
Abbruch der aktuellen Transaktion innerhalb einer Session
3261
Einleitung des Abbaus einer bestehenden Session
3261
REGISTER


Übermittlung von Kontaktinformationen eines SIP-UA zum SIP-Registrar.
Übergeben werden: permanenter SIP-URI (sip:name@domain) und der temporäre URI (IP-Adresse).
3261
OPTIONS



Abfrage der Fähigkeiten von Endsystemen bezüglich ihrer Fähigkeiten (Media Capabilities).
Welche Medien werden unterstützt (Audio, Video), welche Codecs sind vorhanden usw.
Diese Methode kann außerhalb einer Session verwendet werden.
3261
BYE
IETF: Erweiterte SIP-Request-Methoden


Die Steuerung von VoIP-Sitzungen kann recht komplex werden.
Das SIP-Protokoll wurde und wird durch weitere Methoden ergänzt.
Zusatzmethoden
Bedeutung
RFC
INFO
 Transport von Signalgabeinformationen (z.B. ISDN-User-Part-Nachrichten) über das Internet.
 Dies ist z.B. zwischen zwei PSTN-Phone-Gateways notwendig.
6086
REFER
Aufforderung, eine Session zu einem anderen Teilnehmer herzustellen (z.B. zur Realisierung von
3515
Rufweiterleitungen)
SUBSCRIBE
Einleitung einer Zustands-/Ereignisüberwachung
6665
NOTIFY
Meldung eines Zustands bzw. Ereignisses. NOTIFY ist die Reaktion auf SUBSCRIBE oder REFER
6665
PUBLISH
Unaufgeforderte Zustands-/Ereignismeldung von einem SIP-UA an einen Presence-Server
3903
SIP kennt zwei Responsetypen :
 Final Response (OK),
 Provisional Response ACKnowledgement (PRACK).
3262
PRACK
Bei vorläufigen Responses, z.B. 180 Ringing, kann man wegen UDP nicht sicher sein, dass diese
Message auch den Empfänger erreicht. Mittels PRACK kann man den Empfang solcher Messages
bestätigen, wenn dies der Requestor fordert.
Diese Methode wird z.B. bei Kommunikation zwischen SIP-UA und ISDN-Gateway verwendet.
UPDATE
MESSAGE
 Anpassung der RTP-Session-Parameter in der Aufbauphase
 Nur verwendbar zwischen INVITE und dem finalen ACK.
 Ansonsten muss ein Re-INVITE verwendet werden.
Ermöglicht die Übertragung kurzer Sofort-Textmitteilungen
(Medienströme, verfügbare Codec‘s, …).
(Instant Messaging, Chatten).
3311
3428
IETF: Aufbau SIP-Response-Messages

Response-Messages:
RFC 3261
Status Line
Message Headers
vom Typ:
General, Response, Entity
SIP-version SP status-code SP status-phrase CRLF
*( header-name ":" header-value CRLF )
Leerzeile
CRLF
RFC 4566
"v=" (protocol version) CRLF
"o=" (owner/creator session_id) CRLF
"c=" *(connection information) CRLF
...
[Message Body
SDP-Protokoll ]
29
IETF: Oft genutzte SIP-Response-Codes /RFC 3261, Section 21/
Code
Phrase
Provisional 1xx
100
Trying
180
Ringing
181
Call Is Being Forwarded
182
Queued
Successful 2xx
200
Ok
202
Accepted
Redirection 3xx
300
Multiple Choices
301
Moved Permanently
302
Moved Temporarily
305
Use Proxy
380
Alternative Service
Request Failure 4xx
400
Bad Request
401
Unauthorized
402
Payment Required
403
Forbidden
404
Not Found
407
Proxy Authentication Required
486
Busy Here
Server Failure 5xx
503
Service Unavailable
505
Version Not Supported
513
Message Too Large
Global Failure 6xx
600
Busy Everywhere
604
Does Not Exist Anywhere
Description
Informative, vorläufige Antworten
Verbindungsaufbau wird versucht
Bei B klingelt es
Anruf wird weitergeleitet
Anruf befindet sich in Warteschleife, ev. mit Angabe Wartende/Wartezeit
Bestätigung erfolgreicher Requests
Request erfolgreich ausgeführt
Verbindung wurde akzeptiert
Weiterleitungsantworten
Other RFC
3265
SIP-URI permanent geändert, d.h. diese ist ungültig
SIP-URI temporär geändert, d.h. Teilnehmer ist unter anderer URI erreichbar
Verbindung zu B über Proxy herstellen
B für angeforderten Dienst nicht erreichbar, aber alternative Dienste möglich
Fehlerhafte Client-Requests
Fehlerhafter SIP-Request
Registrar-Antwort: Autorisierung fehlt
Erst blechen, dann sprechen
Server hat Anfrage verstanden, weigert sich aber, diese auszuführen
Nutzer-URI existiert in dieser Domäne nicht
Autorisierung gegenüber Proxy erforderlich
Der Angerufene kann/will den Anruf nicht entgegen nehmen
Serverfehler
Server kann derzeit Request nicht bearbeiten, wegen Überlastung/Wartung/…
Im Request verwendete SIP-Version wird nicht unterstützt
Requestverarbeitung scheiterte, da die Message zu groß war
Alle Anschlüsse besetzt
B-Teilnehmer nicht existent
Weitere Übersichten, z.B. unter: http://www.3cx.de/voip-sip/sip-responses/ verfügbar am 21.09.2014
30
IETF: SIP-Grundlagen /RFC 3261/


Caller: Anrufender, auch A-Teilnehmer genannt.
Callee: Angerufener, auch B-Teilnehmer genannt.

SIP-Transaction besteht:
– aus einem einzelnen Request,
– keinem, einem oder mehreren vorläufigen Responses,
– einem oder mehreren finalen Responses.
Arbeiten die Proxies zustandsbasiert , werden Transaktionen über eine Clt-Srv-Kette
abgewickelt.

Response
UA-B
Request
Client
Client
Response
Request
server
Client
Request
Inbound
Proxy
Response
server
Outbound
Proxy
UA-A
server

Arbeitet ein Proxie zustandslos, werden die Messages nur durchgereicht. In dem Fall
gibt es keine Server-Client-Anordnung in dem Proxy.
31
IETF: SIP-Dialog/-Transaction /RFC 3261/
Dialog
Transaktion


= ein oder mehrere Transaktionen,
= abgeschlossene Request-/Response-Folge, man unterscheidet:
– INVITE-Transaction:
• Transaction 1
– NON-INVITE-Transaction:
• Transaction 2
• Transaction 3
SIP-UA A
SIP-UA B
INVITE
– Call-ID-Wert
– Tag-Wert1) im From-Header
– Tag-Wert im To-Header

180 Ringing
200 OK
ACK
Dialog
Transaction Identifier:
Transaction 1
Transaction 2
Session
– Branch-Wert im Via-Header
UA-A-Srv
– CSequ-Wert
Bye
200 OK
UA-B-Clt
Dialog Identifier sind:
UA-A-Client

UA-B-Server
100 Trying
Transaction 3
1) Tag-Wert ist mindestens eine 32-Bit-Zufallszahl, RFC 3261, Section 19.3
32
IETF: SIP 3-Way-Handshake

/RFC 3261/
INVITE-Transaktionen werden durch ein 3Wege-Handschlag sicher gemacht, z.B.:
UA A
UA B
INVITE
– INVITE  200 OK  ACK
– INVITE  486 Busy  ACK
100 Trying
180 Ringing


200 OK
Damit vermeidet man undefinierte
Zustände.
ACK
Beispielsweise:
Session
– A rufe B an.
– In dem Moment wo B den Hörer
abnimmt, legt A auf.
– Mit ACK weiß B, A ist noch da.
– Bleibt ACK aus, kann UA-B die
Session beenden.
UA A
UA B
INVITE
486 Busy
ACK
33
IETF: SIP Timer


/RFC 3261, Table 4/
Viele Protokolle nutzen Timer, so auch SIP.
Timer A und E werden aber nur bei UDP als
Transportprotokoll verwendet.
Basis-Timer (Auswahl)
T1 500 ms Kann in privaten Netzen kleiner sein (RTT)
T2 4s
UA A
B
A
0,5
1
32
UA B
INVITE
INVITE
INVITE
2
The maximum retransmit interval for non-INVITE
requests and INVITE responses
INVITE
4
8
16
Abbruch
Anwendungs-Timer (Auswahl)
Timer A Initial T1 INVITE request retransmit interval, for UDP only
Timer B 64*T1 INVITE transaction timeout timer
Timer E Initial T1 non-INVITE request retransmit interval, UDP only
Timer F 64*T1 Non-INVITE transaction timeout timer
F
E
0,5
1
32
BYE
BYE
BYE
2
BYE
4
4
…
4
Abbruch
34
IETF: SDP – Session Description Protocol /RFC 4566/

SDP dient zur Parametrisierung von Multimediasitzungen, z.B.:

Der Transport von SDP-Messages erfolgt in der Entity einer SIP-Message.

Beispielhafte SDP-Nachricht aus RFC 2327:
– zur Aushandlung der beteiligten Medienströme (Audio, Video), der Codec's,
– Zur Angabe, an welcher Portnummern ein Medienstrom erwartet wird usw.
//session description parameters
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
[email protected] (Mark Handley)
c=IN IP4 224.2.17.12/127
//time description parameters
t=2873397496 2873404696
//media description parameters
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb ; wb=white board
a=orient:portrait
v Version des Protokolls
o Urheber (owner) der Sitzung:
• Anmeldename (z.B. auf PC) oder "-"
• Sitzungs-ID (NTP-Zeitstempel)
• Sitzungsversion (NTP-Zeitstempel)
• Internet, IP4, IP-Unicast-Adresse oder symb. Adr.
s Sitzungsname, mindestens 1 Leerzeichen
i Sitzungsbeschreibung
u URI auf Zusatzinformationen
e Mail-Adresse zu Kontaktpers., muss nicht Owner sein
c Verbindungsdaten:
• Internet
• IP4
• Uni- oder Multicastadresse, wenn Multicast: IP/TTL
t Start- und Endezeit, bei Telefonie t=0 0
…
35
IETF: SDP – Session Description Protocol
m/o Typ <Verwendung>, beispielhafte Werte
Elemente zur Sitzungsbeschreibung
m
v= version
v= 0
m
o= username sess-id sess-version nettype addrtype unicast-address
o= mhandley 2890844526 2890842807 IN IP4 126.16.64.4
m
o
o
s=
s=
i=
i=
u=
session name
SDP Seminar
session description
Bedeutung
Protokollversion
derzeit wird Version 0 verwendet
Angaben des Sitzungerzeugers (originator)
Username: mhandley |root|win|…
Session ID: 2890844526
Session Version: 2890842807
Network Type: IN
Address Type: IP4
Address: 126.16.64.4
Bezeichnung der Session
call |konferenz | besprechung | …
Session-Beschreibung
A Seminar on the session description protocol
uri
URI auf Session-Material
u= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
o
o
o
e=
e=
p=
p=
c=
c=
email-address
[email protected] (Mark Handley)
phone-number
+49-3727-581290 | +49 3727 581290
network type address type connection address
IN IP4 224.2.17.12/127
E-Mail-Adresse einer Kontaktperson
muss nicht Adresse des Originator‘s sein
Telefonnummer einer Kontaktperson
muss nicht Nummer des Originator‘s sein
Parameter der Nutzdatenadresse
Network Type: IN; Address Type: IP4
Address: 224.2.17.12 ;TTL: 127
Im Beispiel wird eine Multicastverbindung genutzt. Der TTL-Wert
gibt die Reichweite an (1=Subnetz, 15=Site, 63=Region, 127 Inet)
o = optional
m = mandatory
36
erf
Typ Verwendung, beispielhafte Werte
Elemente zur Sitzungsbeschreibung
o
b= bandwith information
b=<modifier>":"<bandwith-value>
b=AS:384
o
z= time zone adjustment
z=*(<adjustment time>SP<offset>)
z=2882844526 -1h 2898848070 0
o
k= encryption key
k=(<method> | <method>":"<encryption key>)
o
erforderliche Bitrate (in kbit/s)
"Bandbreite" der Anwendung 384 kbit/s
Verwendung: siehe RFC 1890 (RTP)
a= zero or more session description lines
a=
Elemente zur Zeitbeschreibung
m
t= time the session is active
t=<start time>SP<stop time>
t=0 0
o
Bedeutung
Verwendung siehe weiter unten
Angaben in NPT (network time
protocol. NTP-Zeitstempel sind 64
Bits lang. 32 Bits kodieren die
Sekunden seit dem 1. Januar 1900
00:00:00 Uhr, weitere 32 Bits den
Sekundenbruchteil.
bei VoIP werden beide Zeitangaben
üblicher weise auf 0 gesetzt.
r= zero or more repeat times
r=<repeat interval>SP<active duration>SP<offset list>
erf
Typ Verwendung, beispielhafte Werte
Bedeutung
Elemente zur Medienbeschreibung
m
m= media name and transport address
m=<media>SP<port>SP<transport>SP<fmt2) list>
m=audio 10032 RTP/AVP 8 0 3 18 4 9 101
o
a= zero or more media attribute lines
a=(<attribute> | <attribute>":"<value>)
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
usw.
a=ptime:20
a=inactive|sendrcv|sendonly|rcvonly
1)
2)
<media>=(audio|video|application|data|control)
Media Type: audio
Media Port: 10032
Media Protocol: RTP/AVP (audio video profile, rfc 1890)
Media Format : (8) ITU-T G.711 PCMA
Media Format : (0) ITU-T G.711 PCMU
Media Format : (3) GSM 06.10
Media Format : (18)ITU-T G.729
Media Format : (4) ITU-T G.723
Media Format : (9) ITU-T G.722
Media Format : 101
Wert in RTP-Protokollfeld "Payloadtype"
rtpmap1)-Wert 8, entspricht PCM-A-law
rtpmap-Wert 0, entspricht PCM-µ-law
rtpmap-Wert 3, entspricht GSM 06.10
usw.
Dauer der Sprachpakete in ms, entspricht bei PCM
20.000µs/125µs=160 PCM-Worte
Richtungsattribute
Werte siehe Tabellen 4/5 in RFC 3551 "RTP Profile for Audio and Video Conferences with Minimal Control „
fmt - format
IETF: Offer/Answer Model with the SDP /RFC 3264/


A-Teilnehmer alice offeriert dem B-Tln.
bob ein Sitzungsangebot.
Auf das Initial Offer(1) wird mit Answer(1)
geantwortet.
[email protected]
[email protected]
Initial Offer(1)
Answer(1)
Offer(2)




Danach kann mit Offer(2) die Session
angepasst werden.
Nach Answer(2) wird die Session
errichtet.
Eine Sessionanpassung kann auch vom
B-Tln. initiiert werden.
Anmerkung: in der Rufaufbauphase kann mit
UPDATE eine Offerte korrigiert werden kann, sofern
noch keine Answer vom B-Teilnehmer kam.
Answer(2)
Session(2)
Offer(3)
Answer(3)
Session(3)
39
IETF: Offer/Answer Beispiel /RFC 3264/
Offer from caller Alice:
It includes
 a bidirectional audio stream
 and two bidirectional video
streams
• using H.261 (payload type 31)
• and MPEG (payload type 32).
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
;Medienname, Portnummer
a=rtpmap:0 PCMU/8000
;Medienattribut
m=video 51372 RTP/AVP 31 ;Medienname, Portnummer
a=rtpmap:31 H261/90000
;Medienattribut
m=video 53000 RTP/AVP 32 ;Medienname, Portnummer
a=rtpmap:32 MPV/90000
;Medienattribut
The callee, Bob, does not want to
receive or send the first video
stream, so he returns the SDP below
as the answer
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
a=rtpmap:32 MPV/90000
40
IETF: Offer/Answer Beispiel /RFC 3264/
The initial offer from Alice to Bob indicates a
single audio stream with the three audio
codecs that are available in the DSP (Digital
Signal Processing). The stream is marked as
inactive, since media cannot be received
until a codec is locked down:
Bob can support dynamic switching between
PCMU and G.723. So, he sends the following
answer:
Alice can then select any one of these two
codecs. So, she sends an updated offer with
a sendrecv stream:
Bob accepts the single codec:
v=0
s=
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
v=0
s=
t=0 0
m=audio 54344 RTP/AVP 0 4
a=inactive
v=0
s=
t=0 0
a=sendrecv
v=0
s=
t=0 0
a=sendrecv
41
IETF: SIP-Szenario

SIP-Netzwerk-Elemente sind:
–
–
–
–
–
SIP-Terminals mit SIP-User-Agent,
SIP-Proxy- und SIP-Redirect-Server
SIP-Registrar- und SIP-Location-Server
SIP-Gateway
SIP-Confence-Server
SIPTerminal
SIPTerminal
SIP-Switch: Zusammenfassung von: Proxy,
Redirect, Registrar, Presence, Gateway, …
2
5
7
P
SIPTerminaladapter
8
0
2
5
P
7
8
0
Scope
of IETF
Packet switched network
SIP-Registrar, SIP-Location,
SIP-Presence,
SIP-Proxy, SIP-Redirect
Switched
Telephone
Network
SIPGateway
…
SIPConfernce
Narrow
ISDN
Funknetze
42
IETF: SIP User Agent (UA)

Aufgaben:
– An-/Abmelden beim Registrar,
– Aufbau/Abbau gehender Verbindungen,
– Annahme/Abbau kommender Verbindungen,

Der UA besteht funktionell aus:
– dem UAC (User Agent Client), zum Aufbau gehender Verbindungen,
– dem UAS (User Agent Server), zur Annahme/Weiterleitung/Abweisung kommender
Verbindungen.

Verbindungen (Sessions) zu anderen Endgeräten können erfolgen:
– direkt
– über SIP-Proxies.
SIP-Proxy
SIP-Endgerät A
UAC
UAS
SIP-Endgerät B
UAS
UAC
UAC
UAS
Session über Proxy
Direkte Session
43
IETF: SIP-Proxy-Server

SIP-Proxy ist ein Server/Client der als "Call Control" innerhalb einer Domäne
arbeitet.

Er routet SIP-Signalgabe und nutzt dazu eine "Location Service DB":
– Entgegennahme/Weiterleitung von SIP-Nachrichten an SIP-Proxies oder SIP-Terminals.
– Die Nachrichten können gelesen, interpretiert und ggf. geändert werden.
– Er ist Server, beim Entgegennehmen und Client beim Weiterleiten von SIP-Messages.

Er kann entscheiden, was Teilnehmer dürfen
Supplementary Services).

Der SIP-Proxy kann
(bei kommenden und gehenden Calls, bzw. bei
– Stateless sein, d.h. er ist ein zustandsloser Transporteur von SIP-Messages.
– Stateful sein:
• Call-statefull, der gesamten Call wird auf eine Zustandsmaschine abgebildet (wie klassische Call
Control)
• Transaction-stateful, Zustand existiert nur für eine Signalgabetransaktion (Request-ResponseAktion).
44
IETF: SIP-Registrar/Location/-Server

SIP-Registrar dient zur Registrierung der Teilnehmer einer Domäne:
– Er nimmt REGISTER-Messages von SIP-Terminals an (angemeldet, abgemeldet).
– Trägt die aktuelle IP-Adressen in "Location DB" ein:
unter welcher IP-Adresse ist derzeit sip:[email protected] erreichbar.
– Er kann die Anmeldung von einem Account (<name>, <passwd>) abhängig machen.

SIP-Location-Server:
– stellt SIP-Proxies oder SIP-Redirect-Servers die momentane IP-Adresse eines
gewünschten Teilnehmers aus der "Location DB" zur Verfügung.
– „Location DB“ ist das Home-Location-Register einer VoIP-Domäne.

Die "Location DB" wird durch den SIP-Registrar aktuell gehalten.
Dazu wird z.B. das LDAP (lightweight directory access protocol) genutzt.
45
IETF: SIP-Redirect/-Gateway/-Conference

SIP-Redirect ist ein Server:
– der auf einen Request eine 3xx-Antwort mit der aktuellen B-Adresse zurückgibt, weil ein
Teilnehmer z.B. zeitlich an verschiedenen Locations erreichbar ist.
– Dazu greift der Redirektion-Server auf die "Location Service DB" zu.
– Der A-Tln. stellt die Session zu B direkt oder über den Proxy her, wo sich der Teilnehmer
z.Zt. befindet.

SIP-Gateway:
– Wandelt die Signalgabe von SIP in z.B. Q.931 und umgekehrt.
– Codiert VoIP-codierte Sprache z.B. in PCM und umgekehrt.

SIP-Conference:
– Knotenpunkt für Signalgabe und deren Verteilung an alle KonferenzteilnehmerFOCUS.
– Knotenpunkt für Nutzdaten und deren Verteilung an alle KonferenzteilnehmerMIXER.

Soft-Switch, VoIP-Switch (bekannte FreeWare: Asterisk,*):
– Basiert auf einem Rechner und vereinigt alle Komponenten.
– Als Übergang z.B. zum Fernsprechnetz wird eine ISDN-Karte verwendet.
46
IETF: SIP-Funktionalitäten und Relationen
1
1
Registrar
2
Location Service
2
1
2
2
3
zum entfernten BTeilnehmer
Proxy
3
Redirect Server



(1) Anmelden mittels Registrar : aktuelle IP-Adresse  in Location Service DB
(2) Verbindung über Proxy:  IP vom Location Service
(3) Vom Redirect-Server: Teilnehmer unter folgender IP derzeit erreichbar.
47
IETF: SIP-/SDP-Signalgabe-Beispiele

Die nachfolgenden Signalgabe-Beispiele sind aus:
– RFC 3261, " SIP: Session Initiation Protocol"
– RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Example",
Category: Best Current Practice (Beste derzeitige Vorgehensweise)
– RFC 5359, "Session Initiation Protocol Service Examples"
Category: Best Current Practice

In den RFC-3665-Beispielen werden folgende Elemente, Namen, permanent URI's,
IP-Adressen verwendet:
Element
Display Name
-----------------User Agent
Alice
User Agent
Bob
User Agent
Proxy Server
Proxy/Registrar
Proxy Server
permanent URI
[email protected]
[email protected]
[email protected]
ss1.atlanta.example.com
ss2.biloxi.example.com
ss3.chicago.example.com
IP Address
---------192.0.2.101
192.0.2.201
192.0.2.100
192.0.2.111
192.0.2.222
192.0.2.233
48
IETF: SIP registration example /RFC 3261, nach Fig. 9/


F1
Bob‘s Phone meldet sich beim Registrar
(hier z.B. ohne Autorisierung) an.
Anmeldung wird i.d.R. zyklisch wiederholt.
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
F2
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
branch=z9hG4bKnashds7; received=192.0.2.201
To: Bob <sip:[email protected]>;tag=2493k59kd
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Expires: 7200
Content-Length: 0
bob’s
reg.biloxi.com
ldap.biloxi.com
phone
registrar
|
|
|
|
| REGISTER F1
|
|
|---------------->|
|
|
| [email protected] |
|
|---------------->|
|
200 OK F2
|
192.0.2.201
|
|<----------------|
|
|
|
|
Methode, Adresse des Registrars, SIP-Version
Via: dient zur Adressierung der Route von SIP-Messages;
branch (zweig) = FixString "z9hG4bK" und Zufallsstring der Einmaligkeit garantiert.
SIP-Proxies dekrementieren diesen Wert. Bei Null, wird die SIP-Message verworfen .
Permanente SIP-Teilnehmer-URI. Zu erzeugender Adresseintrag in der Location-Datenbank.
Urheber des Eintrages in die Location-Datenbank. ; tag ist Zufallszahl (mind. 32 Bit).
Weltweit einmaliger Call-Id, soll te Zeit-, Raum- und Zufallskomponenten enthalten.
Sequenznummer und Methode, referenziert Request und Response
Temporäre IP von Bob‘s Telefon.
In der Location-Datenbank sind dann zugeordnet sip:[email protected]=192.0.2.201
Gültigkeitsdauer der Registrierung. Nach Ablauf wird Eintrag aus der Location-DB gestrichen.
Länge des Message body (SDP-Nachrichtenlänge)
Methode, Adresse des Registrars, SIP-Version
Via: dient zur Adressierung der Route von SIP-Messages;
Permanente SIP-Adresse.
identifiziert zwingend den Urheber der Message; tag ist Zufallszahl (mind. 32 Bit).
weltweit einmaliger Call-Id, soll Zeit-, Raum- und Zufallskomponenten enthalten
Sequenznummer und Methode, referenziert Request und Response
Momentane Bindung URI-IP-Adresse: sip:[email protected]=192.0.2.201
Gültigkeitsdauer der Registrierung. Nach Ablauf wird Eintrag aus der Location-DB gestrichen.
Länge des Message body (SDP-Nachrichtenlänge)
49
IETF: Registration /RFC 3665/
Bob
SIP Server
|
|
|
REGISTER F1
|
|------------------------------>|
|
401 Unauthorized F2
|
|<------------------------------|
|
REGISTER F3
|
|------------------------------>|
|
200 OK F4
|
|<------------------------------|
|
|
F1 REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:[email protected]>;tag=a73kszlfl
To: Bob <sips:[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sips:[email protected]>
Content-Length: 0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
Max-Forwards: 70
From: Bob <sips:[email protected]>;tag=ja743ks76zlflH
CSeq: 2 REGISTER
Authorization: Digest username="bob", realm="atlanta.example.com"
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
uri="sips:ss2.biloxi.example.com",
response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
F4 SIP/2.0 200 OK Via: SIP/2.0/TLS
client.biloxi.example.com:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
From: Bob <sips:[email protected]>;tag=ja743ks76zlflH
To: Bob <sips:[email protected]>;tag=37GkEhwl6
CSeq: 2 REGISTER
Contact: <sips:[email protected]>;expires=3600
Content-Length: 0
F2 SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds7;received=192.0.2.201
To: Bob <sips:[email protected]>;tag=1410948204
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com",
qop="auth",nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", algorithm=MD5
Content-Length: 0
50
IETF: Digest Authentication /RFC 1321/
Digest Extrakt
Authentication : ich bin X, erbracht durch
Nachweis eines geheimen Wissen
MD5 is a message digest algorithm that takes as input a
message of arbitrary length and produces as output a 128bit "fingerprint" or "message digest" of the input.
SIP/2.0 401 Unauthorized
REGISTER sips:ss2.biloxi.example.com SIP/2.0
WWW-Authenticate: Digest
Authorization: Digest
realm="atlanta.example.com",
Name des geschützten
Bereichs (realm)
qop="auth",
"quality of protection“:
Authentication
nonce="ea9c8e88df84f1cec4341ae6cbe
5a359",
Zufallswert im Hexformat
opaque="",
Weiterer Zufallswert
algorithm=MD5
Verwende Hashfunktion
"MD5“
username="bob",
Benutzername
Name des geschützten
Bereichs
nonce="ea9c8e88df84f1cec4341ae6cb
e5a359",
Zufallswert im Hexformat
opaque="",
URI(s), für den(die)
Authorisierung gelten soll
response="dfe56131d1958046689d833
06477ecc"
MD5-Digest aus:
Benutzername
+nonce
+Passwort
Auf Serverseite: anhand des Benutzernamens wird das Passwort aus Datenbasis gelesen und ebenfalls
der Fingerprint aus Benutzername+nonce+Passwort gebildet.
Authorisierung erfolgt bei Übereinstimmung mit response-Wert.
51
IETF: Cancellation of Registration /RFC 3665/
Bob
SIP Server
|
|
|
REGISTER F1
|
|------------------------------>|
|
|
|
200 OK F4
|
|<------------------------------|
|
|
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
CSeq: 1 REGISTER
Expires: 0
Contact: *
Authorization: Digest
username="bob", realm="atlanta.example.com",
nonce="88df84f1cac4341aea9c8ee6cbe5a359", opaque="",
response="ff0437c51696f9a76244f0cf1dbabbea"
Content-Length: 0
Das Abmelden geschieht über den SIP-Header
Expires: 0.
F4 SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
To: Bob <sips:[email protected]>;tag=1418nmdsrf
CSeq: 1 REGISTER
Content-Length: 0
52
IETF: Successful Session Establishment /RFC 3665/
Alice
Bob
|
|
|
INVITE F1
|
|----------------------->|
|
180 Ringing F2
|
|<-----------------------|
|
|
|
200 OK F3
|
|<-----------------------|
|
ACK F4
|
|----------------------->|
|
Both Way RTP Media
|
|<======================>|
|
|
|
BYE F5
|
|<-----------------------| nicht dar|
200 OK F6
|
|----------------------->| gestellt
|
|
F1 INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:[email protected]>;tag=9fxced76sl
To: Bob <sip:[email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=c=IN IP4 192.0.2.101
t=0 0
Schwarz/fett
Violett/fett
 Dialog-ID
Transaction ID
F1 bis F3
F4
F2 SIP/2.0 180 Ringing
;received=192.0.2.101
To: Bob <sip:[email protected]>;tag=8321234356
CSeq: 1 INVITE
Content-Length: 0
F3 SIP/2.0 200 OK
;received=192.0.2.101
CSeq: 1 INVITE
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=c=IN IP4 192.0.2.201
t=0 0
F4 ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
CSeq: 1 ACK
Content-Length: 0
Beschreibung der Konzepte: siehe Folie
INVITE-Transaction
Non-INVITE-Transaction
53
IETF: Session Establishment Through Two Proxies /RFC 3665/
Alice
Proxy 1
Proxy 2
Bob
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
|
|
|
407 F2
|
|
|
|<---------------|
|
|
|
ACK F3
|
|
|
|--------------->|
|
|
|
INVITE F4
|
|
|
|--------------->|
INVITE F5
|
|
|
100 F6
|--------------->|
INVITE F7
|
|<---------------|
100 F8
|--------------->|
|
|<---------------|
|
|
|
|
180 F9
|
|
|
180 F10
|<---------------|
|
180 F11
|<---------------|
|
|<---------------|
|
200 F12
|
|
|
200 F13
|<---------------|
|
200 F14
|<---------------|
|
|<---------------|
|
|
|
ACK F15
|
|
|
|--------------->|
ACK F16
|
|
|
|--------------->|
ACK F17
|
|
|
|--------------->|
|
Both Way RTP Media
|
|<================================================>|
|
|
|
BYE F18
|
|
|
BYE F19
|<---------------|
|
BYE F20
|<---------------|
|
|<---------------|
|
|
|
200 F21
|
|
|
|--------------->|
200 F22
|
|
|
|--------------->|
200 F23
|
|
|
|--------------->|
|
|
|
|
In this scenario, Alice completes a call to
Bob using two proxies Proxy 1 and Proxy 2.
The initial INVITE (F1) contains a preloaded Route header with the address of
Proxy 1 (Proxy 1 is configured as a default
outbound proxy for Alice). The request
does not contain the Authorization
credentials Proxy 1 requires, so a 407 Proxy
Authorization response is sent containing
the challenge information.
A new INVITE (F4) is then sent containing
the correct credentials and the call
proceeds. The call terminates when Bob
disconnects by initiating a BYE message.
Der Signalgabepfad wird durch
Via-Header adressiert. siehe
SID-/SDP-Dump auf den
nächsten zwei Folien.
54
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
Max-Forwards: 70
CSeq: 1 INVITE
Content-Length: 151
v=0
s=c=IN IP4 192.0.2.101
t=0 0
Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.101
Max-Forwards: 69
CSeq: 2 INVITE
Content-Length: 151
v=0
s=c=IN IP4 192.0.2.101
t=0 0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
Max-Forwards: 70
CSeq: 2 INVITE
Proxy-Authorization: Digest username="alice",
nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="",
uri="sip:[email protected]",
response="42ce3cef44b22f50c6a6071bc8"
Content-Length: 151
v=0
s=c=IN IP4 192.0.2.101
t=0 0
Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
;received=192.0.2.111
;received=192.0.2.101
Max-Forwards: 68
CSeq: 2 INVITE
Content-Length: 151
v=0
s=c=IN IP4 192.0.2.101
t=0 0
55
F12 SIP/2.0 200 OK
;received=192.0.2.222
;received=192.0.2.111
;received=192.0.2.101
CSeq: 2 INVITE
Content-Length: 147
v=0
s=c=IN IP4 192.0.2.201
t=0 0
F14 SIP/2.0 200 OK
;received=192.0.2.101
CSeq: 2 INVITE
Content-Length: 147
v=0
s=c=IN IP4 192.0.2.201
t=0 0
F13 SIP/2.0 200 OK
;received=192.0.2.111
;received=192.0.2.101
CSeq: 2 INVITE
Content-Length: 147
v=0
s=c=IN IP4 192.0.2.201
t=0 0
56
IETF: Session via Redirect and Proxy Servers
Alice
Redirect Server
Proxy 3
Bob
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
|
|
|
302 F2
|
|
|
|<---------------|
|
|
|
ACK F3
|
|
|
|--------------->|
|
|
|
INVITE F4
|
|
|-------------------------------->|
INVITE F5
|
|
100 F6
|--------------->|
|<--------------------------------|
180 F7
|
|
180 F8
|<---------------|
|<--------------------------------|
|
|
|
200 F9
|
|
200 F10
|<---------------|
|<--------------------------------|
|
|
ACK F11
|
|
|-------------------------------->|
ACK F12
|
|
|--------------->|
|
Both Way RTP Media
|
|<================================================>|
|
|
BYE F13
|
|
BYE F14
|<---------------|
|<--------------------------------|
|
|
200 F15
|
|
|-------------------------------->|
200 F16
|
|
|--------------->|
|
|
|
with SDP in ACK
/RFC 3665/
In this scenario, Alice places a call to Bob
using first a Redirect server then a Proxy
Server.
The INVITE message is first sent to the
Redirect Server. The Server returns a 302
Moved Temporarily response (F2)
containing a Contact header with Bob's
current SIP address.
Alice then generates a new INVITE and
sends to Bob via the Proxy Server and the
call proceeds normally.
In this example, no SDP is present in the
INVITE, so the SDP is carried in the ACK
message.
The call is terminated when Bob sends a
BYE message.
57
IETF: Session via Redirect and Proxy Servers
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
Max-Forwards: 70
CSeq: 1 INVITE
Content-Length: 0
F2 SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
;received=192.0.2.101
To: Bob <sip:[email protected]>;tag=53fHlqlQ2
CSeq: 1 INVITE
Content-Length: 0
Max-Forwards: 70
CSeq: 2 INVITE
Content-Length: 0
with SDP in ACK
F9 SIP/2.0 200 OK
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
;received=192.0.2.233 Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
CSeq: 2 INVITE
Content-Length: 148
v=0
o=bob 2890844527 2890844527 IN IP4 client.chicago.example.com
s=c=IN IP4 192.0.2.100
t=0 0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
Max-Forwards: 70
Route: <sip:ss3.chicago.example.com;lr>
CSeq: 2 ACK
Content-Length: 151
v=0
s=c=IN IP4 192.0.2.101
t=0 0
58
IETF: Unsuccessful Busy /RFC 3665/
Alice
Proxy 1
Proxy 2
Bob
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
INVITE F2
|
|
|
100 F3
|--------------->|
INVITE F4
|
|<---------------|
100 F5
|--------------->|
|
|<---------------|
|
|
|
|
486 F6
|
|
|
|<---------------|
|
|
|
ACK F7
|
|
|
486 F8
|--------------->|
|
|<---------------|
|
|
|
ACK F9
|
|
|
486 F10
|--------------->|
|
|<---------------|
|
|
|
ACK F11
|
|
|
|--------------->|
|
|
|
|
|
|
In this scenario, Bob is busy and
sends a 486 Busy Here response to
Alice's INVITE.
Note that the non-2xx response is
acknowledged on a hop-by-hop
basis instead of end-to-end.
Also note that many SIP UAs will
not return a 486 response, as they
have multiple line and other
features.
59
IETF: Unsuccessful Busy /RFC 3665/
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
CSeq: 1 INVITE
nonce="dc3a5ab2530aa93112cf5904ba7d88fa", opaque="",
response="702138b27d869ac8741e10ec643d55be"
Content-Length: 151
v=0
s=c=IN IP4 192.0.2.101
t=0 0
F6 SIP/2.0 486 Busy Here
;received=192.0.2.222
;received=192.0.2.111
;received=192.0.2.101
CSeq: 1 INVITE
F3 SIP/2.0 100 Trying
;received=192.0.2.101
CSeq: 1 INVITE
Content-Length: 0
Max-Forwards: 70
CSeq: 1 ACK
nonce="dc3a5ab2530aa93112cf5904ba7d88fa", opaque="",
response="702138b27d869ac8741e10ec643d55be"
Content-Length: 0
60
IETF: Consultation Hold /5359/
Alice
Proxy
Bob
Carol
|
|
|
|
|
|
|
|
|
Both way RTP Established |
|
|<=============================>|
|
|
|INVITE(hold) F10
|
|INVITE(hold) F11|<-------------|
|
|<---------------|
|
|
|
200 OK F12 |
|
|
|--------------->|
200 OK F13 |
|
|
|------------->|
|
|
|
ACK F14 |
|
|
|<-------------|
|
|
ACK F15
|
|
|
|<---------------|
|
|
|
No RTP Sent!
|
|
|
|
INVITE F16 |
|
|
|<-------------|
|
|
|
|
INVITE F17
|
|
|--------------------------------->|
|
|(100 Trying) F18
|
|
|------------->|
|
|
|
| 180 Ringing F19
|
|
|<---------------------------------|
|
| 180 Ringing F20
|
|
|------------->|
|
|
|
|
200 OK F21
|
|
|<---------------------------------|
|
|
200 OK F22 |
|
|
|------------->|
|
|
|
ACK F23
|
|
|
|<-------------|
|
|
|
|
ACK F24
|
|
|--------------------------------->|
|
|
|
|
|<=================>|
|
|
BYE F25
|
|
|
|<-------------|
|
|
|
|
BYE F26
|
|
|--------------------------------->|
|
|
|
200 OK F27
|
|
|<---------------------------------|
|
|
200 OK F28 |
|
|
|------------->|
|
|
|
INVITE F29 |
|
|
INVITE F30 |<-------------|
|
|<---------------|
|
|
|
200 OK F31 |
|
|
|--------------->|
200 OK F32 |
|
|
|------------->|
|
|
|
ACK F33 |
|
|
|<-------------|
|
|
ACK F34
|
|
|
|<---------------|
|
|
|
|
|<=============================>|
|
F1 bis F9 und F35 bis F38 nicht dargestellt.
In this scenario, Alice calls Bob.
Bob places call on hold.
Bob calls Carol.
Bob then disconnects with Carol, then
takes the call with Alice off hold.
61
IETF: Consultation Hold /5359/
F10 INVITE sips:[email protected] SIP/2.0
Max-Forwards: 70
From: Bob <sips:[email protected]>;tag=314159
To: Alice <sips:[email protected]>;tag=1234567
CSeq: 1 INVITE
Content-Length: ...
v=0
s=
c=IN IP4 client.biloxi.example.com t=0 0
a=sendonly
F29 INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7b
Max-Forwards: 70
From: Bob sips:[email protected]>;tag=314159
CSeq: 2 INVITE
Content-Length: ...
v=0
s=
c=IN IP4 client.biloxi.example.com
t=0 0
F12 SIP/2.0 200 OK
Via: SIP/2.0/TLS ss1.example.com:5061 ;branch=z9hG4bK837497.1
;received=192.0.2.54
;received=192.0.2.105
CSeq: 1 INVITE
Content-Length: ...
v=0
s=
c=IN IP4 client.atlanta.example.com
t=0 0
a=recvonly
F31 SIP/2.0 200 OK
Via: SIP/2.0/TLS ss1.example.com:5061 ;branch=z9hG4bK837497.1
;received=192.0.2.54
;received=192.0.2.105
CSeq: 2 INVITE
Content-Length: ...
v=0
s=
c=IN IP4 client.atlanta.example.com
t=0 0
62
IETF: Call Pickup /RFC 5359/
Alice
Bob
Bill
|
|
|
|
INVITE F1 |
|
|------------->|
|
|180 Ringing F2|
|
|<-------------|
|
|
|
SUBSCRIBE F3
|
|
|<------------------|
|
|
200 OK F4
|
|
|------------------>|
|
|
NOTIFY F5
|
|
|------------------>|
|
|
200 OK F6
|
|
|<------------------|
|
INVITE Replaces:Bob F7 |
|<---------------------------------|
|
|
200 OK F8
|
|--------------------------------->|
|
CANCEL F9 |
|
|------------->|
|
| 200 OK F10 |
|
|<-------------|
|
|
487 F11
|
|
|<-------------|
|
|
ACK F12
|
|
|------------->|
|
|
ACK F13
|
|<---------------------------------|
|
|
|
Two-Way RTP Established
|
|<================================>|
|
BYE F14
|
|--------------------------------->|
|
200 OK F15
|
|<---------------------------------|
|
|
Bob und Bill sind Teil einer Arbeitsgruppe.
Jedes Mitglied kann einen Call zu sich
heranholen.
Alice ruft Bob an, der antwortet nicht.
Bill will den Call übernehmen und sendet
ein SUBSCRIBE zu Bobs Telefon, damit
dieses die Call-Dialog-Informationen mit
NOTIFY übersendet.
Die Call-Dialog-Informationen werden im
XML-Format übergeben.
Bill generiert dann ein INVITE mit einem
Replaces zu Alice.
63
IETF: Call Pickup /RFC 5359/
F3 SUBSCRIBE sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS pc.biloxi.example.com:5061 ;branch=z9hG4bK74bf
Max-Forwards: 70
From: Bill <sips:[email protected]>;tag=8675309
CSeq: 1 SUBSCRIBE
Event: dialog
Expires: 0
Accept: application/dialog-info+xml
Content-Length: 0
F7 INVITE sips:[email protected];gr SIP/2.0
Via: SIP/2.0/TLS pc.biloxi.example.com:5061 ;branch=z9hG4bK74HH
Max-Forwards: 70
From: Bill <sips:[email protected]>;tag=8675310
To: Alice <sips:[email protected]>
CSeq: 1 INVITE
Require: replaces
Replaces: [email protected] ;from-tag=314578;totag=1234567;early-only
F5 NOTIFY sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bK74br
Max-Forwards: 70
To: Bill <sips:[email protected]>;tag=8675309
CSeq: 1 NOTIFY
Event: dialog
Subscription-State: terminated;reason=timeout
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sips:[email protected]">
<dialog id="94992014524" call-id="[email protected]"
local- tag="3145678" remote-tag="1234567" direction="recipient">
<duration>1</duration>
<local>
<identity display="Bob">sips:[email protected]</identity>
<target>sips:[email protected]</target>
</local>
<remote>
<identity display="Alice">sips:[email protected] </identity>
<target>sips:[email protected];gr</target>
</remote>
<state>early</state>
</dialog>
</dialog-info>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: ...
v=0 o=bill 2890843122 2890843122 IN IP4 pc.biloxi.example.com
s=
c=IN IP4 pc.biloxi.example.com
t=0 0
/* Alice matches the dialog information in the Replaces header and
accepts the INVITE. */
F8 SIP/2.0 200 OK
…
/* Alice stops Bob's phone from ringing by sending a CANCEL. */
F9 CANCEL sips:[email protected] SIP/2.0
…
64
IETF: Rufumleitung
Alice
Proxy.b.de
Proxy.c.de
Bob
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
|
|
|
302 F2
|
|
|
|<---------------|
|
|
|
ACK F3
|
|
|
|--------------->|
|
|
|
INVITE F4
|
|
|-------------------------------->|
INVITE F5
|
|
100 F6
|--------------->|
|<--------------------------------|
180 F7
|
|
180 F8
|<---------------|
|<--------------------------------|
|
|
|
200 F9
|
|
200 F10
|<---------------|
|<--------------------------------|
|
|
ACK F11
|
|
|-------------------------------->|
ACK F12
|
|
|--------------->|
|
Both Way RTP Media
|
|<================================================>|
|
|
BYE F13
|
|
BYE F14
|<---------------|
|<--------------------------------|
|
|
200 F15
|
|
|-------------------------------->|
200 F16
|
|
|--------------->|
|
|
|
Bob, ursprünglich in b.de, ist temporär
erreichbar in der Domäne c.de.
F1 INVITE von Alice wird beantwortet mit:
F2 302 Moved temporarly
Contact: [email protected]
Das nächste INVITE geht dann zur Domäne
c.de:
65
IETF: Call Forking
Alice
Proxy.b.de
Bob.b.de
Alf.b.de
|
|
|
|
| INVITE [email protected]
|
|
|--------------->|
|
|
|
| INVITE [email protected]|
|
|
|--------------->|
|
|
| INVITE [email protected]|
|
|
|-------------------------------->|
|
|
| 200 OK
|
|
200 OK
|<--------------------------------|
|<---------------| CANCEL [email protected]|
|
|
|--------------->|
|
|
| 200 OK
|
|
|
|<---------------|
|
|
| 487 Transaction Canceled
|
|
|<---------------|
|
|
|
ACK
|
|
|
|--------------->|
|
|
ACK
|
|
|
|------------------------------------------------->|
|
|
|
|
Both Way RTP Media
|
|<================================================>|
|
|
|
Fork = Gabel
Call Forking =
Rufverzweigung|Rufgabelung|Parallelruf
Bob und Alf sind hier z.B. Mitglieder einer
Servicegruppe.
Kommt ein Service-Call, werden Bob und
Alf gerufen.
Alf nimmt den Call an.
Das INVITE zu Bob wird mit CANCEL
aufgehoben und das Transaktionsende mit
487 angezeigt.
66
Das Real Time Transport Protocol – RTP /RFC 3550/


RTP wurde für die Übertragung von Echtzeitdaten (Voice, Video) entwickelt.
Folgende Hauptmerkmale hat das Protokoll:
–
–
–
–
–
–

es unterstützt Unicast- und Multicast-Kommunikation,
keine Flußsteuerung und Fehlerkontrolle
benutzt UDP (User Datagram Protocol)
kann aber auch direkt auf unter UDP liegende Protokolle aufsetzen
RTP wird durch RTCP (RTP Control Protocol) überwacht
RTCP gestattet insbesondere Empfängern, an den Sender QOS-Parameter zu senden.
Dies gestattet dem Sender, z.B. Kodierung und Kompression an die Netzbedingungen
anzupassen.
Die Echtzeitdatenübertragung im Internet hat zwei Feinde:
– die Unterschreitung einer Mindestübertragungsrate
– die Überschreitung der zulässigen Verzögerungszeit von Paketen

Bei VoIP sollte eine Verzögerungszeit von 250 ms nicht überschritten werden.
67
RTP: Byte Order, Alignment, Time Format /RFC 3550/

RTP-Funktionen im Überblick sind:
– Anzeige des Payloadtypes, d.h. es wird der Nutzlasttyp angegeben (siehe Folie):
• 8 pcma/8000
• 0 pcmu/8000
• 3 gsm/8000 usw.
– Sequenznumerierung, Anfangswert ist Zufallswert, wird in jedem Paket um 1 erhöht,
– Zeitstempel (Absolute Zeit: diese kann mit dem Network Time Protocol (NTP) ermittelt werden) .

Der Header hat folgenden Aufbau:
0
7
V
P X
CC
8
M
15 16
Payload Type
23
24
31
Sequence number
Timestamp
Synchronisation source (SSRC) identifier
Contribution source (CSRC) identifiers (Liste mit 0 oder bis max. 16 Einträgen)
Sprach-, Videodaten
68
RTP: RTP Fixed Header Fields /RFC 3550/
Feld
Version
Padding
Bits
2
1
eXtension
CSRC count (CC)
1
4
Marker
1
Payload type
7
Sequence number
16
Timestamp
32
Synchronisation
source (SSRC)
identifier
32
Contribution
source (CSRC)
identifiers
Bedeutung
Versionsnummer, derzeit 2
Wenn dieses Bit gesetzt ist, enthalt das Paket am Ende Füllbytes. Die genaue Anzahl steht im
letzten Byte des Paketes.
Falls das Bit gesetzt ist, folgt dem Header ein Erweiterungsheader
Zähler, der die Anzahl der CSRC-Kennungen angibt, die dem fixen Header folgen
Die Benutzung dieses Bits wird durch die Profile geregelt. M zeigt beispielsweise das letzte Paket
an. /RFC 1890/, Abschnitt 4.1
Dieses Feld verweist auf die Art der Nutzlast. Ein Profil spezifiziert die Nutzlasttypen und deren
Eigenschaften. /RFC 1890/, Tabelle 2
Die Sequenznummer erhöht sich für jedes gesendete Paket um 1. Aus dieser Nummer kann man
verlorene Pakete ermitteln. Der Anfangswert wird zufällig ermittelt, damit der Anfangswert etwas
verschleiert wird.
Abtastzeitpunkt der ersten Probe, die dann codiert im Paket gesendet wird. Die Auflösung der Uhr
muß der Anwendung angemessen sein, damit z.B. die Synchronisation hinreichend genau ist und
Jitter gemessen werden können.
Innerhalb einer RTP-Sitzung eindeutige Kennung der Synchronisationsquelle. Wird auch zufällig
ermittelt
0..15 Beitragende Quellen. Durch Mixer erzeugte Liste, aller beteiligter Synchronisationsquellen. Die
Liste enthält aber nur die Quellen, deren Proben in dem aktuellen RTP-Frame mitgeschickt werden.
Die Empfänger können so z. B. in einer Audiokonferenz den aktuellen Sprecher ermitteln.
IETF: RTP – Payload types Audio/Video
PT
encoding
media
clock rate
channels
name
type
(Hz)
______________________________________________
0
PCMU
A
8,000
1
3
GSM
A
8,000
1
4
G723
A
8,000
1
5
DVI4
A
8,000
1
6
DVI4
A
16,000
1
7
LPC
A
8,000
1
8
PCMA
A
8,000
1
9
G722
A
8,000
1
10
L16
A
44,100
2
11
L16
A
44,100
1
12
QCELP
A
8,000
1
13
CN
A
8,000
1
15
G728
A
8,000
1
16
DVI4
A
11,025
1
17
DVI4
A
22,050
1
18
G729
A
8,000
1
PT
encoding
media type clock rate
name
(Hz)
_____________________________________________
25
CelB
V
90,000
26
JPEG
V
90,000
28
nv
V
90,000
31
H261
V
90,000
32
MPV
V
90,000
33
MP2T
AV
90,000
34
H263
V
90,000
dyn
H263-1998
V
90,000
Table 5: Payload types (PT) for video and
combined encodings
Table 4: Payload types (PT) for audio encodings
RTP-Paket
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00a0
00b0
00c0
00d0
00
00
f1
99
d5
d5
57
5d
40
5a
58
45
5a
5a
04
c8
dd
5f
57
54
57
53
5a
5b
5b
58
5b
47
13
bd
13
dd
54
54
55
51
50
58
5a
5b
44
44
22
04
8c
96
d1
d7
d1
57
57
5c
59
45
47
5a
3f
00
27
8c
d0
d3
d2
d7
56
53
53
46
45
58
cc
00
30
24
d7
d1
d0
d3
51
51
56
5b
5f
59
00
fa
00
55
d5
55
d1
d0
57
56
56
54
53
0b
11
b4
55
d4
56
d6
d5
d5
56
54
d1
56
82
04
33
55
54
55
d4
54
d4
54
55
55
54
03
f7
fb
54
50
d5
54
54
54
d5
d5
50
55
90
8d
80
57
56
56
51
57
52
55
54
51
55
d6
37
08
54
54
5d
52
53
5e
51
51
55
57
08
f1
3a
54
56
5f
5e
5f
59
5c
5d
54
56
00
dc
b1
57
51
5c
58
58
58
58
58
5c
56
45
8d
e9
54
56
53
59
58
45
5a
46
5a
50
00
37
37
d5
55
56
5f
47
45
5b
41
44
5f
MAC-Header
IP-Header
UDP-Header
RTP-Header
Payload
MAC-Header: sourceMAC:00-04-13-22-37-cc, destMAC:00-0b-82-03-90-d6, Nutzlast:IP(8000)
IP-Header: sourceIP:141.55.241.220(8d 37 f1 dc),destIP: 141.55.241.221(8d 37 f1 dd)
totalLength: 200 (00 c8), protocol: UDP (11)
UDP-Header: sourcePort:5004 (138c), destPort:10032(2730), length: 180 (00 b4)
RTP-Header: 80
1000 0000
10-- ---version: 2
--0- ---padding: false (keine Füllbits)
---0 ---extension: false (kein Erweiterungsheader)
---- 0000
contributing source identifiers count: 0
08
0000 1000
payload type: ITU-T G.711 PCMA (8)
3a b1 0011 1010 1011 0001
sequence number: 1525
e9 37 99 5f
time stamp
dd 96 8c 24
synchronisation source identifier: 3.717.631.012
Payload:
55 55 55 54 57 .. 58 59
insgesamt 160 PCM-Worte
71
Probleme bei VoIP durch NAT
A-Tln
192.168.1.1
B-Tln
141.55.3.3
NAT-Gateway
84.80.2.2
NAT
Privates Netzwerk
Router
Internet
Netzwerk B
INVITE F1
INVITE F2
INVITE F3
180 Ringing F6
180 Ringing F5
180 Ringing F4
ACK
ACK
ACK
RTP Sprache zu A F7
F1
UDP:IP
SDP
5060 : 192.168.1.1
5060 : 141.55.3.3
F7
UDP:IP 192.168.1.1 : 10002
141.55.3.3 : 1700
c=IN IP4 192.168.1.1
F2,F3
UDP:IP
50000 : 84.80.2.2
5060 : 141.55.3.3
SDP c=IN IP4 192.168.0.2
F4,F5
UDP:IP
84.80.2.2 : 50000
F6
UDP:IP 192.168.1.1 : 5060
VoIP-Teilnehmer in privaten Netzen, können
Verbindungsprobleme haben:
•
•
zu einem VoIP-Teilnehmer im öffentlichen Netz
zu einem VoIP-Teilnehmer in einem anderen
privaten Netz (schlimmster Fall).

Das Senden der Sprachdaten scheitert, weil Router
keine Pakete zu privaten IP-Adressen durch das
öffentliche Internet routen.

Fehlerbild: SIP-Verbindung kommt zustande, B hört A
aber A hört B nicht!
141.55.3.3 : 5060
141.55.3.3 : 5060
72
Probleme bei VoIP durch NAT



Es kommen unterschiedliche NAT-Typen zum Einsatz, die hier kurz besprochen
werden.
RFC 3498, abgelöst durch RFC 5780, klassifizieren NAT-Typen.
Nachfolgend sind beide Begriffswelten dargestellt.
RFC 5780
NAT-Type
Mapping
Filtering
RFC 3489
1
EIM (Endpoint-Independent)
EIF (Endpoint-Independent)
Full Cone
2
ADF (Address-Dependent)
Restricted Cone
3
APDF (Address and Port-Dependent)
4
ADM (Address-Dependent)
EIF (Endpoint-Independent)
-
5
ADF (Address-Dependent)
-
6
APDF (Address and Port-Dependent)
-
7
APDM (Address and Port-Dependent) EIF (Endpoint-Independent)
-
8
APDM (Address and Port-Dependent) ADF (Address-Dependent)
-
9
APDM (Address and Port-Dependent) APDF (Address and Port-Dependent)
Port Restricted Cone
Symmetric
73
NAT-Type 1 (Full Cone)
/RFC 5389, NETM/
A
B
NAT
Private Network
NAT-Type 1
Full Cone
5000:A
80:B
1000:N
80:B
Endpoint-Independent
Mapping
5000:A
90:B
1000:N
90:B
5000:A
8080:C
1000:N
8080:C
5000:A
80:X
1000:N
80:X
EIF
X
Y
Public Network
EIM
Filtering
C
Endpoint 5000:A ist (i.d.R. zeitlich begrenzt)
über 1000:N von jedem Host erreichbar!
A:5000
X:80
N:1000
X:80
A:5000
X:90
N:1000
X:90
A:5000
Y:8080
N:1000
Y:8080
74
NAT-Type 2 (Restricted Cone)
/RFC 5389, NETM/
A
Private Network
NAT
NAT-Type 2
Restricted
Cone
B
5000:A
80:B
1000:N
80:B
Mapping
5000:A
90:B
1000:N
90:B
5000:A
8080:C
1000:N
8080:C
5000:A
80:X
1000:N
80:X
ADF
X
Y
Public Network
EIM
Address-Dependent
Filtering
C
über 1000:N von Host X erreichbar!
A:5000
X:80
N:1000
X:80
A:5000
X:90
N:1000
X:90
N:1000
Y:8080
75
NAT-Type 3 (Port Restricted Cone)
A
Private Network
/RFC 5389, NETM/
NAT
NAT-Type 3
Port Restricted
Cone
B
5000:A
80:B
1000:N
80:B
Mapping
5000:A
90:B
1000:N
90:B
5000:A
8080:C
1000:N
8080:C
5000:A
80:X
1000:N
80:X
APDF
X
Y
Public Network
EIM
Address- and PortDependent Filtering
C
über 1000:N nur von Port:Host 80:X erreichbar!
A:5000
X:80
N:1000
X:80
N:1000
X:8080
N:1000
Y:80
76
NAT-Type 9 (Symmetric)
/RFC 5389, NETM/
A
B
NAT
Private Network
NAT-Type 9
Symmetric
5000:A
80:B
1000:N
80:B
Address- and PortDependent Mapping
5000:A
90:B
1002:N
90:B
5000:A
80:C
1004:N
80:C
5000:A
80:X
1000:N
80:X
APDF
X
Y
Public Network
APDM
Address- and PortDependent Filtering
C
über 1000:N nur von Port:Host 80:X erreichbar!
A:5000
X:80
N:1000
X:80
N:1000
X:8080
N:1000
Y:80
77
STUN: Überblick

STUN steht für unterschiedliche Begriffe
– RFC 3489, 2003: "Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators"
– RFC 5389, 2010: "Session Traversal Utilities for NAT (STUN)".

STUN ist ein Protokoll, womit ein STUN-Client mithilfe eines STUN-Server herausfinden kann, ob NAT angewendet wird und welcher NAT-Typ verwendet wird.
Hier wird STUN nach RFC 5389 besprochen.

Szenario:

A mit STUN-Client
NAT
Private Network


NAT-Type X
STUN-Server mit den:
• Adressen: B, C
• Ports: 3478, 3479
Public Network
Binding Request
Binding Request
Binding Response
Binding Response
Ein STUN-Server hat zwei IP-Adressen (B, C) und zwei Portnummern (3478, 3479).
Client und Server nutzen zur Kommunikation zwei Messages:
– Binding Request,
– Binding Response.
78
STUN: Messages und NAT-Erkundungs-Attribute /RFC 5389/5780/

Binding-Request-Attribute
– CHANGE-REQUEST, mit Flags:
• Change IP,
• Change Port,
steuern das Antwortverhalten
des STUN-Servers.


Client sendet Binding Request
an STUN-Adresse
mit
Change IP
0
0
1
1
Change Port
0
1
0
1
--->
3478:B
3478:B
3478:B
3478:B
STUN-Server antwortet
mit Adresse
<--B:3478
B:3479
C:3478
C:3479
Binding-Response-Attribute
Attribut
vom Server zurückgegebene Werte
MAPPED-ADDRESS
IP/Port des Binding-Request-Senders
RESPONSE-ORIGIN
IP/Port des Binding-Response-Senders
OTHER ADDRESS
IP/Port des zweiten Adressenpaares des STUN-Servers
XOR MAPPED
ADDRESS
IP/Port der MAPPED-ADDRESS-Attributwerte, verschleiert durch eine XOR-Operation
mit dem TransactionID, weil manche Application-Layer-Gateways die IP-Adresse und
Portnummern verändern.
Um das Mapping- und Binding-Verhaltens von NAT's heraus zu finden, werden
jeweils 3 Testschritte ausgeführt.
79
STUN: Test des NAT-Mapping-Verhaltens /RFC 5389/5780, NETM/
Start
Test1
No NAT
Testende
Test2
EIM-NAT
Testende
Test3
ADM-NAT
Testende
APDM-NAT
Testende
Test
Aktionen und Wertevergleiche
T1
A --> 3478:B BindingReq mit ChangeIP=0, ChangePort=0
T2
T3
A
B
C
3478
3479
EIM-NAT
ADM-NAT
APDM-NAT
STUN-Client
primäre IP STUN-Server
alternative IP STUN-Server
primäre Portnummer STUN-Server
alternative Portnummer STUN-Server
Endpoint-Independent-Mapping-NAT
Address-Dependent-Mapping-NAT
Address-Port-Dependent-Mapping-NAT
Ergebnis
(a) No BindingRes
(b) BindingRes mit XOR-MAPPED-ADDRESS==Client-Address (A: IP und Port)
(c) BindingRes mit XOR-MAPPED-ADDRESS!=Client-Address (A: IP und Port)
A --> 3478:C BindingReq mit ChangeIP=0, ChangePort=0
(a) BindingRes mit XOR-MAPPED-ADDRESS== XOR-MAPPED-ADDRESS_T1
UDP-Blockade -->Testende
No NAT
-->Testende
NAT
-->Test 2
(b) BindingRes mit XOR-MAPPED-ADDRESS!= XOR-MAPPED-ADDRESS_T1
noEIM-NAT -->Test3
A --> 3479:C BindingReq mit ChangeIP=0, ChangePort=0
(a) BindingRes mit XOR-MAPPED-ADDRESS== XOR-MAPPED-ADDRESS_T2
ADM-NAT
(b) BindingRes mit XOR-MAPPED-ADDRESS!= XOR-MAPPED-ADDRESS_T2
APDM-NAT -->Testende
EIM-NAT
-->Testende
-->Testende
MSC's : http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 17.11.2014
80
STUN: Test des NAT-Filtering-Verhaltens /RFC 5389/5780, NETM/
Start
Test1
Test2
EIF-NAT
Testende
Test3
ADF-NAT
Testende
ADPF-NAT
Testende
Test
Aktionen und Wertevergleiche
T1
T2
T3
A
B
C
3478
3479
EIF-NAT
AIF-NAT
APDF-NAT
STUN-Client
primäre IP STUN-Server
alternative IP STUN-Server
primäre Portnummer STUN-Server
alternative Portnummer STUN-Server
Endpoint-Independent-Filtering-NAT
Address-Independent-Filtering-NAT
Address-Port-Dependent-Filering-NAT
Ergebnis
(a) No BindingRes
(b) BindingRes
(a) BindingRes
UDP-Blockade -->Testende
--> Test 2
(b) No BindingRes
--> Test3
(a) BindingRes
ADF-NAT
(b) No BindingRes
APDF-NAT --> Testende
EIF-NAT
-->Testende
-->Testende
MSC's : http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 17.11.2014
81
NAT-Traversal1)

NAT-Typ1
Lösung durch STUN
(EIM/EIF, Full-Cone-NAT) VoIP
möglich
– Mittels Binding-Request-Response die NAT-Gateway-Adresse N ermitteln
– In INVITE kann der UA-A die öffentliche IP-Adresse N eintragen
INVITE
UDP:IP
SDP
5060 : B
5060 : A
c=IN IP4 N
– RTP-Verbindung möglich: A ist über N von jedem Host/Port erreichbar.

NAT-Typ2
(EIM/ADF, Restricted-Cone-NAT) VoIP
bedingt möglich
– Mittels Binding-Request-Response die NAT-Gateway-Adresse N ermitteln
– In INVITE kann der UA-A die öffentliche IP-Adresse N eintragen
INVITE
UDP:IP
SDP
5060 : B
5060 : A
c=IN IP4 N
– RTP-Verbindung ist nur dann möglich, wenn A an B zyklisch ein UDP-Paket sendet.
– Dadurch ist A über N von B erreichbar.


NAT-Type 3 (EIM/APDF, Port Restricted Cone NAT) VoIP mit STUN nicht möglich
NAT-Type 4 (APDM/APDF, Symmetric NAT) VoIP mit STUN nicht möglich
1) überquerend
82
NAT-Traversal 1) Lösung durch TURN /RFC 5766/

TURN
"Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"
– ist ein Protokoll, wodurch ein Host auch hinter einem NAT-Typ 4/9, eingehende Daten
über TCP- oder UDP-Verbindungen empfangen kann
– bietet die gleichen Sicherheit wie symmetrisches NAT.

Szenario (stark vereinfacht):
Tln. A mit TURN-Client
TURN-Server
NAT
A
Private Network
NAT-Type X
N
Public Network
Relay-AddressRq a:A  3478:T
Relay-AddressRq n:N  3478:T
A:aT:3478 Relay-AddressRs T:x
N:n  T:3478 Relay-AddressRs T:x
Tln. B
T
B
Endpoint a:A ist über n:N von 3478:T erreichbar!
(SDP x:T) INVITE 5060:A  5060:B
(SDP x:T) INVITE N  5060:B
A:5060  B:5060 200 OK (SDP B:y)
N  B:5060 200 OK (SDP B:y)
ACK A  B
ACK N  B
y:B Remote-AddressRq a:A  3478:T
y:B Remote-AddressRq n:N  3478:T
RTP a:A  3478:T
RTP n:N  3478:T
A:a  T:3478 RTP
N:n  T:3478 RTP
RTP x:T  y:B
T:x  B RTP
1) überquerend
83
Literatur
Fachbücher
/TRICK /
SIP, TCP/IP und Telekommunikationsnetze
Next Generation Networks und VoIP – konkret, Oldenburg, 2009, ISBN 978-3-486-59000-5
/BADACH/
Voice over IP, Hanser Verlag, 2005, ISBN 3-446-40304-3
Taschenbuch
/STEIN/
Taschenbuch Rechnernetze und Internet, Fachbuchverlag Leipzig, 2004, ISBN 3-446-22573-0
Standards
/H.323/
Visual telephone systems and equipment for local area networks which provide a non guaranteed quality of service
/RFC 3261/
Session Initiation Protocol
/RFC 3665/
Session Initiation Protocol (SIP) Basic Call Flow Examples
/RFC 4566/
Session Description Protocol (SDP)
/RFC 3489/
Simple Traversal of UDP through NATs (STUN)
/RFC 5389/
Session Traversal Utilities for NAT (STUN)
/RFC 3550/
Real Time Protocol (RTP) with Real Time Control Protocol (RTCP)
URLs
/NETM/
http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 12.11.2014
84
NAT-Traversal 1) Lösung durch ICE /RFC 5245/

ICE, RFC 5245
1) überquerend
85
A1:


Sprachcodierung
Anforderungen an Codierung: Qualität, geringe Datenrate.
Für VoIP nutzt man zwei Codierungsprinzipien:
– Abtastorientierte Codierung: Abtastrate=8 kHz, abgetasteter Signalwert wird codiert.
– Segmentorientierte Codierung: Abtastrate=8 kHz, abgetasteter Signalwerte eines
Zeitraumes (10 ms … 30 ms) werden auf Parameter abgebildet. Diese werden zum Empfänger
gesendet und dort werden daraus 10ms…30 ms Sprachsignale synthetisiert.
Bitrate
kbit/s
PCM: 64
60
Abtastorientiert
40
Segmentorientiert
30
ADPCM: 40
ADPCM: 32
ADPCM: 24
20
ADPCM: 16
10
CS-ACELP:5,3
LD-CELP: 16
CS-ACELP: 6,4
schlecht
PCM
ADPCM
ACELP
MP-MLQ
LD-CELP
CS-ACELP
CS-ACELP: 8
gut
Pulse Code Modulation
Adaptive Differential PCM
Algebraic-Code-Excited Linear Prediction
Multipulse Maximum Likelhood Quantization
Low-Delay CELP
Conjugate-Structure ACELP
Weitere Details /BADACH/, 131 ff
Qualität
A1:
Sprachcodierung: Audio-Samples1) ,Sprachqualität
PCM
G. 711
ADPCM
G.726
LD-CELP
G. 728
CS-ACELP
G. 729
CELP
LPC
GSM
GSM 6.10
64 kbps 32 kbps 16 kbps 8 kbps 4.8 kbps 2.4 kbps 13 kbps
Space
Shuttle
Music
Bit Errors
0.1%
Bit Errors
1%

Sprachqualität ist subjektiv. Zur Objektivierung nutzt man einen standardisierten
Testaufbau. Testpersonen bewerten den Höreindruck.
MOS-Wert
5 excellent keinerlei Anstrengung zum Verstehen notwendig; entspanntes Hören
4
good keine Anstrengung erforderlich; Aufmerksamkeit nötig
3
fair
leichte Anstrengung nötig
2
poor merkbare Anstrengung nötig
1
bad trotz Anstrengung, kein Verstehen
1) Quelle: /Dr. Andreas Steffen, http://www.strongsec.com/zhw/KSy_VoIP_1.pdf/
87
A1:


Sprachcodierung: MOS-Skala, Verzögerung
MOS-Werte typischer
Codierverfahren 1)
PCM
ADPCM
ACELP
MP-MLQ
LD-CELP
CS-ACELP
G.711
G.726
G.723.1
G.723.1
G.728
G.729
Bitrate kbps
MOS-Wert
64
16 /24 /32 /40
5,3
6,3
16
8 /6,4
4,3 – 4,5
3,4 /3,6 /3,9 /4,2
3,5
3,7
4,0
4,0 /3,8
Einfluss auf die Sprachqualität haben aber auch Verzögerungzeiten
Kodierung und
Paketierung
SubnetzVerzögerung
InternetVerzögerung
PufferVerzögerung
Depaketierung
und Dekodierung
20 ms
0 … 100 ms
50 … 1000 ms
0 … 100 ms
20 ms
Sender
Netzlaufzeit 50 …1100 ms
Empfänger 20 …120 ms
Ende-zu-Ende-Verzögerung 90 …1240 ms
Mensch empfindet Verzögerungen:
OK:
0..250 ms,
Akzeptabel:
250…400 ms,
Unakzeptabel:
ab 400 ms,
1) weitere Angaben: /NÖLLE/, S48 ff
A2:
IETF: SIP session setup example /RFC 3261, Figure 1/
atlanta.com . . . biloxi.com
.
proxy
proxy
.
.
.
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
Phone
Phone
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
INVITE F2
|
|
| 100 Trying F3 |--------------->|
INVITE F4
|
|<---------------| 100 Trying F5 |--------------->|
|
|<-------------- | 180 Ringing F6 |
|
| 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------|
200 OK F9 |
|<---------------|
200 OK F10 |<---------------|
|
200 OK F11 |<---------------|
|
|<---------------|
|
|
|
ACK F12
|
|------------------------------------------------->|
|
Media Session
|
|<================================================>|
|
BYE F13
|
|<-------------------------------------------------|
|
200 OK F14
|
|------------------------------------------------->|
|
|
89
IETF: SIP session setup example
F1
F3
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 142 //SDP nicht gezeigt
SIP/2.0 100 Trying
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
F2
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1
Max-Forwards: 69
CSeq: 314159 INVITE
Content-Length: 142
F5
SIP/2.0 100 Trying
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
91
F4
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.2
;received=192.0.2.1
Max-Forwards: 68
CSeq: 314159 INVITE
Content-Length: 142 //SDP nicht dargestellt
F6
SIP/2.0 180 Ringing
;received=192.0.2.3
;received=192.0.2.2
;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
CSeq: 314159 INVITE
Content-Length: 0
92
F7
SIP/2.0 180 Ringing
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
F8
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
93
F9
SIP/2.0 200 OK
;received=192.0.2.3
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
F10
SIP/2.0 200 OK
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 131
94
F11
SIP/2.0 200 OK
;received=192.0.2.1
CSeq: 314159 INVITE
F12
ACK sip:[email protected] SIP/2.0
Max-Forwards: 70
CSeq: 314159 ACK
Content-Length: 0
95
F13
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
F14
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
96

VoIP

Transcrição

Documentos relacionados

BT Wholesale VoIP

Altersarmut ist weiblich

Bob Proctor In Wien laden wir Sie ein

3937231536_Leseprobe

7. Übung

Systemexperte (m/w) VoIP / Softswitch

Presseinformation - Union Investment Real Estate GmbH

Die Next Generation Networks im Hochschullabor

SIP 1 - Survival Guide

We Say Disco You Say Maybe