voip voice over ip - staff.hs-mittweida.dewin/vorlesungen/voip.pdf · 2015-11 voip – voice over...

2015-11

VoIP – Voice over IP

Prof. Dr.-Ing. habil. Lutz Winkler

Fakultät Elektro- und Informationstechnik

https://www.telecom.hs-mittweida.de

[email protected]

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


Einführung: VoIP – Voice over IP

Bisher wurde Sprachkommunikation über leitungs- und kanalvermittelnde Netze

abgewickelt, z.B. Fernsprechnetze, Funkfernsprechnetze.

VoIP ist: – Realisierung von Sprachkommunikation über paketvermittelnde Netze, z.B. Internet.

– Diese Idee wird von verschiedenen Standardisierungsgremien und Firmen verfolgt.

– Es gibt eine Vielfalt von VoIP-Lösungen und eine VoIP-Begriffsvielfalt.

Grundsätzlich sind dabei folgende Probleme zu lösen: – Signalgabe: wie kommt eine Session zwischen Endgeräten zustande?

– Nutzsignalübertragung: wie werden analoge Signale codiert und in Echtzeit über ein Paketnetz übertragen.

Seit Jahren gibt es schon Internet-Telefonie für PC‘s: – „Internet Phone“ (VocalTec, 1995), proprietäre Codecs, Protokolle und Verzeichnisdienste,

– "NetMeeting" (Microsoft, 1998) basierend auf H.323,

– “Skype“ (2003 schwedische/dänische Firma, später Microsoft), proprietäre Codecs, Protokolle und Verzeichnisdienste.

Wichtige Lösungsansätze für kommerzielle VoIP-Lösungen lieferten und liefern: – ITU, IETF, Firmen (z.B. CISCO).

3


Einführung: Telefonie über das Fernsprechnetz – Szenario

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


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


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]




• ...

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


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


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


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-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

http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-H

http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-G

http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-Q


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

http://www.protocols.com/pbook/VoIPFamily.htm#Skinny




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


ITU - H.323: Merkmale

H.323 ist ein (so genannter) Umbrella-Standard und beschreibt Einrichtungen und Verfahren:

– zur Anbahnung von Sitzungen,

– zur Übertragung von Echtzeitsprache, -video und/oder Daten.

H.323-Standardisierung

– V.1: 1996, „Visual telephone systems and equipment for local area networks which provide a non guaranteed quality of service “

– V.2,3,4: 1998, 1999, 2000 „Packet-based multimedia communications systems “

H.323-Einrichtungen arbeiten zusammen über folgende Protokolle:

– Managementzwecke und Signalgabe: RAS (Registration, Admission and Status) , Q.931

– Übertragung von Sprach- und Videodaten: RTP (Real Time Protocol).

Über Gateways können H.323-Geräte zusammenarbeiten mit Endgeräten:

– an Fernsprechnetzen,

– an Funknetzen.

H.323-Endgeräte können Teil eines PC‘s oder eine extra Gerät sein.

13


ITU - H.323: Szenario

4 wesentliche Funktionsgruppen – auch Endsysteme

genannt:

– 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


ITU - H.323 : Gatekeeper, Multipoint Control Unit (MCU)

Gatekeeper (GK) ist ein (optionaler) Server mit den Aufgaben:

– Zonenmanagement: Registrierung aller Endsysteme oder Endpunkte (Terminals, Multiple

Control Units und Gateways).

– Adressenauflösung: Ermittlung der Transportadresse (IP) aus einem URI.

– Zulassung, Ablehnung von Verbindungen: AdmissionRq, AdmissionCf, AdmissionRj,

innerhalb einer Zone.

– Bandbreitensteuerung: Bandwidth_Rq/Cf/Rj, zur Anforderung/Änderung/Zurückweisung

von Bandbreite.

– Gebührenerfassung.

– Call Management: der GK kann Liste aktiver Terminals führen. Kommt Call für aktives

Terminal wird zurückgewiesen/umgeleitet/zur Sprachbox weitergeleitet.

Multipoint Control Unit (MCU) Konferenzen mit drei und mehr Endpunkten.

– Eine MCU besteht aus:

• einem Multipoint Controller (MC) für Signalisierung zwischen Endpunkten.

• und mehreren Multipoint-Prozessoren (MP‘s)

– Ein MP mixt, kodiert um und vermittelt Audio-, Video- und/oder Datenbits zu den Teilnehmern einer Konferenz.

