voip_training_2009_14_07

1VoIPTraining

14.07 - 15.07.2009Wolfgang Kampichler

FREQUENTIS 2008 Date: 21-10-2008 Rev.0.1File: voip_training.ppt Author: wok@frq Page: 2

Agenda

Basics IP, UDP, multicast

Basics Quality of Service

VoIP Voice Transport

VoIP Signaling (SIP) Frequentis & VoIP

Discussion

2 FREQUENTIS 2008 Date: 21-10-2008 Rev.0.1File: voip_training.ppt Author: wok@frq Page: 3

IP Features

Connectionless service- Datagram/packet based

Data forwarding

Addressing

Fragmentation and reassembly

Supports variable size datagrams

Best-effort delivery- Delay, out-of-order, corruption, and loss possible higher layers

should handle these


IPv4 Header Format


IPv6 Header Format


What IP does not provide!

End-to-end data reliability and flow control (done by TCP or application layer protocols)

Sequencing of packets (like TCP) Error detection in payload (TCP, UDP or other transport

layers) Error reporting (ICMP) Setting up routing tables (RIP, OSPF, BGP etc) Connection setup (it is connectionless!) Address/Name resolution (ARP, RARP, DNS)


TCP Features I

TCP ensures that IP datagrams are transferred in an orderly, efficient, and reliable manner

Connection opening- On the sending host, a process (such as web browser) issues a

request to send data (such as a URL) to a destination host (such as a web server)

- TCP creates an initial segment designed to open the connection between the sender and the receiver. In this initial contact, the two systems exchange IP addresses and port numbers (to cerate a socket interface) and setup the flow control and sequencing

Flow control- One of the parameters that the sending and receiving hosts exchange

is the number of bytes each is willing to accept in at on time. This way, one system doesn't end up sending more data the other system can handle


TCP Features II

Sequencing- Every segment is assigned a sequence number to reassemble any

segments that arrive out of order

Acknowledgement- When TCP transmits a segment, it holds the segments a queue and if

not receiving an acknowledgement it retransmits the segment.

Error detection- A checksum value in the header lets the receiver test the integrity of

an incoming segment.

Connection closing- TCP sends a segment that tells the receiver that no more data will be

sent and the socket should be closed.


TCP Header Format


UDP Features

There are two main attributes: simple and fast

The only real goal of UDP is to serve as an interface between networking application processes and the internetworking capabilities of IP

Like TCP, UDP layers on top of IP a method of transport-layer addressing (and hence, process identification) through the use of UDP port numbers

In choosing to use UDP, the application writer takes it upon himself or herself to take care of issues such as reliability and retransmissions, if they are needed


UDP/ICMP Header Format


IP and Frequentis

Separation of application and infrastructure User may access any application of any service

provider (e.g. voice or data service) Intelligence and states remain in end-devices (host) No (or little) intelligence within the network (routing,

forwarding) End-devices communicate via applications there is

no (or some) impact from the infrastructure Advantages:

- Flexibility; new applications are easy integrated- Robust- Scalable; no state kept in network (keep it simple and stupid)

Specializing: Infrastructure or Services (=FRQ)


IP Multicast

IP multicasting relies on two mechanisms:- A group management protocol to establish and maintain groups- Multicast routing protocols to route packets efficiently

Internet Group Management Protocol (IGMP)- Manages packet communication between hosts and their local

multicast router, letting them join or leave groups- IGMP Version 3, supports source filtering (only receive packets from

specified multicast sources, rather than all multicast sources)

Switches and Multicast IGMP snooping- IGMP snoopers add a bridge table entry for each multicast group

destination address (IGMP Join) to each switch port that has the interested member's unicast source address already on it

- When an IGMP Leave is received, the entries are removed- Potential for heavy loading of the switch CPU


Agenda





Discussion


What makes the Quality changing?

Router implements two main functions- Forward packets to corresponding output interface- Manage congestion


Router/Switch Interfaces

Input interface- Packet forwarding

- Decide which output interface to forward each packet based on the information in the packet header

Output interface- Buffer management

- Decide when and which packet to drop- Scheduler

- Decide when and which packet to transmit- Packet classification

- Map each packet to a predefined flow/connection- Used to implement more sophisticated services


FIFO Queuing

FIFO: in order of arrival to the queue; packets that arrive to a full buffer are either discarded, or a discard policy is used to determine which packet to discard among the arrival and those already queued


Priority Queuing

Classes have different priorities; class may depend on explicit marking or other header info, e.g. IP source or destination, IP TOS (DSCP), Port numbers, etc.

Transmit a packet from the highest priority class with a non-empty queue

Preemptive and non-preemptive versions

10


Weighted Fair Queuing

A generalized Round Robin in which an attempt is made to provide a class with a differentiated amount of service over a given period of time


Some Ideas

Link Layer (L2) QoS- ATM- Ethernet (802.1p/Q) provided by Ethernet switch- Link Fragmentation and Interleaving (LFI)

IP (L3) QoS- IntServ/RSVP- DiffServ- MPLS (more or less L2.5)

Queuing Techniques- Layer 2/3 (router, switch) devices offer ways to prioritize traffic and

handle congestion- WFQ, CBWFQ, LLQ, and WRED

11


Link-Layer QoS: LFI

