voice over internet protocol and internet telephony - aalto file1 tik-110.350 tietoverkot /...
TRANSCRIPT
1 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Voice over Internet Protocol andInternet Telephony
Pekka PessiNetworking Technologies Laboratory
Nokia Research Center
2 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Contents
• RTP/RTCP, Packetizing voice and video, codecs
• Voice over IP
• Codec features
• Wireless
• QoS
• Internet Telephony:
• H.323
• SIP and SDP
• ENUM, TRIP, CPL, etc.
• Media Streaming, RTSP
3 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTP - Real-Time Transport Protocol
• RTP/RTCP specified in RFC 3550 (Internet Standard 64)• Provides means for application to restore packet sequence and
timing:• sequence number, timestamp, source identifier
• Runs on top of any transport protocol• UDP, TCP, AAL5• "Real-time" does not mean "fast"
• Lightweight, designed according ALF, ILP• Application integrated with RTP implementation
• Designed for multicast• "unicast is special case of multicast"
4 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTP Packet
V P X CC M PT Sequence numberTimestamp
Synchronization Source Identifier (SSRC)
Contributing Source Identifiers (CSRC)
Extension Identifier Extension Length
RTP Header Extension
RTP Payload
Pad lengthPad
If X ≠ 0
If P ≠ 0
If CC ≠ 0
12 bytes
5 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Putting Speech into Packets
Sender:
• A/D conversion
• Collecting samples into a frame
• Coding or compressing frame
• Sending frame(s) within a packet
Receiver:
• Reordering and synchronizing packets
• Decoding or decompressing frames
• D/A conversion
F r a m e F r a m e
A
t S a m p l i n g
Qua
ntiz
atio
n
6 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Video in Packets
• Video is stream of pictures
• Picture divided into blocks
• Blocks encoded using discrete cosine transform (like JPEG)
• INTRA/INTER mode:
• INTRA mode: encodecomplete picture
• INTER mode: encode differences between pictures
• Motion prediction
81 01 2
79
1 1
246
135
1
3 3
2 3 4 5 6 7 8 9 1 0 1 1
1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2
2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1 3 2
Time
P i c t u r e
G O B
M a c r o b l o c k
L u m i n a n c e b l o c k s
C o l o u r b l o c k s
7 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTP in Action
0 10 1 0
0 20 3 0
0 30 7 0
0 40 9 0
0 51 1 0
0 61 3 0
0 71 5 0
0 10 1 0
0 20 3 0
0 30 7 0
0 40 9 0
0 51 1 0
0 61 3 0
0 71 5 0
S E QT S
R e c e i v e r
S e n d e r01
0
030
050
070
090
110
130
150
010
030
050
070
090
110
130
150
170
190
S E QT S
8 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTCP - Real-Time Control Protocol
• Designed for loosely coupled multimedia multicast session• Packet types: SR, RR, SDES, BYE, APP • SR: Sender report, RR: receiver report
• Means for congestion control, calculating packet loss, jitter• Synchronization between streams
• SDES: Source description• BYE: Participant is departing conference• APP: Application-specific packets• Extended packet types:
• RTPFB, PSFB (feedback)• XR (more detailed receiver reports, RFC 3611)
9 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTP Profiles
• RTP profile defines guidelines for• timestamp rate, packetization, marker bit usage• extensions to RTP header
• STD 0065 - RFC 3551 - RTP Profile for Audio and Video Conferences with Minimal Control (“RTP/AVP”)
• Audio profile, video profile
• Contains packetization for many codecs:PCMA (G.711A), PCMU (G.711µ), GSM (GSM 06.10 FR), G.729, G.723, ADPCM (G.726), L8, L16, DVI4, G.722, G.728, H.261, nv
10 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Audio Profile for RTP • M bit is used to mark start of speech burst
• Sampling frequency used as timestamp frequency
• Timestamp indicates sampling time of oldest sample
• Frame-based codec guidelines:
• 1..N speech frames in each RTP packet
• frames typically octet padded, concatenated
• frames from all channels consecutive, fixed order, all channels in same packet
11 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Video Profile for RTP• M bit indicates last RTP packet in frame
• 90 kHz timestamp frequency
• nice multiple of 25 Hz, 24 Hz, 29.97 Hz, 30 Hz
• mainly because simple frame/field rate is insufficient for RTCP jitter calculation
• Frame can be split into multiple RTP packets
• All packets have same timestamp, different sequence number
• Some audio codecs may use video profile (MPA or MPEG audio)
12 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SRTP - Secure RTP Profile• Usual Internet security protocols unusable with RTP
• TLS did not work with UDP
• IPSec prevents header compression, no unequal error protection, uses block ciphers (bit errors spread)
• Solution: SRTP (RFC 3711)
• Confidentiality, authentication, replay protection for RTP/RTCP
• Defined as a special RTP profile
• Stream cipher for payload only• keystream generated by AES in counter mode, or f8 mode
• Optional authentication with HMAC-SHA1
13 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTP Summary
• RTP solves some problems of real-time media transport
• Restoring timing, reordering
• RTP designed for multicast
• RTP does not address
• QoS (packet loss, delay, network congestion)
14 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
RTP Applications: VoIP
15 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Two Kinds of Real-Time Multimedia
• Conversational ~ VoIP ~ SIP• Telephony• Delay is critical• HiFi quality is not important
(3.4 kHz speech, 300 b/w pixels in video)
• Unidirectional ~ Streaming ~ RTSP• Radio, television• Delay is not important
(can be up to ~5 seconds, even more in multicast)• Emphasis on media quality (compared to CD, HDTV)
16 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Why to Use IP with Voice?
• Reduce overhead• Speech coding (compression)• Silence compression
• Utilize common network technology• No more special network/connection for voice or multimedia
• Enable new kind of services• Multimedia, multicast, integrating with Internet services• High-quality voice
• Optimize rout(e)ing• Media is not tied to signaling path
17 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Factors in End-to-End Quality of VoIP
• Voice codecs (2 kb/s ... 1500 kb/s)• Speech and audio codecs• Different algorithms:
• PCM, ADPCM, RP-LPT, LELP, CELP, jne.• Lower bitrate
=> lower speech quality, more MIPS, longer delay• Delay (conversational: ...140 ms … 400 ms)
• algorithmic, coding, packetization• network• synchronization, decoding
• Packet erasure rate (...2% … 20 %)• lost in network or dropped due to excessive delay
18 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Voice Codec is Always Compromise• Low bitrate v. low complexity
• Audio quality v. low bitrate
• Packet loss sensitivity v. delay and low bitrate
• Delay v. packet loss
• Delay v. header overhead
• Few codecs designed with Internet in mind:
• ILBC
• AMR (3GPP)
19 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Header Overhead
A M R1 0 . 2
1 1 . 2 2 8
R T P
1 6 . 0
1 2
U D P
1 9 . 2
8
I P
2 7 . 2
2 0
P P P
2 8 . 8
4
• RTP payload headers,RTP/UDP/IP/LL headers
• Example 1: AMR 10.2 kb/s mode on PPP• 50 frames/s, 25.5 octets/frame• RTP payload headers 2.5 octets,
RTP 12, UDP 8, IP 20, PPP 4-5• Total bandwidth: 28.8 kb/s
• Example 2: G.723.1 5.6 kb/s over ADSL
• 30 ms/frame, 21 octets/frameRTP 12, UDP 8, IP 20, Ethernet 14,SNAP 10, AAL-5 8, (pad 3), ATM 10
• Total bandwidth: 28.3 kb/s
20 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
… and more
• + RTP + UDP + IPSEC + Mobile IP+ IPv6 + IEEE802.3 + LLC-SNAP + AAL5+ ATM ...
• More than 80% of packet is headers
• Putting more frames in one packet• multiplies packetization delay• worsen packet loss degradation
(multiple frames lost at once)
• CRTP or ROHC reduces header overhead to 2..4 octets in the best case
• (…but not with IPSEC)
5 6 . 0
A M R1 0 . 2
R T P
U D P
I P v 6
H A o p t i o n( M o b i l e I P v 6 )
E H( I P S E C )
E t h e r n e t
1 4 0
21 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Delay Budget
• Example:AMR 12.2 codec, 2 frames in packet (speech 64, total 104 octets),64 kb/s ISDN, inter-continental link and 256 kb/s ADSL
• Algorithmic 25 ms Encoding 5 msPacketization 20 msNetwork (ISDN) 14 ms (6 ms because of headers)Network (Core) 80 ms .. 100 msNetwork (ADSL) 4 ms (3 ms because of headers)Synchronization 20 ms .. 40 msDecoding + 2 msTotal 190 ms
22 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
VoIP on Wireless Networks
• Wireless links differ from wireline• Lot of bit errors (1E-3 — 1E-4)
• Error correction codes (e.g., convolution coding) at link layer• Forward Error Correction (FEC) at application layer
• Bandwidth varies• Bad reception requires more error correction, leaving less
bandwidth for data• Solution: codecs with variable bit rates (AMR)
• Really narrowband links• Error rate causes problem for normal header compression• Solution:
RObust Header Compression (ROHC) orCompressed RTP (CRTP)
23 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
UDP Lite
• Usually in Internet, one bit error causes packet loss
• But media codecs tolerate bit errors better than packet loss
• Solution:
• UDP Lite (RFC 3828)
• Use unequal error protection, ignore some bit errors
S p e e c hR T PU D PI P
U D P L i t e C h e c k s u mC o v e r a g e
U D P C h e c k s u mC o v e r a g e
24 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
VoIP and Network Performance
• Processing, queueing, propagation delay• VoIP has large packet overhead
• "Lot of little packets full of headers"• high number of packets increase load on routers, longer
processing delay• header overhead causes relatively long propagation delay
• Real-time queueing:• by-pass long queue, use short RT-specific queue • packets may be lost already on low load• RT-load must be much lower than non-RT load
• IntServ (RSVP)• DiffServ• MPLS
25 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
VoIP Myths• VoIP saves bandwidth
• ...if you don't count header overhead
• VoIP quality is hopeless compared to PSTN
• ...only if you are happy with 3.4 kHz PSTN quality
• VoIP is useless without QoS in whole Internet
• ...in core Internet, jitter is less than 1 ms
• VoIP is free
• ...only almost
26 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Other RTP Applications
• Conferencing - SAP (RFC 2974)
• Session source multicasts SDP session description
• No negotiation - take it or leave it
• Streaming - RTSP (RFC 2326)
• Client asks server for session description
• URL addressing, HTTP-like transaction model
• Media and codec negotiation by RTSP URLs
• Multiple streams
• Firewall/NAT-friendly (RTP tunneling)
• Distributed content servers
27 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Internet Telephony
28 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Two Standards for IP Telephony
• H.323 from ITU-T
• H.323v5 approved in May 2003
• SIP from IETF
• RFC 3261 (“SIP/2.0bis”)published in June 2002
29 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
H.323 Suite from ITU-T
• Based on Q.931, H.320, H.324
• Umbrella specification: H.323, H.225.0, H.245
• "Videophone over TCP/IP LAN"
• Follows classic telephony model
• Binary encoding (Q.931, ASN.1/PER)
• Predefined services(H.450 series services, defined using X.880 RPC)
• Lot of baggage
• Designed by a committee
• Too complex (total 808 pages) but still missing features
30 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
H.323 Components
P S T N
G a t e w a yG a t e k e e p e r
T e r m i n a l s
I P
M C U
M P
M C
• Entities:terminal,gateway,gatekeeper
31 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Basic H.323 Protocol Stack
IP
UDP
RTP/RTCP
RTP/RTCP
AudioCodec
RAS
TCP
X.224 (RFC 1006)
H.245Q.931
T.122
T.120Video
Codec
H.323 Videophone Application
32 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
T.120 Multimedia Conferencing
• ITU-T protocol suite for multiparty conferencing
• Application sharing (T.128)
• Whiteboarding (T.126)
• Text chat (T.134, T.140)
• File sharing (T.127)
• Transport-independent
• Modem, ISDN, Internet (T.123)
• Uses its own multipoint servers (T.125)
• E.g., Microsoft Netmeeting, Windows Messenger
33 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP from IETF
• Based on SAP, RTSP, HTTP
• Multicast multimedia conferencing
• Original scope was inviting individuals to multicast conferences (Session Invitation Protocol)
• Evolved to set up unicast and person-to-person calls(Session Initiation Protocol)
• "HTTP over UDP"
• Base specifications in RFC3261, RFC3262, RFC3263, RFC3264
• Simple, lightweight, flexible
• RFC 3261 is largest RFC ever published, 269 pages
• Total SIP/SDP = 370 pages
34 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
...Not so Simple Anymore RFC 3261 SIPRFC 3262 100rel and PRACK methodRFC 3263 Locating SIP ServersRFC 3264 SDP Offer-Answer ModelRFC 3265 SIP Events (SUBSCRIBE/NOTIFY)RFC 2327 SDPRFC 3266 IPv6 for SDPRFC 2976 INFO methodRFC 3311 UPDATE methodRFC 3312 PreconditionsRFC 3323 Privacy extensionRFC 3325 P-Asserted-IDRFC 3326 Reason headerRFC 3327 Path extensionRFC 3329 Security AgreementRFC 3420 message/sipfragRFC 3428 MESSAGE methodRFC 3515 REFER methodRFC 3581 rport
RFC 3608 Service-Route headerRFC 3903 PUBLISHRFC 2617 Digest authenticationRFC 2782 DNS SRV, RFC 2915 NAPTRRFC 3050 CGI for SIP RFC 3320 SigCompRFC 3486 Compressing SIPRFC 3485 SIP/SDP SigComp Dictionary RFC 3840, 3841 Caller preferencesRFC 3856 SIP PresenceRFC 3859 Common Presence Profile (CPP)RFC 3863 PIDFRFC 3857, 3858 WatcherinfoRFC 3880 Call Processing Language (CPL)draft-ietf-simple-event-lists-07draft-ietf-simple-xcap-07draft-ietf-sip-session-timer-15draft-sparks-sip-nit-actions-03...
35 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP in Nutshell
• Modelled after HTTP/1.1:
• Addressing using URLs
• Plain text headers, allows very simple "miniservers"
• Transaction-based (request-response), redirections
• Authentication model
• Differences from HTTP:
• Built-in personal mobility (“rendezvous service”)
• Services implemented mostly by proxies
• Request forking, real-time requests (timeout after 32 sec)
• Transport-independent: UDP, TCP, TLS, SCTP
36 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP MessageINVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP kton.bell-tel.comFrom: A. Bell <sip:[email protected]>To: T. Watson <sip:[email protected]>Call-ID: [email protected]: 1 INVITESubject: Mr. Watson, come here.Content-Type: application/sdpContent-Length: 130
v=0o=bell 53655765 2353687637 IN IP4 128.3.4.5s=Mr. Watson, come here.c=IN IP4 kton.bell-tel.comm=audio 3456 RTP/AVP 0 3 4 5
SIP Headers
SDP MediaDescription
as SIP Payload
Request method
RequestURI
37 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Transactions
• SIP transaction consist of
• a request message sent by client to server,
• optionally followed by provisional response message from server to client, and
• a final response message from server to client
• (in case of INVITE)an ACK message from client to server
SIP ServerSIP Client
INVITE
100 Trying
180 Ringing
200 OK
ACK
38 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Requests
• Transaction requests
• INVITE - call setup (also hold, resume, transfer, ...)involves user interaction (no timeout if provisional response has been received, indefinite duration)
• BYE - call release
• OPTIONS - query UA capabilities and/or status
• REGISTER – update user contact information
• Other requests
• CANCEL - aborting (INVITE) transaction
• ACK - acknowledge final response to INVITE
39 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP and SDP
• SIP uses SDP (RFC2327) to describe sessions
• SDP is transmitted as payload of SIP call setup messages
• IP addresses, port numbers, codec types, packetization, etc., for each media
• Media negotiation with SDP Offer/Answer Model (RFC3264)
• SDP is very simple
• full implementation < 2 kLoC (H.245 is ~ 100 kLoC)
• allows selecting audio and/or video codecs
• but selecting individual codec modes is hard
• may be replaced in future with, e.g., XML-based solution
40 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Entities• SIP Entities:
• user agents
• proxies
• registrars
• redirect servers
• back-to-back user agents
41 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP User Agents
User Agent (UA)
• Consists of a client and a server
• Examples: Terminal, MCU, Gateway
• User Agent Client (UAC):• Initiates SIP transactions
(sends requests)
• User Agent Server (UAS):• Accepts SIP transactions
(receives requests and acts on them)
• Both server and client functionality required during a call!
42 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Proxies
Stateless proxy• forwards SIP messages• does not maintain transaction nor call state scalable
Stateful proxy• forwards SIP transaction - keeps transaction state• acts as server to one direction and as client to another• can fork requests: incoming SIP request may create several
virtual clients, each executing a transaction, the combined result is returned back to the original client
43 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Redirect and Registrar Servers
Redirect Server• accepts request and returns a list of addresses to the client• very simple implementation
• needs to understand two headers• scalable
• no need for transaction state• never maintains call state
Registrar Server• server accepting REGISTER transactions• updates location database• usually co-located with proxy/redirect server
44 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Back-to-Back User-Agent• SIP limits the operations a proxy can perform
• Intermediate element not behaving by proxy rules is B2BUA
• B2BUA can modify session description, authentication and identification info, etc
• Problematic because they break end-to-end connectivity and transparency
• Applications:
• Session border controller, application-level gateway, transcoder
45 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Call Example
sip.nokia.com sipgw6.nokia.com
sipgw7.nokia.com
sipgw8.nokia.com
sipgw9.nokia.
sipgw10.nokia.com
location.research.nokia.com
pc-pessi.research.nokia.compessi.koti.sonera.fi
labra-pc-18.research.nokia.com
(1) INVITE
(3) 100 Trying
(4) INVITE
(5) 302Found
(6)INVITE (6)
INVITE
(6) INV
ITE
(8) 180Ringing
(7) 480
Not available
(7) 180 Ringing
(7) 180R
ingi ng(9) 200 O
k
(10) 200 Ok
(11)ACK
(12) AC
KMEDIA
alice.wonderland.org
(10)CANCEL
(8)A
CK
46 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Instant Messaging and Presence (SIMPLE)
• Instant messages (like SMS or MMS)
• Uses MESSAGE method (RFC3428)
• MIME payload, CPIM wrapper
• Maximum size 1300 bytes
• Presence
• Uses SUBSCRIBE/NOTIFY (RFC3265) and PUBLISH (RFC 3903)
• Basic presence (CPIM) indicates if user is willing to receive instant messages
• Extensions proposed for other modes of communication, device capabilities, user activity, location, mood, future availability
47 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP Security
• Digest authentication (from HTTP)
• Based on shared secret (password or a key from SIM)
• SIPS URI scheme (just like HTTPS)
• Uses TLS (or equivalent) as transport
• Clumsy with UAs (a certificate required for all devices)
• S/MIME (from e-mail)
• End-to-end security for message payload
• Using self-certified certificates if no PKI available
• Used also to secure authentication tokens(hop-by-hop security)
48 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Locating SIP Users and Services
• SIP uses URIs for addresses:
• sip:[email protected]
• im:[email protected]
• tel:+358718036404
• URLs are mapped to IP addresses using DNS
• SIP/SIPS URIs using RFC3263 (NAPTR, SRV, AAAA/A)• Provides load balancing, transport selection,
switchover after failure
• ENUM
• Gateways to PSTN can be located with TRIP
49 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
ENUM
• Protocol for mapping telephone numbers into URLs
• Mapping based on service required
• Using DNS NAPTR
• RFC 2916
• E.g., calling to +358 71 800 8000:
• Converted to domain name0.0.0.8.0.0.8.1.7.8.5.3.e164.arpa.
• 0.8.1.7.8.5.3.e164.arpa. resolves to NAPTR 10 10 "U" "SIP+E2U" "!+(.*)!sip:+\[email protected]!” .
• Telephone number is matched to regexp, and resulting URL is used to place the call
50 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
TRIP
• Inter-domain call routing protocol
• Based on BGP
• Locates suitable destination for a telephone number
• Protocol-independent
• Supports booth H.323, SIP
• Routing based on policy
• Cost, quality, reliability, features
51 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Creating SIP Services
• SIP services can be built like WWW services
• CGI scripts, servlets, miniservers
• Services are created within SIP proxy network
• No special IN servers or protocols – SIP can always be used
• Presence-based and location-based services
• SIP-specific:
• Callee capabilities, caller preferences
• Call Processing Language (CPL)
• KPML (keypress markup language) for IVR applications
• Events (presence, call status, conference status)
52 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Callee Capabilities and Caller Preferences• Callee can specify different contacts:
• audio, video, chat, mobile, business phone, voicemail
• Caller can ask for specific services:
• video, mobile, business phone, no voicemail
• Caller can ask how a request is processed:
• proxying, redirecting, forking, recursive
53 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
CPL - Call Processing Language
• XML-based rules for processing and routing calls• Robust, safe, suitable for large-scale servers<cpl> <subaction id="voicemail"> <location url="sip:[email protected]"> <redirect /> </location> </subaction> <incoming> <location url="sip:[email protected]"> <proxy timeout="8"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <address-switch field="origin"> <address is="sip:[email protected]"> <location url="tel:+19175551212"> <proxy /> </location> </address> <otherwise><sub ref="voicemail" /></otherwise> </address-switch> </noanswer> </proxy> </location> </incoming></cpl>
54 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Problems with Internet Telephony
• No more end-to-end connectivity on Internet
• Firewalls, NATs work with client-server only
• Internet is no more suitable for peer-to-peer applications
• Solutions:• IPv6• Application-level gateways (ALGs)• STUN/TURN/ICE• UPnP
• Security models require central authority
• PKI or operator
55 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
SIP and 3G
• 3GPP release 5 and 6
• New subsystem called IMS(IP Multimedia Core Network Subsystem)
• TS 23.228, TS 24.229
• Adds network elements likeP-CSCF, I-CSCF, S-CSCF, MRCF, MRPF
• SIP Proxies, RTP media processors, etc.
• Internet multimedia calls signaled using SIP
• Messaging and Presence
• Streaming using RTSP
• 3GPP2 adopts IMS, too
56 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi
Internet Telephony
RTP RTCPAMR H.263 MPEG
RSVP UDP Lite ROHC
SIP SDPSIMPLE
ENUM URIs E1.64 DNS TRIP CPL CGI Servlets
CPIM
Presence ReachabilityInstant multimedia messaging
Push-to-talk Click-to-dial Chat-to-callMultimedia conferences
Voice and video mailboxes