Presentation on theme: "Voice over IP (VoIP) and the Session Initiation Protocol (SIP)"— Presentation transcript:
1Voice over IP (VoIP) and the Session Initiation Protocol (SIP) Huei-Wen Ferng (馮輝文)Assistant Professor, CSIE, NTUST
2Outline Introduction Streaming stored audio and video Real-time, interactive multimedia: Internet phone case studyProtocols for real-time interactive applications: RTP, RTCP, and SIPChallengesOur resultsQ & A
4MM Networking Applications Fundamental characteristics:Typically delay sensitiveend-to-end delaydelay jitterBut loss tolerant: infrequent losses cause minor glitchesAntithesis of data, which are loss intolerant but delay tolerant.Classes of MM applications:1) Streaming stored audio and video2) Streaming live audio and video3) Real-time interactive audio and videoJitter is the variabilityof packet delays withinthe same packet stream
5Streaming Stored Multimedia: What is it? streaming: at this time, clientplaying out early part of video,while server still sending laterpart of video3. video received,played out at clientCumulative data2. videosent1. videorecordednetworkdelaytime
6Streaming Live Multimedia Examples:Internet radio talk showLive sporting eventStreamingplayback bufferplayback can lag tens of seconds after transmissionstill have timing constraintInteractivityfast forward impossiblerewind, pause possible!
7Interactive, Real-Time Multimedia applications: IP telephony, video conference, distributed interactive worldsend-end delay requirements:audio: < 150 msec good, < 400 msec OKincludes application-level (packetization) and network delayshigher delays noticeable, impair interactivitysession initializationhow does callee advertise its IP address, port number, encoding algorithms?
8A few words about audio compression Analog signal sampled at constant ratetelephone: 8,000 samples/secCD music: 44,100 samples/secEach sample quantized, ie, roundedeg, 28=256 possible quantized valuesEach quantized value represented by bits8 bits for 256 valuesExample: 8,000 samples/sec, 256 quantized values --> 64,000 bpsReceiver converts it back to analog signal:some quality reductionExample ratesCD: MbpsMP3: 96, 128, 160 kbpsInternet telephony: kbps
9Streaming Stored Audio and Video VoIP & SIPStreaming Stored Audio and Video
10Streaming Stored Multimedia Application-level streaming techniques for making the best out of best effort service:client side bufferinguse of UDP versus TCPmultiple encodings of multimediaMedia Playerjitter removaldecompressionerror concealmentgraphical user interface w/ controls for interactivity
11Internet multimedia: simplest approach audio or video stored in filefiles transferred as HTTP objectreceived in entirety at clientthen passed to playeraudio, video not streamed:no, “pipelining,” long delays until playout!
12Internet multimedia: streaming approach browser GETs metafilebrowser launches player, passing metafileplayer contacts serverserver streams audio/video to player
13Streaming from a streaming server This architecture allows for non-HTTP protocol between server and media playerCan also use UDP instead of TCP.
15User Control of Streaming Media: RTSP HTTPDoes not target multimedia contentNo commands for fast forward, etc.RTSP: RFC 2326Client-server application layer protocol.For user to control display: rewind, fast forward, pause, resume, repositioning, etc…What it doesn’t do:does not define how audio/video is encapsulated for streaming over networkdoes not restrict how streamed media is transported; it can be transported over UDP or TCPdoes not specify how the media player buffers audio/video
16RTSP: out of band control FTP uses an “out-of-band” control channel:A file is transferred over one TCP connection.Control information (directory changes, file deletion, file renaming, etc.) is sent over a separate TCP connection.The “out-of-band” and “in-band” channels use different port numbers.RTSP messages are also sent out-of-band:RTSP control messages use different port numbers than the media stream: out-of-band.Port 554The media stream is considered “in-band”.
18Real-time, Interactive Multimedia: Internet Phone Case Study VoIP & SIPReal-time, Interactive Multimedia: Internet Phone Case Study
19Real-time interactive applications Going to now look at a PC-2-PC Internet phone example in detailPC-2-PC phoneinstant messaging services are providing thisPC-2-phoneDialpadNet2phonevideoconference with Webcams
20Interactive Multimedia: Internet Phone Introduce Internet Phone by way of an examplespeaker’s audio: alternating talk spurts, silent periods.64 kbps during talk spurtpkts generated only during talk spurts20 msec chunks at 8 Kbytes/sec: 160 bytes dataapplication-layer header added to each chunk.Chunk+header encapsulated into UDP segment.application sends UDP segment into socket every 20 msec during talkspurt.
21Internet Phone: Packet Loss and Delay network loss: IP datagram lost due to network congestion (router buffer overflow)delay loss: IP datagram arrives too late for playout at receiverdelays: processing, queueing in network; end-system (sender, receiver) delaystypical maximum tolerable delay: 400 msloss tolerance: depending on voice encoding, losses concealed, packet loss rates between 1% and 10% can be tolerated.
22Delay Jitterconstant bitratetransmissionvariablenetworkdelay(jitter)clientreceptionconstant bitrate playoutat clientclient playoutdelayCumulative databuffereddatatimeConsider the end-to-end delays of two consecutive packets: difference can be more or less than 20 msec
23Internet Phone: Fixed Playout Delay Receiver attempts to playout each chunk exactly q msecs after chunk was generated.chunk has time stamp t: play out chunk at t+q .chunk arrives after t+q: data arrives too late for playout, data “lost”Tradeoff for q:large q: less packet losssmall q: better interactive experience
24Fixed Playout Delay First packet received at time r Sender generates packets every 20 msec during talk spurt.First packet received at time rFirst playout schedule: begins at pSecond playout schedule: begins at p’
25Adaptive Playout Delay, I Goal: minimize playout delay, keeping late loss rate lowApproach: adaptive playout delay adjustment:Estimate network delay, adjust playout delay at beginning of each talk spurt.Silent periods compressed and elongated.Chunks still played out every 20 msec during talk spurt.Dynamic estimate of average delay at receiver:where u is a fixed constant (e.g., u = .01).
26Adaptive playout delay II Also useful to estimate the average deviation of the delay, vi :The estimates di and vi are calculated for every received packet, although they are only used at the beginning of a talk spurt.For first packet in talk spurt, playout time is:where K is a positive constant.Remaining packets in talk spurt are played out periodically
27Adaptive Playout, IIIQ: How does receiver determine whether packet is first in a talk spurt?If no loss, receiver looks at successive timestamps.difference of successive stamps > 20 msec -->talk spurt begins.With loss possible, receiver must look at both time stamps and sequence numbers.difference of successive stamps > 20 msec and sequence numbers without gaps --> talk spurt begins.
28Summary: Internet Multimedia: bag of tricks use UDP to avoid TCP congestion control (delays) for time-sensitive trafficclient-side adaptive playout delay: to compensate for delayserver side matches stream bandwidth to available client-to-server path bandwidthchose among pre-encoded stream ratesdynamic server encoding rateerror recovery (on top of UDP)FEC, interleavingretransmissions, time permittingconceal errors: repeat nearby data
29Protocols for Real-Time Interactive Applications : RTP, RTCP, and SIP VoIP & SIPProtocols for Real-Time Interactive Applications : RTP, RTCP, and SIP
30Real-Time Protocol (RTP) RTP specifies a packet structure for packets carrying audio and video dataRFC 1889.RTP packet providespayload type identificationpacket sequence numberingtimestampingRTP runs in the end systems.RTP packets are encapsulated in UDP segmentsInteroperability: If two Internet phone applications run RTP, then they may be able to work together
31RTP runs on top of UDPRTP libraries provide a transport-layer interfacethat extend UDP:port numbers, IP addressespayload type identificationpacket sequence numberingtime-stamping
32RTP Example Consider sending 64 kbps PCM-encoded voice over RTP. Application collects the encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk.The audio chunk along with the RTP header form the RTP packet, which is encapsulated into a UDP segment.RTP header indicates type of audio encoding in each packetsender can change encoding during a conference.RTP header also contains sequence numbers and timestamps.
33RTP and QoSRTP does not provide any mechanism to ensure timely delivery of data or provide other quality of service guarantees.RTP encapsulation is only seen at the end systems: it is not seen by intermediate routers.Routers providing best-effort service do not make any special effort to ensure that RTP packets arrive at the destination in a timely matter.
34RTP HeaderPayload Type (7 bits): Indicates type of encoding currently being used. If sender changes encoding in middle of conference, senderinforms the receiver through this payload type field.Payload type 0: PCM mu-law, 64 kbpsPayload type 3, GSM, 13 kbpsPayload type 7, LPC, 2.4 kbpsPayload type 26, Motion JPEGPayload type 31. H.261Payload type 33, MPEG2 videoSequence Number (16 bits): Increments by one for each RTP packetsent, and may be used to detect packet loss and to restore packetsequence.
35RTP Header (2)Timestamp field (32 bytes long). Reflects the sampling instant of the first byte in the RTP data packet.For audio, timestamp clock typically increments by one for each sampling period (for example, each 125 usecs for a 8 KHz sampling clock)if application generates chunks of 160 encoded samples, then timestamp increases by 160 for each RTP packet when source is active. Timestamp clock continues to increase at constant rate when source is inactive.SSRC field (32 bits long). Identifies the source of the RTP stream. Each stream in a RTP session should have a distinct SSRC.
36Real-Time Control Protocol (RTCP) Works in conjunction with RTP.Each participant in RTP session periodically transmits RTCP control packets to all other participants.Each RTCP packet contains sender and/or receiver reportsreport statistics useful to applicationStatistics include number of packets sent, number of packets lost, interarrival jitter, etc.Feedback can be used to control performanceSender may modify its transmissions based on feedback
37SIP Session Initiation Protocol Comes from IETF SIP long-term vision All telephone calls and video conference calls take place over the InternetPeople are identified by names or addresses, rather than by phone numbers.You can reach the callee, no matter where the callee roams, no matter what IP device the callee is currently using.
38RFC and Related Protocols Originally specified in RFC 2543 (March 1999)RFC 3261, new standards track released in June 2002An application-layer control signaling protocol for creating, modifying and terminating sessions with one or more participantsA component that can be used with other IETF protocols to build a complete multimedia architecture (e.g. RTP, RTSP, MEGACO, SDP)
39SIP FunctionalitySupports five facets of establishing and terminating multimedia communicationsUser LocationUser AvailabilityUser CapabilitiesSession SetupSession Management SIP supports five facets of establishing and terminating multimedia communications:1. User Location: determination of the end system to be used for communication;2. User Availability: determination of the willingness of the called party to engage in communications;3. User Capabilities: determination of the media and media parameters to be used;4. Session Setup: establishment of session parameters at both called and calling party;5. Session Management: including transfer and termination of sessions, modifying session parameters, and invoking services.
40SIP Architecture Client-server in nature Main entities: User Agent Proxy ServerRedirect ServerRegistration ServerLocation Server
41Registrar and UA Behavior SIP RegistrarSIP User AgentUser Agent sends a registration message to the SIP Registrar and the Registrar stores the registration information in a location service via a non-SIP protocol. Once the information is stored, the Registrar sends the appropriate response back to the user agentSIP RequestSIP ReplyNon-SIP ProtocolSIP Location Service
42SIP Proxy/Redirect Servers and UA Behaviors Location Service2,35,6SIP ProxySIP ProxySIP Proxy14711101298SIP User Agent(Caller)SIP User Agent(Caller)Non-SIP Protocol
43Model of VoIP Communication Between Two Soft Phones Protocol dependencyUDPSoftPhoneSoftPhoneSIPSDPRTPAudio Codec(e.g. voice)Example does not represent actual scale
46SIP Response Messages 100 Trying 180 Ringing 181 Call is being Forwarded182 Queued200 OK301 Moved Permanently302 Moved Temporarily
47Messages FlowPrimary protocol for establishing sessions between VoIP applications (softphones)Cooperating protocols – RTP (Realtime Transmission Protocol), SDP (Session Description protocol)
48Example of SIP message INVITE sip:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDPFrom:To:Call-ID:Content-Type: application/sdpContent-Length: 885c=IN IPm=audio RTP/AVP 0Notes:HTTP message syntaxsdp = session description protocolCall-ID is unique for every call.Here we don’t knowBob’s IP address.Intermediate SIP servers will be necessary.Alice sends and receives SIP messages using the SIP default port number 5060.Alice specifies in Via: header that SIP client sends and receives SIP messages over UDP
49Name translation and user locataion Caller wants to call callee, but only has callee’s name or address.Need to get IP address of callee’s current host:user moves aroundDHCP protocoluser has different IP devices (PC, PDA, car device)Result can be based on:time of day (work, home)caller (don’t want boss to call you at home)status of callee (calls sent to voic when callee is already talking to someone)Service provided by SIP servers:SIP registrar serverSIP proxy server
50SIP RegistrarWhen Bob starts SIP client, client sends SIP REGISTER message to Bob’s registrar server(similar function needed by Instant Messaging)Register Message:REGISTER sip:domain.com SIP/2.0Via: SIP/2.0/UDPFrom:To:Expires: 3600
51SIP Proxy Alice send’s invite message to her proxy server contains addressProxy responsible for routing SIP messages to calleepossibly through multiple proxies.Callee sends response back through the same set of proxies.Proxy returns SIP response message to Alicecontains Bob’s IP addressNote: proxy is analogous to local DNS server
52Two major signaling standards ITU-T H.323More mature and applicableLess flexible and expansibleIETF Session Initiation Protocol (SIP) – RFC 2543greater scalability easing Internet application integrationLess definition
53Comparison with H.323H.323 is another signaling protocol for real-time, interactiveH.323 is a complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport and codecs.SIP is a single component. Works with RTP, but does not mandate it. Can be combined with other protocols and services.H.323 comes from the ITU (telephony).SIP comes from IETF: Borrows much of its concepts from HTTP. SIP has a Web flavor, whereas H.323 has a telephony flavor.SIP uses the KISS principle: Keep it simple stupid.
55Challenges: NATs and firewalls NATs and firewalls reduce Internet to web and servicefirewall, NAT: no inbound connectionsNAT: no externally usable addressNAT: many different versions binding durationlack of permanent address (e.g., DHCP) not a problem SIP address bindingmisperception: NAT = security
56Challenges: QoS Not lack of protocols – RSVP, diff-serv Lack of policy mechanisms and complexitywhich traffic is more important?how to authenticate users?cross-domain authenticationmay need for access only – bidirectional trafficDiffServ: need agreed-upon code pointsNSIS WG in IETF – currently, requirements only
57Challenges: SecurityPSTN model of restricted access systems cryptographic securityDumb end systems PCs with a handsetObjectives:identification for access control & billingphone/IM spam control (black/white lists)call routingprivacy
59Our Results Members of our team: Prof. Chiu, Prof. Gu, and Prof. Ferng Four Industrial Projects and one NSC projectNon-SIP based PC-to-PC UASIP-based UAVOCAL SIP ServersSecured UA (Under development)
61Related workVovida Open Communication Application Library (VOCAL)open source project targeted at facilitating the adoption of VoIP in the marketplaceincludes a SIP based Redirect Server, Feature Server, Provisioning Server and Marshal Proxyopen source project targeted at facilitating the adoption of VoIP in the marketplace. VOCAL provides the development community with software and tools needed to build new and exciting VoIP features, applications and services . software in VOCAL includes a SIP based Redirect Server, Feature Server, Provisioning Server and Marshal Proxy. This is the stable development branch of the VOCAL
64ReferencesD. Collins, Carrier Grade Voice over IP, 2nd Edition, McGraw-Hill, 2003.Vovida Open Communication Application Library (VOCAL)L. Dang, C. Jennings, and D. Kelly, Practical VoIP Using VOCAL, OReilly & Associates Inc., 2002.J. F. Kurose and K. W. Ross, Computer Networking: A Top-Down Approach Featuring the Internet, 2nd Edition, Addison Wesley, 2003.