Link Fragmentation and Interleaving (LFI)- serialization delay- router technique for dealing with slow links- cuts the big packets into fragments- always combined with priority queuing

Example- 64kbit/s line speed

- 2048kbit/s line speed

Size [Byte] Serialization delay [ms]

48 6.001500 187.50

Size [Byte] Serialization delay [ms]

48 0.191500 5.86


Link-Layer QoS: LFI Example

12


Resource Reservation Protocol (RSVP) An architecture for providing QOS guarantees in IP

networks for individual sessions

Philosophy is similar to ATM- Per flow- End-to-end- Signaling

Needs a signaling protocol; most often- RSVP (Resource Reservation Protocol)

The IntServ architecture is not tied to any particular signaling protocol


Flow based admission

Session must first declare its QOS requirement and characterize the traffic it will send through the network

- R-spec: defines the QOS being requested- T-spec: defines the traffic characteristics

Routers will admit flows based on their R-spec and T-spec and based on the current resource allocated at the routers to other calls

13


Differentiated Services

Intended to address the difficulties with Intserv- Scalability: maintaining states by routers in high speed networks is

difficult due to the very large number of flows - Flexible service models to provide more qualitative service classes;

want to provide relative service distinction (Platinum, Gold, Silver, )

Simpler signaling (than RSVP)- Many applications and users may only want to specify a more

qualitative notion of service

Approach:- Only simple functions in the core, and relatively complex functions at

edge routers (or hosts)- Do not define service classes, instead provide functional components

with which service classes can be built


Edge Functions

Classification - Edge node marks packets according to classification rules to be specified (manually by admin, or by some protocol)

Traffic Conditioning - Edge node may delay and then forward or may discard

14


MPLS Multi Protocol Label Switching

Switching: forwarding packets based on hardware that is a switching matrix

Label: small simple entities that carry both forwarding and QoS information

Label switching: use of labels, as opposed to the IP address-based routing

Multi-Protocol: forwarding based on label switching is not specific to a particular network layer

MPLS was originally proposed to increase efficiency of packet forwarding and to provide differentiated QoS


Agenda





Discussion

15


Voice over IP

Voice over IP begins with digital voice

Analog-to-digital conversion- speech sampling (8kHz, 16kHz)- 64 kbit/s speech

Removing redundancies from sample stream- compression techniques/characterization of compressed speech

Extracting inactive periods- silence/activity detection

AD


Codecs

Mathematical models used to digitally encode (and compress) analog audio information

G.711 is the fundamental codec of PSTN (-law: North America, A-law in the rest of the world)

iLBC (Internet Low Bitrate Codec) well suited to sustaining reasonable quality on lossy network links

Introduce some delay

16


Codec Delays

Algorithmic delay- look-ahead delay (sample N+1) for sample N- G.723.1: 7.5ms

Coder delay- coding and compression delay- can be significant and depend on DSP power and complexity

Packetization delay- function of sample block size required and the- number of blocks placed in a single frame

Decoding delay (~10% of coding delay)


Audio Transport

IP

UDP

RTP

Audio (A)

IP

UDP

RTP

Audio (A)

RTP Stream

A A A A

IP UDP RTP Payload

17


Real-time Transport Protocol (RFC 3550) Designed specifically for real-time data

Functions independently of underlying protocols

RTP Provides- Payload Type Identification exploiting the encoding- Sequence Numbering- Time Stamping

RTCP Provides- Feedback on quality of data distribution- Information on participants- Control of its own bandwidth consumption


RTP Header

RTP header fields- V ... Version: 2 bits (actual value is 2)- P ... Padding: 1 bit, if set, the packet contains padding bytes- X ... Extension: 1 bit, if set the header is followed by header extension- CC ... CSRC count: 4 bits, contain the number of CSRC identifiers- M ... Marker: 1bit- PT ... Payload Type: 7 bit payload type code

MV=2 CC PT sequence numbertimestamp

P X

synchronization source (SSRC) identifiercontributing source (CSRC) identifiers

....

2 3 4 5 6 70 1 2 3 4 5 6 70 1 2 3 4 5 6 70 1 2 3 4 5 6 70 1

18


RTP Header Extension

Extension mechanism to allow implementations of payload independent functions

- FRQ: PTT and Squelch for radio communication- No relative voice delay- Real-time transport- Continuous signaling

defined by profile length

header extension

2 3 4 5 6 70 1 2 3 4 5 6 70 1 2 3 4 5 6 70 1 2 3 4 5 6 70 1


Real-time Transport Control Protocol

RTCP is based on the periodic transmission of control packets to all participants in the session

RTCP performs four functions as follows- Providing feedback on the quality of the data distribution. Can be

used by the participants and third-party monitors- RTCP carries transport-level identifier for an RTP source called the

canonical name (CNAME). This is necessary to associate multiple data streams in a session

- Controlling the RTCP packet rate to scale up to a large number of participants

- Conveys optionally minimal session control information

Has own header

19


ne

two

rk

Systematic Delay

20msconversion

coding compression

packetprocessing

transmission(RTP containing 20ms

audio payload)

syst

em

atic

jitter bufferdecoding

t


Delay occurs on transmitting side, network and receiving side

- Delay on the transmitting side is due to the codec- In the network, delay stems from

- Transmission (serialization and propagation)- Queuing