15


ITU - H.323 : Gateway

Gateways – bilden Netzübergang zu anderen Netzen (Fernsprechnetze, Funknetze, …)

– Verhalten sich aus Sicht der H.323-Zone wie ein H.323-Terminal und aus Sicht z.B. des ISDN wie ein ISDN-Terminal.

– Anpassung der Signalgabe und der Nutzdaten in beide Richtungen.

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


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


ITU - H.323 : System Control nutzt 3 Protokolle

H.225.0-RAS: Registration, Admission (Zugang, Erlaubnis) and Status

– Finden eines Gatekeepers (GK): GateKeeper_Request/Confirm/Reject,

– An-/Abmelden eines TE beim GK: Registration_Request/Confirm/Reject, DisEngage_Request/Confirm/Reject

– Kommunikationserlaubnis vom GK einholen: Admission_Request/Confirm/Reject.

– Bandbreite beim GK anfordern: Bandwith_Request/Confirm/Reject

H.225.0-Q.931: Signalgabe zum Sitzungsauf- und –abbau zwischen Terminals über oder ohne Gatekeeper unter Verwendung von Q.931-Messages, z.B. SETUP, CALL_PROCeeding, ALERTing, CONNect, INFOrmation,

RELease_COMplete, PROGress, FACility

H.245: Signalisierungsprotokoll zum:

– Austausch von Terminaleigenschaften TerminalCapabilitySet

– Auf-/Abbau logischer Kanäle zur Sprach-/Videoübertragung (z.B. RTP/RTCP-Kanäle): OpenLogicalChannel, CloseLogicalChannel

– Ermittlung des Round Trip Delay (Umlaufverzögerung der Datenpakte): RoundTripDelay_Request/Response

T.120: Optional, weitere Datenkanäle für Shared Whiteboard, Chat, Filetransfer

18


ITU - H.323: Prinzip der Protokollnutzung (Kanalnutzung)

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


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


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


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


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


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

https://tools.ietf.org/html/rfc3261

http://tools.ietf.org/html/rfc3265





















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













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


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.


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.


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


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

http://www.3cx.de/voip-sip/sip-responses/







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


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


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


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


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 …


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



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>



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


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)


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



a=rtpmap:32 MPV/90000


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


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, …


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


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


IETF: SIP-Registrar/Location/-Server

SIP-Registrar dient zur Registrierung der Teilnehmer einer Domäne:

– Er nimmt REGISTER-Messages von SIP-Terminals an (angemeldet, abgemeldet).

– Trägt die aktuelle IP-Adressen in "Location DB" ein:

unter welcher IP-Adresse ist derzeit sip:[email protected] erreichbar.

– Er kann die Anmeldung von einem Account (<name>, <passwd>) abhängig machen.

SIP-Location-Server:

– stellt SIP-Proxies oder SIP-Redirect-Servers die momentane IP-Adresse eines

gewünschten Teilnehmers aus der "Location DB" zur Verfügung.

– „Location DB“ ist das Home-Location-Register einer VoIP-Domäne.

Die "Location DB" wird durch den SIP-Registrar aktuell gehalten.

Dazu wird z.B. das LDAP (lightweight directory access protocol) genutzt.

45


IETF: SIP-Redirect/-Gateway/-Conference

SIP-Redirect ist ein Server:

– der auf einen Request eine 3xx-Antwort mit der aktuellen B-Adresse zurückgibt, weil ein Teilnehmer z.B. zeitlich an verschiedenen Locations erreichbar ist.

– Dazu greift der Redirektion-Server auf die "Location Service DB" zu.

– Der A-Tln. stellt die Session zu B direkt oder über den Proxy her, wo sich der Teilnehmer z.Zt. befindet.

SIP-Gateway:

– Wandelt die Signalgabe von SIP in z.B. Q.931 und umgekehrt.

– Codiert VoIP-codierte Sprache z.B. in PCM und umgekehrt.

SIP-Conference:

– Knotenpunkt für Signalgabe und deren Verteilung an alle 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


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


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:


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 | |<----------------| | | | |


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


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.


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


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


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.



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



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


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.


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


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.


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


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.


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


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.


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 …


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


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.


Das Real Time Transport Protocol – RTP /RFC 3550/

RTP wurde für die Übertragung von Echtzeitdaten (Voice, Video) entwickelt.

