Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
2015-11
VoIP – Voice over IP
Prof. Dr.-Ing. habil. Lutz Winkler
Fakultät Elektro- und Informationstechnik
https://www.telecom.hs-mittweida.de
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Ziel und Inhalt der Vorlesung
2
Ziel – Prinzip von VoIP, Unterschiede zur klassischen Telefonie
– Implementationsansätze von ITU und IETF
– Funktion und Nutzung typischer Protokolle
Inhalt
Einführung ............................................................................................................................................... 3
Standardisierung ..................................................................................................................................... 10
ITU-H.323-Lösung ................................................................................................................................... 12
ITU-H.323-Beispiel .................................................................................................................................. 20
IETF-SIP/SDP-Lösung ............................................................................................................................ 23
IETF-SIP/SDP-Beispiele ......................................................................................................................... 47
IETF-SDP ................................................................................................................................................ 46
RTP ……………....................................................................................................................................... 67
Probleme bei VoIP durch NAT/NAPT …………………............................................................................ 72
STUN, TURN ......................................................................................................................................... 78
Literatur ................................................................................................................................................... 85
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Einführung: Telefonie über das Fernsprechnetz – Szenario
ISDN-Telefone NT
OVSt A/D
OVSt D/A
D/A
FVSt
S0-Bus
a/b-Telefon
Signalgabekanäle
CuDAn CuDAn
NT ISDN-Telefone
S0-Bus
a/b-Telefon Nutzkanäle
64 kbit/s
Steuerung Steuerung Steuerung Signalgabekanäle
Nutzkanäle
64 kbit/s
4
A/D
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Einführung: Telefonie über das Fernsprechnetz – Merkmale
5
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.
Fernsprechnetz
Stimmt das? ähhh
01001111 11100011 0100010 0101010 01101111
11111010 00011010 11111111 01010101 01010101
64 kbit/s
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Einführung: VoIP Szenario, Ablauf
6
Domain-Controller-Aufgaben: Nutzeranmeldung, Adressauflösung SIP-URIIP, 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]
• sip:[email protected]
• sip:[email protected]
• 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.
VoIP-Domain-Controller VoIP-SoftPhone
VoIP-Telefon
G G
IP-Netz
IP-Router
IP-Router Domain a.de
VoIP-Telefon
Domain b.de
VoIP-Domain-Controller VoIP-SoftPhone
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Einführung: VoIP - Prinzip
usw. usw. usw.
VoIP-Proxy a.de VoIP-Telefon VoIP-Telefon
VoIP-Proxy b.de
Hörer wird abgenommen
es klingelt
A/D
A/D
PH
PH
RTP: Sprachdaten RTP: Sprachdaten RTP: Sprachdaten RTP: Sprachdaten
RTP: Sprachdaten RTP: Sprachdaten RTP: Sprachdaten
IP-Router IP-Router IP-Router
Nu
tzu
ng
Sitz
un
gsau
fbau
A
bb
au SIP-Signalgabe: BYE
SIP-Signalgabe: 200 OK
Hörer wird aufgelegt
Wahl u. Hörer abnehmen
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.
SIP+SDP: INVITE
SIP: 180 RINGING
SIP+SDP: 200 OK
SIP: ACK
7
SIP+SDP: INVITE
SIP: 180 RINGING
SIP+SDP: 200 OK
SIP: ACK
SIP+SDP: INVITE
SIP: 180 RINGING
SIP+SDP: 200 OK
SIP: ACK
A/D
A/D
PH
PH
RTP: Sprachdaten
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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).
PH
01001111 11100011 01000100 01010101 01101111
R R
R R
R R
Datagram x
R R PCM- A/D
PH
PH PCM- A/D
PH
11111010
00011010
01010101
11111010
00011010
01010101
11111010
00011010
01010101
11111010
00011010
01010101 Datagram 1
Datagram i
Datagram 1 Datagram j Datagram y
Einführung: VoIP - Merkmale
packet handler
8
01001001 11111111 01011100 01000101 01100001
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IP-Netz (Internet)
VoIPVoIP
CS-Netz Internet CS-Netz
Phone/VoIPGateway
PhoneVoIPGatewaysPhone
P0
7 8
5
2
P0
7 8
5
2
IP-Netz CS-Netz (PSTN)
VoIP/PhoneGateway VoIPGatewayPhone
P0
7 8
5
2
CS Circuit Switched (Leitungs-, kanalvermittelt)
PSTN Public Switched Telephony Network (Öffentliches Telefonnetz)
9
Einführung: Drei Basisszenarien für VoIP
VoIP/PhoneGateway
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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 – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
VoIP-Standardisierung
CISCO: SCCP - Skinny Client Control Protocol
– proprietäres Signalgabeprotokoll zwischen IP-Telefonen und dem so genannten Call-Manager.
– Endgeräte senden/empfangen einfache Nachrichten die durch den Call Manager interpretiert/erzeugt werden, wodurch sie auch weniger angreifbar als SIP- oder H.323-Endgeräte sind.
– Die Endgeräte sind relativ einfach und benötigen wenig Rechenleistung.
– Nachrichtenbeispiele http://www.protocols.com/pbook/VoIPFamily.htm#Skinny :
11
Endgeräte Call-Manager
SCCP SIP/SDP oder H.323
– Der Call-Manager nutzt dann aber SIP/SDP bzw. H.323 als Signalgabeprotokoll.
SCCP-Messages vom Endgerät SCCP-Messages zum Endgerät
Register Message Display Text Message
Unregister Message Clear Display Message
Key Pad Button Message Start Tone Message
Enbloc Call Message Stop Tone Message
Off Hook Message Set Ringer Message
On Hook Message Set Lamp Message
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Ziel ist Multimedia-Kommunikation Sprache Video Daten – Netzübergreifend, über verschiedene Netze, – über Netze mit und ohne QoS (Quality of Service), – Sprachkommunikation ist nur ein Teil.
Wichtige Standardserien sind:
T.120 (Data Protocols for
Multimedia Conferencing)
Multimedia-Konferenzen zwischen Terminals an verschiedenen Netzen (Filetransfer,
Shared Applications, Chat, Standbild, Audio,
Video),
H.320 (Narrow-band Visual Telephone Systems and
Terminal Equipment)
Multimedia-Konferenzen über das ISDN unter Nutzung eines oder mehrerer B- oder H-Kanäle
H.323 (Packet-based Multimedia
Conferencing Systems)
Multimedia-Konferenzen über Netze, die keine garantierte QOS bieten
H.324 (Terminal for low bit rate
Multimedia Conferencing)
Multimedia-Konferenzen über das analoge Fernsprechnetz
12
ITU: Multimedia Teleconferencing Standards
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
ITU - H.323: Szenario
4 wesentliche Funktionsgruppen – auch Endsysteme
genannt:
– Terminals
– Gatekeeper
– MCU
– Gateway
H.323-MCU (Multipoint Control Unit)
H.323- Gatekeeper
H.323- Gateway
H.324 Terminal
Speech Terminal
H.322 Terminal
Speech Terminal
H.320 Terminal
Terminal
Switched Telephone Network
QOS LAN
Narrow ISDN
Funknetze
Packet switched network
H.323- Terminal
Terminal für die Multimedia-Kommunikation mit geringen Bitraten. Standards für Video-Codecs mit geringen Datenraten, die über V.34 mit analogen Telefonleitungen arbeiten
Visual telephone systems and terminal equipment for local area networks which provide a guaranteed quality of service
Narrow-band visual telephone systems and terminal equipment
H.323- Terminal
Terminal-adapter
P0
7 8
5
2
P0
7 8
5
2
14
Scope of H.323
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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.
H.323-Zone - Voice over PS-Zone
IP-Netz
H.323-Multipoint Control Unit
H.323-SoftPhone
H.323-HardPhone
H.323-Gatekeeper
OVSt oder TK-Anlage
FVSt oder TK-Anlage
Voice over CS-Zone
P0
7 8
5
2
H.323- Gateway
Fernsprechnetz- Signalgabe
Sprache: PCM, circuit switched
VoIP- Signalgabe
Sprache: XX, packet-switched
P0
7 8
5
2
P0
7 8
5
2
Terminal- adapter
16
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
ITU - H.323 : Terminal und Stack
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 MikroCodecRTP,UDP,IP und umgekehrt
Signalgabe nächste Seite
Anwendungsteile
H.245 Bearer- Control
H.245 Bearer- Control
H.225.0 Call-
Control
H.225.0 Call-
Control
H.225.0 RAS
H.225.0 RAS
System Control User Interface
Data Interface
T.120
Data Interface
T.120
Data Applications
Audiocodec G.711, G.728,
Audiocodec G.711, G.728,
Microphone, Speaker
Videocodec H.263, H.261 Videocodec
H.263, H.261
Camera, Display
System Control
RTP (RTCP) RTP (RTCP)
TCP UDP
IP
Anwendungsprotokolle
Transportprotokolle
17
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
ITU - H.323: Prinzip der Protokollnutzung (Kanalnutzung)
nach /STEFFEN/
AUFBAU
1
2
3
4
5
6
ABBAU
12
11
10
9
8
7
G.7xx G.7xx RTP,RTCP/UDP RTP,RTCP/UDP Audio-Channels
H.26x H.26x RTP,RTCP/UDP RTP,RTCP/UDP Video-Channels
Control-Channel ▼ Terminaleigenschaften austauschen,
logische Kanäle öffnen bzw. ▲ schließen
H.245 H.245 TCP TCP
User-Data-Channels T.120 T.120 TCP TCP
Standard Transport Service Kanal/Aufgabe
RAS-Channel: ▼ GK suchen, anmelden, Kommunikations-Erlaubnis,
▲ Bandbreite freigeben, abmelden
H.225.0 H.225.0 UDP UDP
Q.931 Q.931 TCP TCP Call Signalling Channel: ▼ Verbindung zu B-Tln. herstellen bzw. ▲ abbauen
19
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IP-Netz
ITU - H.323 : H.245-RAS (GK-Erkundung, An-/Abmeldung am GK)
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
GK 2 Terminal GK 1
Gatekeeper_Rq
IP-Multicast 224.0.1.41, UDP 1718
Gatekeeper_Cf
IP-Unicast-Adresse des GK1
Gatekeeper_Cf
IP-Unicast-Adresse des GK2
Gatekeeper_Rj
Registration_Rq(caSigAddr,teType,teAliases,tToLive) IP-Unicast, UDP 1719 Registrierung beim GK (RRq,RCf,RRj);
Parameter:
• callSignalAddress: IP-Addr
• terminalType: TE, MCU, GW
• terminalAliases: PhoneNr, E-Mail
• timeToLive: gewünschte Dauer
Registration_Cf(timeToLive)
alt
Registration_Rj(rejectReason,alternateGK)
DeRegistrierung beim GK (URq,UCf,URj)
Unregistration_Rq() IP-Unicast, UDP 1719
Terminal, MCU, GW
Unregistration_Cf()
alt
Unregistration_Rj(rejectReason)
Weitere Details /BADACH/, /STEFFEN/ 224.0.1.41 = Multicastadresse für H.225 Gatekeeper Discovery
20
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IP-Netz
ITU - H.323 : H.245-RAS (Location, Admission, Disengage, Bandwidth)
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.
GK 2 Terminal, MCU, GW Terminal GK 1
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
Location_Rq(aliasAddress) IP-Multicast 224.0.1.41, UDP 1718
Location_Cf(callSignalAddress)
Location_Rj(rejectReason)
alt
Admission_Rq(callModel,bandWidth) IP-Unicast, UDP 1719
Admission_Cf(callModel,bandWidth)
Admission_Rj(rejectReason)
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
DisEngage_Rq() IP-Unicast, UDP 1719
DisEngage_Cf()
DisEngage_Rj(rejectReason)
Bandwidth_Cf()
Bandwidth_Rj(rejectReason)
Bandbreitenänderung (BRq,BCf,BRj) • Anforderung einer veränderten
Bandbreite gegenüber der, die bei Admission_Rq gefordert wurde.
Bandwidth_Rq(bandWidth) IP-Unicast, UDP 1719
Weitere Details /BADACH/, /STEFFEN/
21
alt
alt
alt
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
ITU - H.323 : Call Setup and Control (ohne GK)
IP-Netz
Terminal, MCU, GW Terminal GK
Admission_Rq
Admission_Cf
Q.931_SETUP
Admission_Cf
Admission_Rq
Wahl u. Hörer abnehmen
es klingelt
H.245-Channel öffnen
Austausch Terminal_Capabilities
Austausch Terminal_Capabilities
RTP-Kanal öffnen
RTP-Kanal öffnen
Bidirektionaler RTP/UDP-Kanal für Sprache
RTP-Kanal schließen
RTP-Kanal schließen
Q.931_CALL_PROC
Q.931_ALERT
Q.931_CONNECT
H.245-Channel schließen
Hörer auflegen
Kommuni-kation
Kommuni-kation
Hörer abnehmen
Q.931_RELEASE
Q.931_RELEASE_COMPLETE
DisEngage_Rq()
DisEngage_Cf
Kommunikationsablauf
• In diesem Beispiel wird der Call direkt
zwischen den Endpunkten ausgehandelt.
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!
DisEngage_Rq()
DisEngage_Cf
22
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF : VoIP-Protokollübersicht
23
VoIP-HardPhone/-SoftPhone VoIP-HardPhone/-SoftPhone
TCP
Nutzdaten
SIP Session Initiation Protocol
SIP Session Initiation Protocol
RTP Real Time Protocol
RTP Real Time Protocol
RTCP RT Control Protocol RTCP RT Control Protocol
SDP Session Description Protocol
SDP Session Description Protocol
UDP
Signalgabe
IP
Übertragungsnetzwerk (LAN, DSL, Modem)
Anwendungs-
Oberfläche
Anwendungs-
Teile
Anwendungs-
Protokolle
Transport-
Protokolle
+ Updates + Updates
TLS Transport Layer Security
TLS Transport Layer Security
DTLS Datagram Transport Layer Security
DTLS Datagram Transport Layer Security
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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 SIP-Message Body übermittelt.
– Die Parameter werden ausgehandelt: AngebotAnnahme/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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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 RTP-Datenverkehr 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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Aufbau SIP-Request-Messages
SIP-Instanzen kommunizieren über Messages. Man unterscheidet: Request-Messages und Response-Messages.
Request-Messages:
Request Line
Message Headers vom Typ: General, Request, Entity
method SP request-URI SP SIP-version CRLF
Leerzeile
[Message Body
SDP-Protokoll ]
*( header-name ":" header-value CRLF )
RFC 3261
"v=" (protocol version) CRLF
"o=" (owner/creator session_id) CRLF
"c=" *(connection information) CRLF
...
RFC 4566
CRLF
26
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP-Standard-Request-Methoden
Basismethoden Bedeutung RFC
INVITE 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
ACK Finale Empfangsbestätigung einer INVITE-Methode.
Der Empfang von ACK hat keine Response-Message (Statusinformation) zur Folge!
3261
CANCEL Abbruch der aktuellen Transaktion innerhalb einer Session 3261
BYE 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
Im RFC 3261 werden sechs grundlegende Request-Methoden festgelegt.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Erweiterte SIP-Request-Methoden
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 Rufweiterleitungen)
3515
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
PRACK SIP kennt zwei Responsetypen : Final Response (OK), Provisional Response ACKnowledgement (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.
3262
UPDATE Anpassung der RTP-Session-Parameter in der Aufbauphase (Medienströme, verfügbare Codec‘s, …).
Nur verwendbar zwischen INVITE und dem finalen ACK.
Ansonsten muss ein Re-INVITE verwendet werden.
3311
MESSAGE Ermöglicht die Übertragung kurzer Sofort-Textmitteilungen (Instant Messaging, Chatten). 3428
Die Steuerung von VoIP-Sitzungen kann recht komplex werden. Das SIP-Protokoll wurde und wird durch weitere Methoden ergänzt.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Aufbau SIP-Response-Messages
Response-Messages:
29
SIP-version SP status-code SP status-phrase CRLF
*( header-name ":" header-value CRLF )
"v=" (protocol version) CRLF
"o=" (owner/creator session_id) CRLF
"c=" *(connection information) CRLF
...
Status Line
Message Headers vom Typ:
General, Response, Entity
Leerzeile
[Message Body
SDP-Protokoll ]
RFC 3261
RFC 4566
CRLF
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Oft genutzte SIP-Response-Codes /RFC 3261, Section 21/
30
Code Phrase Description Other RFC Provisional 1xx Informative, vorläufige Antworten 100 Trying Verbindungsaufbau wird versucht 180 Ringing Bei B klingelt es 181 Call Is Being Forwarded Anruf wird weitergeleitet 182 Queued Anruf befindet sich in Warteschleife, ev. mit Angabe Wartende/Wartezeit Successful 2xx Bestätigung erfolgreicher Requests 200 Ok Request erfolgreich ausgeführt 202 Accepted Verbindung wurde akzeptiert 3265 Redirection 3xx Weiterleitungsantworten 300 Multiple Choices 301 Moved Permanently SIP-URI permanent geändert, d.h. diese ist ungültig 302 Moved Temporarily SIP-URI temporär geändert, d.h. Teilnehmer ist unter anderer URI erreichbar 305 Use Proxy Verbindung zu B über Proxy herstellen 380 Alternative Service B für angeforderten Dienst nicht erreichbar, aber alternative Dienste möglich Request Failure 4xx Fehlerhafte Client-Requests 400 Bad Request Fehlerhafter SIP-Request 401 Unauthorized Registrar-Antwort: Autorisierung fehlt 402 Payment Required Erst blechen, dann sprechen 403 Forbidden Server hat Anfrage verstanden, weigert sich aber, diese auszuführen 404 Not Found Nutzer-URI existiert in dieser Domäne nicht 407 Proxy Authentication Required Autorisierung gegenüber Proxy erforderlich 486 Busy Here Der Angerufene kann/will den Anruf nicht entgegen nehmen Server Failure 5xx Serverfehler 503 Service Unavailable Server kann derzeit Request nicht bearbeiten, wegen Überlastung/Wartung/… 505 Version Not Supported Im Request verwendete SIP-Version wird nicht unterstützt 513 Message Too Large Requestverarbeitung scheiterte, da die Message zu groß war Global Failure 6xx 600 Busy Everywhere Alle Anschlüsse besetzt 604 Does Not Exist Anywhere B-Teilnehmer nicht existent
Weitere Übersichten, z.B. unter: http://www.3cx.de/voip-sip/sip-responses/ verfügbar am 21.09.2014
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP-Grundlagen /RFC 3261/
31
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.
Arbeitet ein Proxie zustandslos, werden die Messages nur durchgereicht. In dem Fall
gibt es keine Server-Client-Anordnung in dem Proxy.
Clie
nt
Clie
nt
serv
er
Clie
nt
serv
er
serv
er
UA-A Outbound
Proxy Inbound
Proxy UA-B
Request Request Request
Response Response Response
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP-Dialog/-Transaction /RFC 3261/
Dialog = ein oder mehrere Transaktionen,
Transaktion = abgeschlossene Request-/Response-Folge, man unterscheidet:
– INVITE-Transaction:
• Transaction 1
– NON-INVITE-Transaction:
• Transaction 2
• Transaction 3
32
SIP-UA A SIP-UA B
INVITE
100 Trying
Session
200 OK
Bye
180 Ringing
200 OK
ACK
Transaction 1
Transaction 2
Transaction 3
Dialog
Dialog Identifier sind:
– Call-ID-Wert
– Tag-Wert1) im From-Header
– Tag-Wert im To-Header
Transaction Identifier:
– Branch-Wert im Via-Header
– CSequ-Wert
UA
-A-C
lien
t U
A-A
-Clie
nt
UA
-B-S
erve
r U
A-B
-Ser
ver
UA
-A-S
rv
UA
-A-S
rv
UA
-B-C
lt
UA
-B-C
lt
1) Tag-Wert ist mindestens eine 32-Bit-Zufallszahl, RFC 3261, Section 19.3
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP 3-Way-Handshake /RFC 3261/
INVITE-Transaktionen werden durch ein 3-
Wege-Handschlag sicher gemacht, z.B.:
– INVITE 200 OK ACK
– INVITE 486 Busy ACK
33
UA A UA B
INVITE
100 Trying
Session
180 Ringing
200 OK
ACK
Damit vermeidet man undefinierte
Zustände.
Beispielsweise:
– 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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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.
34
Basis-Timer (Auswahl)
T1 500 ms Kann in privaten Netzen kleiner sein (RTT)
T2 4s The maximum retransmit interval for non-INVITE requests and INVITE responses
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
UA A UA B INVITE
INVITE
INVITE
INVITE
0,5
1
2
4 8
16
32
A B
BYE 0,5
1
2
4 4 … 4
32
E F
BYE
BYE
BYE
Abbruch
Abbruch
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SDP – Session Description Protocol /RFC 4566/
35
SDP dient zur Parametrisierung von Multimediasitzungen, z.B.: – zur Aushandlung der beteiligten Medienströme (Audio, Video), der Codec's, – Zur Angabe, an welcher Portnummern ein Medienstrom erwartet wird usw.
Der Transport von SDP-Messages erfolgt in der Entity einer SIP-Message.
Beispielhafte SDP-Nachricht aus RFC 2327: //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 …
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SDP – Session Description Protocol
m/o Typ <Verwendung>, beispielhafte Werte Bedeutung
Elemente zur Sitzungsbeschreibung
m v= version Protokollversion
v= 0 derzeit wird Version 0 verwendet
m o= username sess-id sess-version nettype addrtype unicast-address Angaben des Sitzungerzeugers (originator)
o= mhandley 2890844526 2890842807 IN IP4 126.16.64.4
Username: mhandley |root|win|…
Session ID: 2890844526
Session Version: 2890842807
Network Type: IN
Address Type: IP4
Address: 126.16.64.4
m s= session name Bezeichnung der Session
s= SDP Seminar call |konferenz | besprechung | …
o i= session description Session-Beschreibung
i= A Seminar on the session description protocol
o u= uri URI auf Session-Material
u= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
o e= email-address E-Mail-Adresse einer Kontaktperson
e= [email protected] (Mark Handley) muss nicht Adresse des Originator‘s sein
o p= phone-number Telefonnummer einer Kontaktperson
p= +49-3727-581290 | +49 3727 581290 muss nicht Nummer des Originator‘s sein
o c= network type address type connection address Parameter der Nutzdatenadresse
c= IN IP4 224.2.17.12/127 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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SDP – Session Description Protocol
erf Typ Verwendung, beispielhafte Werte Bedeutung
Elemente zur Sitzungsbeschreibung
o b= bandwith information
b=<modifier>":"<bandwith-value>
b=AS:384
erforderliche Bitrate (in kbit/s)
"Bandbreite" der Anwendung 384 kbit/s
o z= time zone adjustment
z=*(<adjustment time>SP<offset>)
z=2882844526 -1h 2898848070 0
o k= encryption key
k=(<method> | <method>":"<encryption key>) Verwendung: siehe RFC 1890 (RTP)
o a= zero or more session description lines
a= Verwendung siehe weiter unten
Elemente zur Zeitbeschreibung
m t= time the session is active
t=<start time>SP<stop time>
t=0 0
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.
o r= zero or more repeat times
r=<repeat interval>SP<active duration>SP<offset list>
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SDP – Session Description Protocol
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
<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
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.
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.
a=ptime:20 Dauer der Sprachpakete in ms, entspricht bei PCM
20.000µs/125µs=160 PCM-Worte
a=inactive|sendrcv|sendonly|rcvonly Richtungsattribute
1) Werte siehe Tabellen 4/5 in RFC 3551 "RTP Profile for Audio and Video Conferences with Minimal Control „
2) fmt - format
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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.
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.
39
[email protected] [email protected]
Initial Offer(1)
Answer(1)
Offer(2)
Answer(2)
Session(2)
Answer(3)
Session(3)
Offer(3)
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Offer/Answer Beispiel /RFC 3264/
40
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
m=audio 49170 RTP/AVP 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
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Offer/Answer Beispiel /RFC 3264/
41
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:
v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 0 4 18 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=inactive
Bob can support dynamic switching between PCMU and G.723. So, he sends the following answer:
v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=inactive
Alice can then select any one of these two codecs. So, she sends an updated offer with a sendrecv stream:
v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv
Bob accepts the single codec: v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
SIP-Registrar, SIP-Location,
SIP-Presence,
SIP-Proxy, SIP-Redirect
SIP-
Gateway
Switched
Telephone
Network
… Narrow
ISDN Funknetze
Packet switched network
SIP-
Terminal
SIP-
Terminal
SIP-
Terminal
SIP-
Terminal
SIP-
Terminaladapter
SIP-
Terminaladapter P
0
7 8
5
2
P0
7 8
5
2
SIP-
Confernce
Scope
of IETF
42
SIP-Switch: Zusammenfassung von: Proxy, Redirect, Registrar, Presence, Gateway, …
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP User Agent (UA)
43
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.
UAC UAS UAC UAS UAS UAC
SIP-Proxy
Direkte Session
Session über Proxy
SIP-Endgerät A SIP-Endgerät B
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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 (bei kommenden und gehenden Calls, bzw. bei
Supplementary Services).
Der SIP-Proxy kann
– 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-Response-Aktion).
44
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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 KonferenzteilnehmerFOCUS.
– Knotenpunkt für Nutzdaten und deren Verteilung an alle KonferenzteilnehmerMIXER.
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP-Funktionalitäten und Relationen
(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.
Proxy
Redirect Server
Location ServiceRegistrar
1
1 1
2
2 2
2
3
3
47
zum entfernten B-Teilnehmer
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP-/SDP-Signalgabe-Beispiele
48
Element Display Name permanent URI IP Address
------- ------------ ------------- ----------
User Agent Alice [email protected] 192.0.2.101
User Agent Bob [email protected] 192.0.2.201
User Agent [email protected] 192.0.2.100
Proxy Server ss1.atlanta.example.com 192.0.2.111
Proxy/Registrar ss2.biloxi.example.com 192.0.2.222
Proxy Server ss3.chicago.example.com 192.0.2.233
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:
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP registration example /RFC 3261, nach Fig. 9/
49
Bob‘s Phone meldet sich beim Registrar
(hier z.B. ohne Autorisierung) an.
Anmeldung wird i.d.R. zyklisch wiederholt.
F1 REGISTER sip:registrar.biloxi.com SIP/2.0 Methode, Adresse des Registrars, SIP-Version
Via: SIP/2.0/UDP bobspc.biloxi.com:5060; branch=z9hG4bKnashds7
Via: dient zur Adressierung der Route von SIP-Messages; branch (zweig) = FixString "z9hG4bK" und Zufallsstring der Einmaligkeit garantiert.
Max-Forwards: 70 SIP-Proxies dekrementieren diesen Wert. Bei Null, wird die SIP-Message verworfen .
To: Bob <sip:[email protected]> Permanente SIP-Teilnehmer-URI. Zu erzeugender Adresseintrag in der Location-Datenbank.
From: Bob <sip:[email protected]>;tag=456248 Urheber des Eintrages in die Location-Datenbank. ; tag ist Zufallszahl (mind. 32 Bit).
Call-ID: 843817637684230@998sdasdh09 Weltweit einmaliger Call-Id, soll te Zeit-, Raum- und Zufallskomponenten enthalten.
CSeq: 1826 REGISTER Sequenznummer und Methode, referenziert Request und Response
Contact: <sip:[email protected]> Temporäre IP von Bob‘s Telefon. In der Location-Datenbank sind dann zugeordnet sip:[email protected]=192.0.2.201
Expires: 7200 Gültigkeitsdauer der Registrierung. Nach Ablauf wird Eintrag aus der Location-DB gestrichen.
Content-Length: 0 Länge des Message body (SDP-Nachrichtenlänge)
F2 SIP/2.0 200 OK Methode, Adresse des Registrars, SIP-Version
Via: SIP/2.0/UDP bobspc.biloxi.com:5060; branch=z9hG4bKnashds7; received=192.0.2.201 Via: dient zur Adressierung der Route von SIP-Messages;
To: Bob <sip:[email protected]>;tag=2493k59kd Permanente SIP-Adresse.
From: Bob <sip:[email protected]>;tag=456248 identifiziert zwingend den Urheber der Message; tag ist Zufallszahl (mind. 32 Bit).
Call-ID: 843817637684230@998sdasdh09 weltweit einmaliger Call-Id, soll Zeit-, Raum- und Zufallskomponenten enthalten
CSeq: 1826 REGISTER Sequenznummer und Methode, referenziert Request und Response
Contact: <sip:[email protected]> Momentane Bindung URI-IP-Adresse: sip:[email protected]=192.0.2.201
Expires: 7200 Gültigkeitsdauer der Registrierung. Nach Ablauf wird Eintrag aus der Location-DB gestrichen.
Content-Length: 0 Länge des Message body (SDP-Nachrichtenlänge)
bob’s reg.biloxi.com ldap.biloxi.com phone registrar | | | | | REGISTER F1 | | |---------------->| | | | [email protected] | | |---------------->| | 200 OK F2 | 192.0.2.201 | |<----------------| | | | |
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Registration /RFC 3665/
50
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| 401 Unauthorized F2 |
|<------------------------------|
| REGISTER F3 |
|------------------------------>|
| 200 OK F4 |
|<------------------------------|
| |
F3 REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 Max-Forwards: 70 From: Bob <sips:[email protected]>;tag=ja743ks76zlflH To: Bob <sips:[email protected]> Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sips:[email protected]> Authorization: Digest username="bob", realm="atlanta.example.com" nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sips:ss2.biloxi.example.com", response="dfe56131d1958046689d83306477ecc" Content-Length: 0
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
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 Call-ID: [email protected] 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 From: Bob <sips:[email protected]>;tag=a73kszlfl To: Bob <sips:[email protected]>;tag=1410948204 Call-ID: [email protected] CSeq: 1 REGISTER WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", algorithm=MD5 Content-Length: 0
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Digest Authentication /RFC 1321/
51
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 128-bit "fingerprint" or "message digest" of the input.
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="atlanta.example.com", Name des geschützten Bereichs (realm)
qop="auth", "quality of protection“: Authentication
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
Zufallswert im Hexformat
opaque="", Weiterer Zufallswert
algorithm=MD5 Verwende Hashfunktion "MD5“
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Authorization: Digest
username="bob", Benutzername
realm="atlanta.example.com", Name des geschützten Bereichs
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
Zufallswert im Hexformat
opaque="",
uri="sips:ss2.biloxi.example.com", URI(s), für den(die)
Authorisierung gelten soll
response="dfe56131d1958046689d83306477ecc"
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Cancellation of Registration /RFC 3665/
52
Bob SIP Server
| |
| REGISTER F1 |
|------------------------------>|
| |
| 200 OK F4 |
|<------------------------------|
| |
Das Abmelden geschieht über den SIP-Header Expires: 0.
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 Expires: 0 Contact: * Authorization: Digest username="bob", realm="atlanta.example.com", nonce="88df84f1cac4341aea9c8ee6cbe5a359", opaque="", uri="sips:ss2.biloxi.example.com", response="ff0437c51696f9a76244f0cf1dbabbea" 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=a73kszlfl To: Bob <sips:[email protected]>;tag=1418nmdsrf Call-ID: [email protected] CSeq: 1 REGISTER Content-Length: 0
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Successful Session Establishment /RFC 3665/
53
Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE F5 | |<-----------------------| nicht dar- | 200 OK F6 | |----------------------->| gestellt | |
F2 SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=8321234356 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];transport=tcp> Content-Length: 0
F3 SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=8321234356 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];transport=tcp> Content-Type: application/sdp 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 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
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] Call-ID: [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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F4 ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=8321234356 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0
Schwarz/fett Dialog-ID Violett/fett Transaction ID
F1 bis F3 INVITE-Transaction F4 Non-INVITE-Transaction
Beschreibung der Konzepte: siehe Folie
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Session Establishment Through Two Proxies /RFC 3665/
54
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 pre-loaded 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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Session Establishment Through Two Proxies /RFC 3665/
55
F1 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F5 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 69 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 2 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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F4 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected];transport=tcp> Proxy-Authorization: Digest username="alice", realm="atlanta.example.com", nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="", uri="sip:[email protected]", response="42ce3cef44b22f50c6a6071bc8" 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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F7 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 68 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 2 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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Session Establishment Through Two Proxies /RFC 3665/
56
F12 SIP/2.0 200 OK Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=314159 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected];transport=tcp> Content-Type: application/sdp 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 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F14 SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=314159 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected];transport=tcp> Content-Type: application/sdp 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 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F13 SIP/2.0 200 OK Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=314159 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected];transport=tcp> Content-Type: application/sdp 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 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Session via Redirect and Proxy Servers with SDP in ACK
57
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 | | |--------------->| | | |
/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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Session via Redirect and Proxy Servers with SDP in ACK
58
F1 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 Max-Forwards: 70 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Length: 0
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 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=314159 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected];transport=tcp> Content-Type: application/sdp 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 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F2 SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=53fHlqlQ2 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];transport=tcp> Content-Length: 0
F4 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]> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:[email protected];transport=tcp> Content-Length: 0
F11 ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bq9 Max-Forwards: 70 Route: <sip:ss3.chicago.example.com;lr> From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=314159 Call-ID: [email protected] CSeq: 2 ACK 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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Unsuccessful Busy /RFC 3665/
59
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Unsuccessful Busy /RFC 3665/
60
F1 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: <sip:ss1.atlanta.example.com;lr> From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];transport=tcp> Proxy-Authorization: Digest username="alice", realm="atlanta.example.com", nonce="dc3a5ab2530aa93112cf5904ba7d88fa", opaque="", uri="sip:[email protected]", response="702138b27d869ac8741e10ec643d55be" 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 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F6 SIP/2.0 486 Busy Here Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE
F3 SIP/2.0 100 Trying Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Content-Length: 0
F11 ACK 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]>;tag=314159 Call-ID: [email protected] CSeq: 1 ACK Proxy-Authorization: Digest username="alice", realm="atlanta.example.com", nonce="dc3a5ab2530aa93112cf5904ba7d88fa", opaque="", uri="sip:[email protected]", response="702138b27d869ac8741e10ec643d55be" Content-Length: 0
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Consultation Hold /5359/
61
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 | | |--------------------------------->| | | Both way RTP Established | | | |<=================>| | | BYE F25 | | | |<-------------| | | | | BYE F26 | | |--------------------------------->| | | | 200 OK F27 | | |<---------------------------------| | | 200 OK F28 | | | |------------->| | | | INVITE F29 | | | INVITE F30 |<-------------| | |<---------------| | | | 200 OK F31 | | | |--------------->| 200 OK F32 | | | |------------->| | | | ACK F33 | | | |<-------------| | | ACK F34 | | | |<---------------| | | | Both way RTP Established | | |<=============================>| |
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Consultation Hold /5359/
62
F10 INVITE sips:[email protected] SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sips:[email protected]>;tag=314159 To: Alice <sips:[email protected]>;tag=1234567 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sips:[email protected]> Content-Type: application/sdp Content-Length: ... v=0 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 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 To: Alice <sips:[email protected]>;tag=1234567 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sips:[email protected]> Content-Type: application/sdp Content-Length: ... v=0 o=bob 2890844527 2890844529 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
F12 SIP/2.0 200 OK Via: SIP/2.0/TLS ss1.example.com:5061 ;branch=z9hG4bK837497.1 ;received=192.0.2.54 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds7 ;received=192.0.2.105 From: Bob <sips:[email protected]>;tag=314159 To: Alice <sips:[email protected]>;tag=1234567 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sips:[email protected]> Content-Type: application/sdp Content-Length: ... v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s= c=IN IP4 client.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 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 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds7 ;received=192.0.2.105 From: Bob <sips:[email protected]>;tag=314159 To: Alice <sips:[email protected]>;tag=1234567 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sips:[email protected]> Content-Type: application/sdp Content-Length: ... v=0 o=alice 2890844526 2890844528 IN IP4 client.atlanta.example.com s= c=IN IP4 client.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Call Pickup /RFC 5359/
63
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Call Pickup /RFC 5359/
64
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 To: Bob <sips:[email protected]> Call-ID: [email protected] CSeq: 1 SUBSCRIBE Contact: <sips:[email protected]> 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]> Call-ID: [email protected] CSeq: 1 INVITE Require: replaces Replaces: [email protected] ;from-tag=314578;to-tag=1234567;early-only Contact: <sips:[email protected]>
F5 NOTIFY sips:[email protected] SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bK74br Max-Forwards: 70 From: Bob <sips:[email protected]>;tag=31451098 To: Bill <sips:[email protected]>;tag=8675309 Call-ID: [email protected] CSeq: 1 NOTIFY Contact: <sips:[email protected]> 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-Type: application/sdp 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 m=audio 5342 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* 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 …
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Rufumleitung
65
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: F4 INVITE sip:[email protected] SIP/2.0
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: Call Forking
66
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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:
V P X CC M Payload Type Sequence number
Timestamp
Synchronisation source (SSRC) identifier
Sprach-, Videodaten
0 7 15 23 31 8 16 24
Contribution source (CSRC) identifiers (Liste mit 0 oder bis max. 16 Einträgen)
68
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
RTP: RTP Fixed Header Fields /RFC 3550/
Feld Bits Bedeutung
Version 2 Versionsnummer, derzeit 2
Padding 1 Wenn dieses Bit gesetzt ist, enthalt das Paket am Ende Füllbytes. Die genaue Anzahl steht im letzten Byte des Paketes.
eXtension 1 Falls das Bit gesetzt ist, folgt dem Header ein Erweiterungsheader
CSRC count (CC) 4 Zähler, der die Anzahl der CSRC-Kennungen angibt, die dem fixen Header folgen
Marker 1 Die Benutzung dieses Bits wird durch die Profile geregelt. M zeigt beispielsweise das letzte Paket an. /RFC 1890/, Abschnitt 4.1
Payload type 7 Dieses Feld verweist auf die Art der Nutzlast. Ein Profil spezifiziert die Nutzlasttypen und deren Eigenschaften. /RFC 1890/, Tabelle 2
Sequence number 16 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.
Timestamp 32 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.
Synchronisation source (SSRC) identifier
32 Innerhalb einer RTP-Sitzung eindeutige Kennung der Synchronisationsquelle. Wird auch zufällig ermittelt
Contribution source (CSRC) identifiers
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
Table 4: Payload types (PT) for audio encodings
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
RTP-Paket
0000 00 04 13 22 3f cc 00 0b 82 03 90 d6 08 00 45 00 MAC-Header 0010 00 c8 bd 04 00 00 fa 11 04 f7 8d 37 f1 dc 8d 37 IP-Header 0020 f1 dd 13 8c 27 30 00 b4 33 fb 80 08 3a b1 e9 37 UDP-Header 0030 99 5f dd 96 8c 24 55 55 55 54 57 54 54 57 54 d5 RTP-Header 0040 d5 57 54 d1 d0 d7 d5 d4 54 50 56 54 56 51 56 55 Payload 0050 d5 54 54 d7 d3 d1 55 56 55 d5 56 5d 5f 5c 53 56 0060 57 57 55 d1 d2 d0 d1 d6 d4 54 51 52 5e 58 59 5f 0070 5d 53 51 57 d7 d3 d0 d5 54 54 57 53 5f 58 58 47 0080 40 5a 50 57 56 51 57 d5 d4 54 52 5e 59 58 45 45 0090 5a 5b 58 5c 53 51 56 56 54 d5 55 51 5c 58 5a 5b 00a0 58 5b 5a 59 53 56 56 54 55 d5 54 51 5d 58 46 41 00b0 45 58 5b 45 46 5b 54 d1 55 50 51 55 54 5c 5a 44 00c0 5a 5b 44 47 45 5f 53 56 54 55 55 57 56 56 50 5f 00d0 5a 47 44 5a 58 59
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Probleme bei VoIP durch NAT
UDP:IP SDP c=IN IP4 192.168.1.1 m=audio 10002 RTP/AVP 0 8 3
UDP:IP SDP c=IN IP4 192.168.0.2 m=audio 10002 RTP/AVP 0 8 3
F2,F3
UDP:IP
F7
72
5060 : 141.55.3.3 5060 : 192.168.1.1
5060 : 141.55.3.3 50000 : 84.80.2.2
F1
UDP:IP
F4,F5
84.80.2.2 : 50000 141.55.3.3 : 5060
UDP:IP
F6
192.168.1.1 : 5060 141.55.3.3 : 5060
192.168.1.1 : 10002 141.55.3.3 : 1700
A-Tln 192.168.1.1
B-Tln 141.55.3.3
Privates Netzwerk
INVITE F1
Router
Router NAT NAT Internet Netzwerk B
NAT-Gateway 84.80.2.2
INVITE F2 INVITE F3
RTP Sprache zu A F7
180 Ringing F4 180 Ringing F5 180 Ringing F6
ACK ACK ACK
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!
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!
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
Probleme bei VoIP durch NAT
73
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 RFC 3489 NAT-Type Mapping Filtering
1 EIM (Endpoint-Independent) EIF (Endpoint-Independent) Full Cone
2 EIM (Endpoint-Independent) ADF (Address-Dependent) Restricted Cone
3 EIM (Endpoint-Independent) APDF (Address and Port-Dependent) Port Restricted Cone
4 ADM (Address-Dependent) EIF (Endpoint-Independent) -
5 ADM (Address-Dependent) ADF (Address-Dependent) -
6 ADM (Address-Dependent) 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) Symmetric
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Type 1 (Full Cone) /RFC 5389, NETM/
74
Private Network NAT-Type 1 Full Cone
NAT-Type 1 Full Cone
Endpoint 5000:A ist (i.d.R. zeitlich begrenzt) über 1000:N von jedem Host erreichbar!
A NAT B
Public Network
80:B 5000:A
C Y
EIM Endpoint-Independent
Mapping 90:B 5000:A
8080:C 5000:A
80:B 1000:N
90:B 1000:N
8080:C 1000:N
N:1000 X:80 A:5000 X:80
N:1000 X:90 A:5000 X:90
N:1000 Y:8080 A:5000 Y:8080
EIF Endpoint-Independent
Filtering
X
80:X 5000:A 80:X 1000:N
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Type 2 (Restricted Cone) /RFC 5389, NETM/
Private Network NAT-Type 2 Restricted
Cone
NAT-Type 2 Restricted
Cone
Endpoint 5000:A ist (i.d.R. zeitlich begrenzt) über 1000:N von Host X erreichbar!
A
75
NAT B
Public Network
80:B 5000:A
C Y
EIM Endpoint-Independent
Mapping 90:B 5000:A
8080:C 5000:A
80:B 1000:N
90:B 1000:N
8080:C 1000:N
N:1000 X:80 A:5000 X:80
N:1000 X:90 A:5000 X:90
N:1000 Y:8080
ADF Address-Dependent
Filtering
X
80:X 5000:A 80:X 1000:N
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Type 3 (Port Restricted Cone) /RFC 5389, NETM/
Private Network NAT-Type 3
Port Restricted Cone
NAT-Type 3 Port Restricted
Cone
Endpoint 5000:A ist (i.d.R. zeitlich begrenzt) über 1000:N nur von Port:Host 80:X erreichbar!
A
76
NAT B
Public Network
80:B 5000:A
C Y
EIM Endpoint-Independent
Mapping 90:B 5000:A
8080:C 5000:A
80:B 1000:N
90:B 1000:N
8080:C 1000:N
N:1000 X:80 A:5000 X:80
N:1000 X:8080
N:1000 Y:80
APDF Address- and Port-
Dependent Filtering
X
80:X 5000:A 80:X 1000:N
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Type 9 (Symmetric) /RFC 5389, NETM/
Private Network NAT-Type 9 Symmetric
NAT-Type 9 Symmetric
Endpoint 5000:A ist (i.d.R. zeitlich begrenzt) über 1000:N nur von Port:Host 80:X erreichbar!
A
77
NAT B
Public Network
80:B 5000:A
C Y
APDM Address- and Port-
Dependent Mapping 90:B 5000:A
80:C 5000:A
80:B 1000:N
90:B 1002:N
80:C 1004:N
N:1000 X:80 A:5000 X:80
N:1000 X:8080
N:1000 Y:80
APDF Address- and Port-
Dependent Filtering
X
80:X 5000:A 80:X 1000:N
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
STUN: Überblick
78
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 heraus-
finden kann, ob NAT angewendet wird und welcher NAT-Typ verwendet wird.
Hier wird STUN nach RFC 5389 besprochen.
Szenario:
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.
Private Network NAT-Type X NAT-Type X
A mit STUN-Client NAT STUN-Server
Public Network
mit den: • Adressen: B, C • Ports: 3478, 3479
Binding Request Binding Request
Binding Response Binding Response
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
STUN: Messages und NAT-Erkundungs-Attribute /RFC 5389/5780/
79
Binding-Request-Attribute – CHANGE-REQUEST, mit Flags:
• Change IP,
• Change Port,
steuern das Antwortverhalten des STUN-Servers.
Binding-Response-Attribute
Um das Mapping- und Binding-Verhaltens von NAT's heraus zu finden, werden
jeweils 3 Testschritte ausgeführt.
Client sendet Binding Request mit
an STUN-Adresse STUN-Server antwortet
mit Adresse Change IP Change Port ---> <---
0 0 3478:B B:3478 0 1 3478:B B:3479 1 0 3478:B C:3478 1 1 3478:B C:3479
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.
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
STUN: Test des NAT-Mapping-Verhaltens /RFC 5389/5780, NETM/
80
Test Aktionen und Wertevergleiche Ergebnis
T1 A --> 3478:B BindingReq mit ChangeIP=0, ChangePort=0
(a) No BindingRes UDP-Blockade -->Testende
(b) BindingRes mit XOR-MAPPED-ADDRESS==Client-Address (A: IP und Port) No NAT -->Testende
(c) BindingRes mit XOR-MAPPED-ADDRESS!=Client-Address (A: IP und Port) NAT -->Test 2
T2 A --> 3478:C BindingReq mit ChangeIP=0, ChangePort=0
(a) BindingRes mit XOR-MAPPED-ADDRESS== XOR-MAPPED-ADDRESS_T1 EIM-NAT -->Testende
(b) BindingRes mit XOR-MAPPED-ADDRESS!= XOR-MAPPED-ADDRESS_T1 noEIM-NAT -->Test3
T3 A --> 3479:C BindingReq mit ChangeIP=0, ChangePort=0
(a) BindingRes mit XOR-MAPPED-ADDRESS== XOR-MAPPED-ADDRESS_T2 ADM-NAT -->Testende
(b) BindingRes mit XOR-MAPPED-ADDRESS!= XOR-MAPPED-ADDRESS_T2 APDM-NAT -->Testende
A STUN-Client B primäre IP STUN-Server C alternative IP STUN-Server 3478 primäre Portnummer STUN-Server 3479 alternative Portnummer STUN-Server EIM-NAT Endpoint-Independent-Mapping-NAT ADM-NAT Address-Dependent-Mapping-NAT APDM-NAT Address-Port-Dependent-Mapping-NAT
MSC's : http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 17.11.2014 MSC's : http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 17.11.2014
Test1
Test2
Test3
Start Start
No NAT No NAT
EIM-NAT EIM-NAT
ADM-NAT ADM-NAT
APDM-NAT APDM-NAT
Testende Testende
Testende Testende
Testende Testende
Testende Testende
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
STUN: Test des NAT-Filtering-Verhaltens /RFC 5389/5780, NETM/
81
Test Aktionen und Wertevergleiche Ergebnis
T1 A --> 3478:B BindingReq mit ChangeIP=0, ChangePort=0
(a) No BindingRes UDP-Blockade -->Testende
(b) BindingRes --> Test 2
T2 A --> 3478:B BindingReq mit ChangeIP=1, ChangePort=1
(a) BindingRes EIF-NAT -->Testende
(b) No BindingRes --> Test3
T3 A --> 3478:B BindingReq mit ChangeIP=0, ChangePort=1
(a) BindingRes ADF-NAT -->Testende
(b) No BindingRes APDF-NAT --> Testende
A STUN-Client B primäre IP STUN-Server C alternative IP STUN-Server 3478 primäre Portnummer STUN-Server 3479 alternative Portnummer STUN-Server EIF-NAT Endpoint-Independent-Filtering-NAT AIF-NAT Address-Independent-Filtering-NAT APDF-NAT Address-Port-Dependent-Filering-NAT
MSC's : http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 17.11.2014 MSC's : http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 17.11.2014
Test1
Test2
Test3
Start Start
EIF-NAT EIF-NAT
ADF-NAT ADF-NAT
ADPF-NAT ADPF-NAT
Testende Testende
Testende Testende
Testende Testende
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Traversal1) Lösung durch STUN
82
NAT-Typ1 (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
– 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
– 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
UDP:IP SDP c=IN IP4 N m=audio 10002 RTP/AVP 0 8 3
5060 : B 5060 : A
INVITE
UDP:IP SDP c=IN IP4 N m=audio 10002 RTP/AVP 0 8 3
5060 : B 5060 : A
INVITE
1) überquerend
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Traversal 1) Lösung durch TURN /RFC 5766/
83
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):
1) überquerend
Private Network NAT-Type X NAT-Type X
Tln. A mit TURN-Client NAT TURN-Server
Public Network
Tln. B
Relay-AddressRq a:A 3478:T
A N T B
Relay-AddressRq n:N 3478:T
N:n T:3478 Relay-AddressRs T:x A:aT:3478 Relay-AddressRs T:x
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
N B:5060 200 OK (SDP B:y) A:5060 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 RTP x:T y:B
T:x B RTP N:n T:3478 RTP A:a T:3478 RTP
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
NAT-Traversal 1) Lösung durch ICE /RFC 5245/
85
ICE, RFC 5245
1) überquerend
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
A1: Sprachcodierung
PCM Pulse Code Modulation
ADPCM Adaptive Differential PCM
ACELP Algebraic-Code-Excited Linear Prediction
MP-MLQ Multipulse Maximum Likelhood Quantization
LD-CELP Low-Delay CELP
CS-ACELP Conjugate-Structure ACELP
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 60
40
30
20
10
PCM: 64
ADPCM: 40
ADPCM: 32
ADPCM: 24
ADPCM: 16
Qualität schlecht gut
LD-CELP: 16
CS-ACELP: 8 CS-ACELP: 6,4 CS-ACELP:5,3
Abtastorientiert
Segmentorientiert
Weitere Details /BADACH/, 131 ff
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
A1: Sprachcodierung: Audio-Samples1) ,Sprachqualität
PCM G. 711
64 kbps
ADPCM G.726
32 kbps
LD-CELP G. 728
16 kbps
CS-ACELP G. 729
8 kbps
CELP
4.8 kbps
LPC
2.4 kbps
Space Shuttle
Music
Bit Errors 0.1%
Bit Errors 1%
GSM GSM 6.10
13 kbps
1) Quelle: /Dr. Andreas Steffen, http://www.strongsec.com/zhw/KSy_VoIP_1.pdf/
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
87
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
A1: Sprachcodierung: MOS-Skala, Verzögerung
Einfluss auf die Sprachqualität haben aber auch Verzögerungzeiten
Bitrate kbps MOS-Wert
PCM G.711 64 4,3 – 4,5 ADPCM G.726 16 /24 /32 /40 3,4 /3,6 /3,9 /4,2 ACELP G.723.1 5,3 3,5 MP-MLQ G.723.1 6,3 3,7 LD-CELP G.728 16 4,0 CS-ACELP G.729 8 /6,4 4,0 /3,8
1) weitere Angaben: /NÖLLE/, S48 ff
MOS-Werte typischer
Codierverfahren 1)
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,
Kodierung und Paketierung
20 ms
Internet-Verzögerung
50 … 1000 ms
Subnetz-Verzögerung
0 … 100 ms
Depaketierung und Dekodierung
20 ms
Puffer-Verzögerung
0 … 100 ms
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
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
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142 //SDP nicht gezeigt
F1
SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
F3
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
INVITE sip:[email protected] SIP/2.0 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
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142
F2
SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0
F5
91
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142 //SDP nicht dargestellt
F4
SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:[email protected]> CSeq: 314159 INVITE Content-Length: 0
F6
92
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:[email protected]> CSeq: 314159 INVITE Content-Length: 0
F7
SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:[email protected]> CSeq: 314159 INVITE Content-Length: 0
F8
93
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 131 //SDP nicht dargestellt
F9
SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 131
F10
94
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 131 //SDP nicht dargestellt
F11
ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0
F12
95
VoIP – Voice over IP Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de
IETF: SIP session setup example
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 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0
F13
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 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0
F14
96