- Delay on the receiving side is added by- Jitter buffer depth- Decoding and processing and audio device

ITU delay limits (one-way)- 0-150ms ~ toll quality- 150-400ms ~ acceptable

Delay Budget

20


Jitter

Speech is a constant bit-rate service (isochronal)- Packets might have varying transmission time- Variable delays must be removed at the receiving end

Jitter-buffer transforms variable delay into constant delay

- Ensures smooth and continuous playback- Adds delay to the overall delay budget

Jitter buffer can be adaptive, but maximum delay is fixed

- E.g. derived from RTCP information


Jitter buffer fixed play-out delay

21


Packet Loss

Losses occur due to- bit errors (no error correction in packet voice networks)- discarding packets at (i) intermediate nodes (ii) destination

Packet losses up to 5% are tolerable if- losses occur at random time instants- packets (=speech segments) are relatively short (~10ms)- places of lost packets are filled in


Echo

Two types of echo can deteriorate speech quality- Network echo, and- acoustic echo- if one-way delay exceeds 25ms

Network echo (impedance mismatch in PSTN hybrids)

Acoustic echo- Commonly in hands-free equipment- Loudspeakers sound reflects back to the microphone

Canceling echo is essential to maintaining high quality

22


Agenda





Discussion


Session Initiation Protocol

IETF standardized

Text-based protocol

Similar to HTTP and SMTP

Headers and MIME bodies

Request-response (bi-directional)

SIP

23


Only signaling

For session negotiation: SDP (Session Description Protocol): - media streams- codec

Different media protocols- RTP (Real-time Transport Protocol): audio, video- MSRP (message streaming protocol): IM (session mode), file

transfer- UDPTL: Fax with T.38- TCP: file sharing, whiteboard sharing, ...

SIP


UA (User Agents)- Softphones, Hardphones- Application Servers- SIP Servers

- SIP Proxy- SIP Registrar- SIP Redirect Server

- Gateways

} often one piece of software

SIP

24


UA (User Agents)- User Agent Client (UAC)

- Sends Requests- Receives Responses

- User Agent Server (UAS)- Receives Request- Sends Response

every user agent consists of a UA client AND a UA server

SIP


SIP User Agents - Software

X-Lite: eyeBeam

25


INVITE

100 trying180 ringing

200 OK

ACK

Direct Call


Wireshark

26


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-;rportMax-Forwards: 70Contact: To: "8000"From: joe";tag=43684b60Call-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Type: application/sdpContent-Length: 233

v=0o=0 2 IN IP4 10.10.0.51s=CounterPath eyeBeam 1.5c=IN IP4 10.10.0.51t=0 0m=audio 12732 RTP/AVP 0 101a=fmtp:101 0-15a=rtpmap:101 telephone-event/8000a=sendrecv

SIP Request


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-;rportMax-Forwards: 70Contact: To: "8000"From: "joe";tag=43684b60Call-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Type: application/sdpContent-Length: 233

v=0o=joe 0 2 IN IP4 10.10.0.51s=CounterPath eyeBeam 1.5c=IN IP4 10.10.0.51t=0 0m=audio 12732 RTP/AVP 0 101a=fmtp:101 0-15a=rtpmap:101 telephone-event/8000a=sendrecv

request line: method and target

SIP Request

27


INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-;rportMax-Forwards: 70Contact: To: "8000"From: "joe";tag=43684b60Call-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Type: application/sdpContent-Length: 233

v=0o=- 0 2 IN IP4 10.10.0.51s=CounterPath eyeBeam 1.5c=IN IP4 10.10.0.51t=0 0m=audio 12732 RTP/AVP 0 101a=fmtp:101 0-15a=rtpmap:101 telephone-event/8000a=sendrecv

message headers

CRLF

SIP Request


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-;rportMax-Forwards: 70Contact: To: "8000"From: "joe";tag=43684b60Call-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Type: application/sdpContent-Length: 233

v=0o=- 0 2 IN IP4 10.10.0.51s=CounterPath eyeBeam 1.5c=IN IP4 10.10.0.51t=0 0m=audio 12732 RTP/AVP 0 101a=fmtp:101 0-15a=rtpmap:101 telephone-event/8000a=sendrecv

MIME body (optional)

SIP Request

28


INVITE: set up a session CANCEL: cancel the session setup ACK: acknowledge the response (the only request without response) BYE: terminate a session

REGISTER: SIP client registers to the SIP proxy

SUBSCRIBE, NOTIFY, PUBLISH: presence

MESSAGE: instant messaging

REFER: call transfer

OPTIONS: SIP Ping INFO: DTMF, SS7 tunneling UPDATE: update pending INVITE transaction

SIP Request


1 request

0..n provisional responses (1xx) 1 final response

- 2xx: Success- 3xx: Redirect- 4xx: Client Error- 5xx: Server Error- 6xx: Global Failure

SIP Response

29


SIP/2.0 200 OKVia: SIP/2.0/UDP 10.10.0.51:60178;received=1.2.3.4;branch=z9hG4bK-d8754z-Record-Route: From: "joe";tag=43684b60To: "8000";tag=as6769381dCall-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEUser-Agent: Asterisk PBXAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFERContact: Content-Type: application/sdpContent-Length: 289