Folgende Hauptmerkmale hat das Protokoll:

– es unterstützt Unicast- und Multicast-Kommunikation,

– keine Flußsteuerung und Fehlerkontrolle

– benutzt UDP (User Datagram Protocol)

– kann aber auch direkt auf unter UDP liegende Protokolle aufsetzen

– RTP wird durch RTCP (RTP Control Protocol) überwacht

– RTCP gestattet insbesondere Empfängern, an den Sender QOS-Parameter zu senden. Dies gestattet dem Sender, z.B. Kodierung und Kompression an die Netzbedingungen anzupassen.

Die Echtzeitdatenübertragung im Internet hat zwei Feinde:

– die Unterschreitung einer Mindestübertragungsrate

– die Überschreitung der zulässigen Verzögerungszeit von Paketen

Bei VoIP sollte eine Verzögerungszeit von 250 ms nicht überschritten werden.

67


RTP: Byte Order, Alignment, Time Format /RFC 3550/

RTP-Funktionen im Überblick sind:

– Anzeige des Payloadtypes, d.h. es wird der Nutzlasttyp angegeben (siehe Folie): • 8 pcma/8000

• 0 pcmu/8000

• 3 gsm/8000 usw.

– Sequenznumerierung, Anfangswert ist Zufallswert, wird in jedem Paket um 1 erhöht,

– Zeitstempel (Absolute Zeit: diese kann mit dem Network Time Protocol (NTP) ermittelt werden).

Der Header hat folgenden Aufbau:

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


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.


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


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


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!


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


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


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


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


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


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


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


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


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.


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

http://www.netmanias.com/en/?m=board&id=techdocs&tag=248





STUN: Test des NAT-Filtering-Verhaltens /RFC 5389/5780, NETM/

81

Test Aktionen und Wertevergleiche Ergebnis


(a) No BindingRes UDP-Blockade -->Testende

(b) BindingRes --> Test 2


(a) BindingRes EIF-NAT -->Testende

(b) No BindingRes --> Test3


(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






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


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


Literatur

Fachbücher

/TRICK / SIP, TCP/IP und Telekommunikationsnetze Next Generation Networks und VoIP – konkret, Oldenburg, 2009, ISBN 978-3-486-59000-5

/BADACH/ Voice over IP, Hanser Verlag, 2005, ISBN 3-446-40304-3

Taschenbuch

/STEIN/ Taschenbuch Rechnernetze und Internet, Fachbuchverlag Leipzig, 2004, ISBN 3-446-22573-0

Standards

/H.323/ Visual telephone systems and equipment for local area networks which provide a non guaranteed quality of service

/RFC 3261/ Session Initiation Protocol

/RFC 3665/ Session Initiation Protocol (SIP) Basic Call Flow Examples

/RFC 4566/ Session Description Protocol (SDP)

/RFC 3489/ Simple Traversal of UDP through NATs (STUN)

/RFC 5389/ Session Traversal Utilities for NAT (STUN)

/RFC 3550/ Real Time Protocol (RTP) with Real Time Control Protocol (RTCP)

URLs

/NETM/ http://www.netmanias.com/en/?m=board&id=techdocs&tag=248 , verfügbar am 12.11.2014

84



NAT-Traversal 1) Lösung durch ICE /RFC 5245/

85

ICE, RFC 5245

1) überquerend


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


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


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


A2: IETF: SIP session setup example /RFC 3261, Figure 1/

atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's Phone Phone | | | |

| INVITE F1 | | |

|--------------->| INVITE F2 | |

| 100 Trying F3 |--------------->| INVITE F4 |

|<---------------| 100 Trying F5 |--------------->|

| |<-------------- | 180 Ringing F6 |

| | 180 Ringing F7 |<---------------|

| 180 Ringing F8 |<---------------| 200 OK F9 |

|<---------------| 200 OK F10 |<---------------|

| 200 OK F11 |<---------------| |

|<---------------| | |

| ACK F12 |

|------------------------------------------------->|

| Media Session |

|<================================================>|

| BYE F13 |

|<-------------------------------------------------|

| 200 OK F14 |

|------------------------------------------------->|

| |

89


IETF: SIP session setup example

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


From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Content-Length: 0

F3



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


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



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



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



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



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



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

voip voice over ip - staff.hs-mittweida.dewin/vorlesungen/voip.pdf · 2015-11 voip – voice over...

Documents