v=0o=root 9239 9239 IN IP4 1.2.32.164s=sessionc=IN IP4 1.2.32.163t=0 0m=audio 37298 RTP/AVP 0 8 3 101a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16

SIP Response




status line: status code and reason phrase

SIP Response

30




message headers

CRLF

SIP Response




MIME body (optional)

SIP Response

31


URI- sip:[email protected] sip:[email protected]:6060;transport=TLS- sips:[email protected] tel:+431505641636 (hardly supported)- sip:1.2.3.4- foobar:/anyuriformat.com

Request URI (target), From URI, To URI Address-of-Record (AoR): public SIP URI

SIP Addressing


A SIP transaction consists of- 1 request- 0..x provisional responses- 1 final response- one exception: ACK after INVITE-200 (no response)

UAC UAS

request

response

SIP Transaction

32


INVITE

100 trying

200 OK

180 ringing

audio, video ...

BYE

200 OK

SIP Client:Caller, A-party

SIP Client:Callee, B-party

ACK

works only if clients have a static IP address

UAC

UAS

UAS

UAC

Direct Call Setup


UAC

UAS

UAS

UAC

INVITE

100 trying

200 OK

180 ringing

audio, video ...

BYE

200 OK

ACK

messages

dialog (call)

transactionsout-of-dialog transaction

in-dialog transactions

Message, Transaction, Dialog

messages

33


stateless- receive, react, forget- fast- easy HA-setups

transaction stateful- stateful during a single transaction- can handle retransmissions- request forking- memory for current transactions

dialog stateful- slowest- best security- memory for current dialog

INVITE

100 trying

200 OK

180 ringing

BYE

200 OK

ACK

Stateless vs. stateful Proxies


SIP registration

The SIP client registers to the SIP proxy

Address for relaying incoming requests is announcedin Contact header

Registration has a timeout (Expires) Multiple contacts are supported

34


REGISTER sip:example.com SIP/2.0

Via: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-

To: "joe"From: "joe";tag=4521db7bCall-ID: MjJhYjkyNmQ3Y2YyMzQ2MDA5YjllYjcxOGY2MGM4ZjM.CSeq: 108 REGISTER

Contact: Expires: 120

SIP URI of SIP registrar SIP AoR which should be registered

party which performs the registration, may differ during 3rd party registration

contact address where the user can be reached

lifetime of registration (seconds)

SIP REGISTER Request


SIP REGISTER Response

lifetime of registrationsregistered contacts

SIP/2.0 200 OKVia: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-To: "joe";tag=89c3783From: "joe";tag=4521db7bCall-ID: MjJhYjkyNmQ3Y2YyMzQ2MDA5YjllYjcxOGY2MGM4ZjM.CSeq: 108 REGISTERContact: ;expires=2418Contact: ;expires=120

35


registration

de-registration of a single contact

de-registration of all contacts

retrieve registration details

REGISTER sip:example.com SIP/2.0Contact: Expires: 120

REGISTER sip:example.com SIP/2.0Contact: Expires: 0

REGISTER sip:example.com SIP/2.0Contact: *Expires: 0

REGISTER sip:example.com SIP/2.0

REGISTER Variants


INVITE sip:[email protected]

Caller CalleeProxy REGISTER sip:enum.atTo: sip:[email protected]: sip:[email protected]

200 OK

INVITE sip:[email protected]

store contact in DB

user | location--------------+--------------

[email protected] | [email protected]@enum.at | [email protected] fetch contact from DB

Registration Storage and Lookup

36


Caller Callee

works also with mobile clients further requests can bypass proxy

Proxy

REGISTER

200 OK

INVITE


200 OK

INVITE

100 trying

180 ringing

200 OK

ACK

Intra-domain Call Setup


alice@atlanta bob@biloxy

REGISTER sip:biloxyTo: sip:bob@biloxyContact: sip:[email protected]

200 OKINVITE sip:bob@biloxyFrom: sip:alice@atlantaTo: sip:bob@biloxy

atlanta proxy biloxy proxy

INVITE sip:bob@biloxyFrom: sip:alice@atlantaTo: sip:bob@biloxy INVITE sip:[email protected]

From: sip:alice@atlantaTo: sip:bob@biloxy

domain biloxydomain atlanta

Interdomain Call Setup

37


Caller Callee

REGISTER

200 OK

INVITE


200 OK

INVITE

100 trying

ACK

Proxy A Proxy B

INVITE

100 trying

180 ringing

200 OK

180 ringing

200 OK

Interdomain Call Setup


SIP URI: sip:[email protected]. NAPTR: find preferred protocol2. SRV: found hostname+port for protocol3. A/AAAA: found IP address of host

biloxy.com. NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.biloxy.com.

biloxy.com. NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.biloxy.com.

biloxy.com. NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.biloxy.com.

_sips._tcp.biloxy.com. SRV 0 0 6061 sip-tls.biloxy.com.

_sip._tcp.biloxy.com. SRV 0 0 6060 sip.biloxy.com.

_sip._udp.biloxy.com. SRV 0 0 6060 sip.biloxy.com.

sip.biloxy.com. A 1.2.3.4

sip.biloxy.com. AAAA 2001:500:2f::f

sip-tls.biloxy.com. A 5.6.7.8

Locating SIP Servers

38


SIP proxy wants to relay also in-dialog messages

useful for NAT traversal, accounting, security

the proxy adds Record-Route header to the dialog-creating request

the UAC adds Route header to in-dialog requests

Record Routing


Caller CalleeProxy

INVITE

200 OK

INVITE

200 OKACK

BYE

200 OK

Dialog without Record-Routing

39


Caller CalleeProxy

INVITE

200 OK

INVITE

200 OKACK

BYE

200 OK

ACK

BYE

200 OK

Dialog with Record-Routing


78

Caller CalleeProxy

INVITEINVITE

INVITE sip:[email protected]:5061 SIP/2.0Record-Route: Via: SIP/2.0/UDP 1.2.32.160;branch=z9hG4bKd7f3.57f78a55.0Via: SIP/2.0/UDP 1.2.33.3;branch=z9hG4bK-d8754z-;rport=60178Max-Forwards: 69Contact: To: "8000"From: "joe";tag=43684b60Call-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Type: application/sdpContent-Length: 236

Record-Routing Details

40


SIP/2.0 200 OKVia: SIP/2.0/UDP 1.2.32.160;branch=z9hG4bKd7f3.57f78a55.0Via: SIP/2.0/UDP 1.2.33.3;branch=z9hG4bK-d8754z-Record-Route: From: "joe";tag=43684b60To: "8000";tag=as6769381dCall-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFERContact: Content-Type: application/sdpContent-Length: 289

200 OK200 OK

Caller CalleeProxy



BYE sip:[email protected]:5061 SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:60178;branch=z9hG4bK-d8754z-;rportMax-Forwards: 70Route: Contact: To: "8000";tag=as6769381dFrom: "joe";tag=43684b60Call-ID: Y2FkNzhiMDA2ZDc3OGIyZGU1MGQ2ZTZiN2YyMjk3ZmM.CSeq: 3 BYEContent-Length: 0

BYEBYE

Caller CalleeProxy


41


Main headers have long and compact representation, which are identical

Case insensitive- To: = t: = to: = tO:- From: = f: = frOM: = FROM:

More Important Header Fields


INVITE sip:[email protected] SIP/2.0 Request URI (R-URI, RURI) Address of the target

Out-of-dialog request: - public SIP AoR, e.g: sip:[email protected] should be identical to To-URI

In-dialog-request- specific address of the other party, e.g: sip:[email protected]:7765;transport=udp

Not only SIP URIs- tel:+431234567

Request URI is used for routing !!!

Request Line

42


To: Joe";tag=as6c24a3d2

Specifies the desired "logical" recipient - display name

- optional- to-uri

- required- to-tag

- header parameter- generated by UAS (callee)- needed for dialog matching- local tag vs. remote tag

this URI MUST NOT be used for routing !!!

To: Header


From: Johnny";tag=7c755807 Indicates the logical identity of the initiator of the request

- display name- optional (often untrusted/unscreened)- often used by UAS to signal incoming calls to user

- from-uri- required

- from-tag- header parameter- generated by UAC (caller)- needed for dialog matching

From: Header

43


Call-ID: NmYyNzBhODk2ZGNhZGYyNTkTUxZmExNjkCall-ID: [email protected]

Unique identifier to group together a series of messages- often contains the local IP address of the client- in-dialog requests MUST have the same call-id- re-registrations SHOULD have the same call-id

Call-ID: Header


CSeq: Header

CSeq: 2 INVITE

Serves as a way to identify and order transactions- sequence number and a method - sequence number strictly increasing- same sequence number and method identifies retransmissions- local CSeq and remote CSeq

44


Max-Forwards: 69

The number of hops a request can transit- decremented by one at each hop- if value reaches 0 before the request reaches its destination:

483 Too Many Hops- may be reset at gateways and B2BUA

Max-Forwards: Header


Via: SIP/2.0/UDP 83.136.32.160;branch=z9hG4bK101b.b.0

Indicates the transport used for the transaction and identifies the location where the response is to be sent

- protocol used for request/response- socket for receiving the response- branch parameter to identify transactions

Via: Header

45


Contact: Header

Contact:

SIP(S) URI that can be used to contact that specific instance of the UA for subsequent requests.

- often contains username (privacy!)


Record-Route:

SIP(S) URI to which in-dialog requests should be sent too - optional- inserted in out-of-dialog request- lr parameter indicates loose-routing as specified in RFC 3261 (in

contrast to strict-routing according to RFC 2543)- RR URI-parameters often be used by stateless elements as cookie

(insecure!)

Record-Route: Header

46


Route: Header

Route:

SIP(S) URI that addresses an intermediate hop (proxy)- 1:1 copy of Record-Route header- all route URIs define the route set- usually only in in-dialog-requests- when present in out-of-dialog request: pre-loaded route set


Remote-Party-ID: ;party=calling;id-type=subscriber;screen=yes

P-Asserted-Identity: joe bow" P-Asserted-Identity: tel:+431234567

Privacy: id

Used to signal asserted identities to trusted nodes- RPID: old, obsolete draft but still often used (Cisco 5300 gateways)- PAI: for IMS, but also used by many SIP/PSTN gateways- screening indicater, Privacy header: CLIR

P-Asserted-Identity, Privacy, Remote-Party-ID: Header

47


Request URI- current target

Via- used for response routing

Record-Route- indicate intermediate hops to clients

Route- client indicates intermediate hops

Contact- address of a specific user agent

Routing Headers Comparison


SIP does not provide services

SIP is a protocol which provides building blocks

An application can use these building blocks to build services/features

Building blocks: the request methods (INVITE, BYE )

SIP Architecture

48


SIP Services: Example 1

A voice call- INVITE- ACK- BYE

Put a call on hold- INVITE (reINVITE)


SIP services: Example 2

Transfer a call- REFER- BYE

SIP does not define the transfer, but defined methods which can be used to implement a call transfer

49


Call Transfer 1

A CB

INVITE200 OK

ACK

200 OK

REFERRefer-To: C

BYE200 OK

A calls B B transfer A to C

INVITE200 OK

ACK


Call Transfer 2

A CB

INVITE200 OK

ACK

200 OK

REFERRefer-To: A

BYE200 OK

A calls B B transfer A to C

INVITE200 OK

ACK

50


SIP Services: Example 3

Presence- SUBSCRIBE- NOTIFY- PUBLISH

But above methods can also be used for other features (e.g. indication if a call transfer was successful, message waiting indication)


SIP Proxy vs. SIP B2BUA

SIP Proxy- is just a proxy forwards SIP messages- no body manipulation- adds/removes certain headers- changes request URI (retargeting)

B2BUA (back to back user agent)- two SIP user agents mounted back-to-back- does not forward requests, but terminates incoming call and creates a

second (outgoing) call

51


SIP Proxy vs. SIP B2BUA


SIP Forking (branches) request gets forwarded to multiple targets

parallel forking

sequential forking

transaction has multiple branches

52


Parallel Forking

Caller Target 2

INVITE

INVITE

Proxy Target 1

INVITE

branch 2

branch 1


Sequential Forking

Caller Target 2

INVITE

INVITE

Proxy Target 1

INVITE

408 Timeout, 603 Declined, 486 Busy Here, ...

branch 2

branch 1

53


SIP is independent of the used transport protocol

From SIPit 20 summary:Implementations using each transport for SIP messages:

- UDP 100%- TCP 82%- TLS 46% (server auth only)- TLS 24% (server or mutual auth)- SCTP 7%- DTLS 0%

NAPTR/SRV lookups for protocol detection

Proxies will do protocol conversion

SIP Transport Protocols


user-to-user

user-to-proxy

proxy-to-proxy

Authentication

user A proxy A proxy B user B



54


Authentication

SIP level: HTTP digest authentication- UAC authenticates to a UAS

Transport layer: TLS, DTLS (datagram transport)- hop-by-hop- authenticates TLS server to TLS client or mutual

IP layer:- IPsec

- transparent to SIP application- hop-by-hop- mutual authentication

- IP based authentication- hop-by-hop- dangerous with UDP (can be easily spoofed)- either in application or firewall


SIP using HTTP authentication

mostly used in a user-to-homeproxy authentication scenario

challenge response method


Caller CalleeProxy

INVITE

INVITE w/o credentials

ACKINVITE with credentials

407

55


HTTP Digest Authentication

1. INVITE

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:14838;branch=z9hG4bK-d8754z-...

2. request authentication

SIP/2.0 407 Proxy Authentication RequiredVia: SIP/2.0/UDP 10.10.0.51:14838;branch=z9hG4bK-d8754z-Proxy-Authenticate: Digest realm="example.com",

nonce="470f1e0a1d9db141898a0c2d98e167ce1c9be785"

...


HTTP Digest authentication

3. INVITE with credentials

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:14838;branch=z9hG4bK--d8754z-Proxy-Authorization: Digest

username="joe.bow",realm="example.com",nonce="470f1e0a1d9db141898a0c2d98e167ce1c9be785",uri="sip:[email protected]",response="52281571a1badee79a51f0875aa5f660",algorithm=MD5

...

56


HTTP authentication against multiple proxies/clients

Hardly used


Chained HTTP Digest Authentication


Caller Callee

INVITE

INVITE w/o cred.

407

Proxy A Proxy B

INVITE

407

INVITE + cred. 1

407

INVITE + cred. 2

401

INVITE + cred. 1+2

401401

INVITE + cred. 3INVITE + cred. 2+3INVITE + cred. 1+2+3


57


Different authenticating parties? realm

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 10.10.0.51:14838;branch=z9hG4bK--d8754z-Proxy-Authorization: Digest

username="joe.bow",realm=proxy1",nonce="470f1e0a1d9db141898a0c2d98e167ce1c9be785",uri="sip:[email protected]",response="52281571a1badee79a51f0875aa5f660",algorithm=MD5

Proxy-Authorization: Digest username=darilionk",realm=proxy2",nonce=asdf34gdras5fdfs",uri="sip:[email protected]",response="a51f0875aa5f66052281571a1badee79",algorithm=MD5

...

Usually the domain is used as realm too, but can be any string



SIP AoR username may be different than authentication username

INVITE sip:[email protected] SIP/2.0From: "joe";tag=7c755807Proxy-Authorization: Digest

username=joeb",realm="example.com",nonce="470f1e0a1d9db141898a0c2d98e167ce1c9be785",uri="sip:[email protected]",response="52281571a1badee79a51f0875aa5f660",algorithm=MD5

Useful to have multiple SIP URIs but only 1 username/password:

joeb/password sip:[email protected] sip:[email protected] sip:[email protected]

HTTP Authentication Characteristics

58


Proxy-Proxy Authentication

Authentication on IP address

Authentication with TLS and certificates

Authentication with IPsec

No authentication at all (SMTP style)


Agenda





Discussion

59


VoIP Initiatives

3020IP, COMSYS, Gate-X

Frequentis IP Interface

Working Positions (iPos, PC Disp.)

VCS

IP

ServerIP

Native IP

VCS Access

IP

VCS

VCS

VCS

Networking


Services

Networked environments allow services being located at almost any place

- Host processing power- Network infrastructure

Example: Radio site is able to connect 2 clients extension to 3 and more clients

60


Radio Service Elements

Service entities to describe ATC radio services


Radio Communication Relations

61


Service Sessions

Client has a configuration file containing SIP URIs describing services needed by the application (1)

The session setup (2) establishes a number of service specific data trunks (e.g. UDP for keep-alive check, UDP/RTP for audio transmission and TCP for data transfer) (3)


Session Setup Example (SDP only)

m=audio 10500 RTP/AVP 0 8m=application 32456 udp heartbeata=timeout:200m=application 43210 TCP met-data c=IN IP4 192.0.2.1a=setup:passivea=connection:newa=encoding:XML

Service interface definition (SIP, SDP and RTP content) for G/G and A/G communication

- FRQ EUROCAE WG67 activities

62


Gate-X

1 HU 19 chassis (media gateway)- low delay (17ms; 10ms audio packet, 2ms jitter buffer)- 622Mbit/s fiber expansion port (stackable)- powerful signal processing capabilities- integrated 22 port Fast Ethernet- integrated 8E1/T1 (G.703) ports- standard RTP/RTCP and SIP- redundant power supply

Other applications- radio site/base station equipment- IP conf./phone/radio server- TDM/IP gateway

IP

VCS

VCS

RadioSiteWorkingPosition

Radio


Gate-X - Features

Standardized signaling- RTP/RTCP- SIP

In-packet radio signaling (RTP header extension)- RFC 3550- 8 Byte per packet (4 Byte header + 4 Byte information)- RTP Payload Type

QoS-DiffServ (use of DSCP and optimized processing)- internal audio processing

63


VCXi / iRIF

Very low internal latency based on fast packet engines and streamlined voice stream paths

Enhancement of legacy systems by features provided by the Frequentis iRIF-gateway

Future-proof design according EUROCAE Working Group 67 outcomes, EU-Interoperability Regulation 552 and expected SESAR design constraints

Two 4/6/8-wire interfaces for radio equipment or MFC

RS232/RS485 (9.6 -115.2 KBit/s) interfaces for remote control 100 MBit/s Fast Ethernet, full duplex

Digital I/O


SIP PC Dispatcher Basic Architecture

PC Dispatcher Server

CAD.NET

Tetra Protocol Module

PC Dispatcher

COI Protocol Module

COI Server

Frequentis VCS

TCP/IP

TAL

Digital Radio

COM

Tetra Protocol Module

http

I/O Protocol Module

SIP TSPCOM

TAPI Protocol Module

SIP

VoIP

(GUI) Client

64


SIP Trunk (3rd party integration)


ISDN E1 (3rd party integration)

65


WAN Gateway (Firecontrol)


WSA Bremen

66


Deployable CRC


EUROCAE WG-67

Konstituierung: 03. 03. 2004

Ziele (bis 2006!):- Analyse: operationelle Anforderungen, Standards, Servicequalitt, - G/G und A/G Kommunikation: Definition von Komponenten (VCS, GRS ),

Interoperabilitt zwischen diesen Komponenten

Teilnehmer (Wunschliste):- ANSPs, ATM Industrie, RTCA, ICAO, Eurocontrol, ITU, ETSI

Vienna Agreement: 13. 09. 2004 (Meeting #4) Plugtest #1: 14. 04. bis 18. 04. 2008

Akzeptierte Dokumente: 02/2009 (EUROCAE Approved) Plugtest #2: 30. 3. bis 03. 04. 2009

Plugtest #3: 09/2009 SIP/MFC, SIP/ATS-QSIG Gateways

67


Arbeitsgrundlage


Bedeutung des WG-67 Resultats

WG-67 definiert keine Architektur sondern legt Anforderungen fest, identifiziert Komponenten und harmonisiert deren Schnittstellen

- VCS- Radio (Funkgert oder Gateway zum Funkgert)- Recorder (aktives Recording)- Gateways (MFC, ATS-QSIG)

Interpretationsspielraum innerhalb der Komponentendefinition- Das Vienna Agreement beschreibt eindeutige Schnittstellen - Bedingt durch die heterogene Gruppe und den Wunsch einiger ANSPs ein

VoIP VCS zu definieren entstanden verschiedene Ansichten

Es bleiben Definitionslcken - Zwanghafter Abschluss der Dokumente Ende 2008- Mangelhafte Beitrge (auch aus strategischen Grnden)

68


WG-67 Definitionslcken

Syntax und vor allem Semantik der Schnittstellenbeschreibung- Keine klaren Aussagen zu bestimmten (von bestehenden Standards

abweichenden) Parametern (hoher Interpretationsspielraum)- Keine Definitionen fr Fehlerflle (etwa Verbindungsabbruch)- Keine eindeutige Aufgabenverteilung speziell bei A/G Kommunikation

zwischen Komponenten (wer legt Parameter fest)

NICHT als Designdokument anwendbar- Vorteil fr die Industrie Schutz vor newbies am Markt und USPs fr

Hersteller (durch besseres Verstndnis der Inhalte)- Allgemein gibt es wenig WG-67 Know-how trger (im wesentlichen die

Autoren selbst) - Hoher Testaufwand (pre-plugtests ) notwendig

Komplexe Fhigkeiten (Radiofeatures) sind nicht beschrieben- Erfordert die Definition einer Architektur!


Eurocae Dokumente (1) - verffentlicht ED-136 Operational and Technical Requirements

- Eurocontrol, ANSPs, tlw. Industrie- (+) gemeinsame Initiative europische ATC Anforderungen zu finden- (-) daraus wurde beinahe ein VoIP basiertes VCS

ED-137-1 Interoperability Standards / Radio- Industrie (VCS, Radio)

- (+) einheitliche Schnittstelle zwischen VCS und Radio (lckenhaft)- (-) keine konsolidierten Inhalte (zwanghafter Abschluss)

ED-137-2 Interoperability Standards / Telephony- ANSPs, Industrie (VCS)

- (+) einheitliche Schnittstelle zwischen VCS A und VCS B (fast vollstndig)

- (-) viele Referenzen auf bestehende RFCs, trotzdem offene Punkte

69


Eurocae Dokumente (2) - verffentlicht ED-137-3 Interoperability Standards / Recording

- Industrie (VCS, Recorder: ATIS UHER)- (+) gute Dokumentation einer Architektur fr aktives Recording- (-) geringe Wertschtzung des Themas innerhalb WG-67

ED-137-4 Interoperability Standards / Supervision- Industrie (VCS, Radio)

- (-) mangelhaftes Dokument (beschreibt OIDs fr Komponenten) - (-) geringe Wertschtzung des Themas innerhalb WG-67

ED-138 Network Design Guide / Network Specification- ANSPs, tlw. Industrie (CISCO!)

- (+) Themen wie Servicequalitt und Sicherheit werden angesprochen- (-) Tutorialcharakter, keine klaren Aussagen sondern Optionen


WG-67 Zukunft

Folgemeeting am 21. 4. 2009- nderungsvorschlge, Rckmeldungen vom Plugtest im Mrz, weitere

Vorgangsweise- Fortschritte bei ED-139 (Qualification Tests)- Field-trial Aktivitten in Europa (DFS, DSNA, FRQ)

Eine allgemeine berarbeitung der EDs ist notwendig- Schon whrend des Implementierens wurden Schwchen erkannt- Tests 2009 (Mrz, September) werden weitere Diskussionen starten- Ein bestimmter Qualittsstandard ist erforderlich um den ICAO Ansprchen

zu gengen (siehe auch Reviewkommentare von Eurocontrol)

Es besteht der allgemeine Wunsch das Thema innerhalb SJU weiter zu verfolgen

70


Frequentis, WG-67 und Plugtests

Internes Ziel 2004: - WG-67 Mitarbeit mit dem Ziel die inhaltliche Gestaltung der Dokumente nach

unseren zuknftigen Architekturen zu beeinflussen, ohne dabei FRQ USPszu verffentlichen. Inhalte sind:

- die Darstellung eines Pradigmenwechsel weg von Plattformen und hin zu Serviceentitten und deren Schnittstellen

- fr Schnittstellen, einfach betrachtet, die Anwendung von SIP und der gemeinsame Transport von Sprachdaten und PTT durch RTP

Interner Status 2009:- Wir verwenden SIP (comsys, isecom, dcrc, iccs ) und RTP mit PTT- Der Paradigmenwechsel ist innerhalb von WG-67 und innerhalb von FRQ

nicht bzw. noch nicht vollstndig gelungen- Es ist leider innerhalb FRQ nicht mglich auf eine sich stetig weiter

entwickelnde Basissoftware zurckzugreifen- Neuentwicklung fr Plugtests 2008- Neuentwicklung fr Plugtests 2009 ...

- FRQ prsentiert einzelne Komponenten (Prototypen) und kein Produkt


Frequentis, WG-67 und Field Trials

DSNA, DFS testet mit FRQ und vier Radioherstellern VoIP im Weitverkehrsnetz

- DSNA Entscheidungsgrundlage fr zuknftige Ausschreibungen- Hohes ffentliches Interesse (Eurocontol Workshop, WG-67 )- Chancen fr FRQ

- erster Nachweis von VoIP Technologie im operationellen Umfeld mit unseren besten Kunden

- Verstndnis der Auswirkungen von cross-border Kommunikation- Risiken fr FRQ

- Misserfolg hat weitreichende Auswirkungen die nicht allen innerhalb FRQ bewusst sind

- Eingeschrnktes Budget (FRQ als Partner und nicht als Lieferant) erhht das Risiko eines Misserfolges

Komponenten sind nicht Teil des Plugtest #2, der Kunde erwartet jedoch uneingeschrnkte Kompatibilitt

71


Agenda





Discussion

voip_training_2009_14_07

Documents

frq page

tcp features

tcp header format frequentis

payload tcp

dns4 frequentis

tcp error detection

connection closing tcp

web server tcp