Real-Time (Phone) Over IP’s Multimedia Networking Best-Effort Last time Principles � Classify multimedia � Multimedia Networking Applications � Settings applications � Streaming stored audio and video � Identify the network � talk spurts Today services the apps � 8 Kbytes/sec � Real-time Multimedia: Internet Phone need study � Making the best of � sample every 20 msec best effort service � Protocols for Real-Time Interactive � packet of 160 Bytes + application header over Applications - RTP, RTCP, SIP � Mechanisms for UDP providing QoS � Distributing Multimedia: content Protocols and distribution networks � up to 20 % loss is tolerable Architectures � Beyond Best Effort � TCP instead of UDP? � Specific protocols � Scheduling and Policing Mechanisms for best-effort � Integrated Services and � Architectures for Differentiated Services QoS � RSVP 10/5-07 Datakommunikation - Jonny Pettersson, UmU 10/5-07 Datakommunikation - Jonny Pettersson, UmU Recovery From Packet Loss Recovery From Jitter � Loss is in a broader sense: � End-to-end delays � packet never � max 400 msec tolerated arrives or arrives later than its � Delay jitter is handled by using scheduled playout time � timestamps � FEC - Forward � sequence numbers Error Correction � delaying playout � Simple or-ing • fixed amount � Mixed quality streams • variable amount � Interleaving � Repair of packet 10/5-07 Datakommunikation - Jonny Pettersson, UmU 10/5-07 Datakommunikation - Jonny Pettersson, UmU Summary: Internet Multimedia: Real-Time Protocol (RTP) bag of tricks � use UDP to avoid TCP congestion control (delays) � RTP specifies a packet � RTP runs in the end for time-sensitive traffic structure for packets systems carrying audio and � RTP packets are � client-side adaptive playout delay: to compensate video data for delay encapsulated in UDP � RFC 3550 segments � server side matches stream bandwidth to available client-to-server path bandwidth � RTP packet provides � Interoperability: If � chose among pre-encoded stream rates two Internet phone � payload type � dynamic server encoding rate identification applications run RTP, � error recovery (on top of UDP) � packet sequence then they may be able numbering � FEC, interleaving to work together � retransmissions, time permitting � timestamping � conceal errors: repeat nearby data 10/5-07 10/5-07 Datakommunikation - Jonny Pettersson, UmU Datakommunikation - Jonny Pettersson, UmU 1
RTP and QoS Real-Time Protocol (RTP) � RTP 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 � Specifies header fields systems: it is not seen by intermediate � Payload Type : types of encoding routers � Sequence Number : to detect packet loss � Routers providing best-effort service do not � Timestamp : the sampling instant of the first make any special effort to ensure that RTP audio/video byte in the packet packets arrive at the destination in a timely � Synchronization Source identifier (SSRC) : an matter id for the source of a stream 10/5-07 Datakommunikation - Jonny Pettersson, UmU 10/5-07 Datakommunikation - Jonny Pettersson, UmU Real-Time Control Protocol RTCP - Continued (RTCP) � Works in conjunction � Statistics include with RTP number of packets � Each participant in sent, number of RTP session packets lost, periodically transmits interarrival jitter, etc. RTCP control packets - For an RTP session there is typically a single multicast address; all � Feedback can be used to all other RTP and RTCP packets belonging to the session use the multicast to control participants address performance � Each RTCP packet - RTP and RTCP packets are distinguished from each other through � Sender may modify contains sender and/or the use of distinct port numbers receiver reports its transmissions � report statistics useful based on feedback - To limit traffic, each participant reduces his RTCP traffic as the to application number of conference participants increases 10/5-07 Datakommunikation - Jonny Pettersson, UmU 10/5-07 Datakommunikation - Jonny Pettersson, UmU RTCP Packets SIP � Session Initiation Protocol Receiver report packets: Source description packets: � e-mail address of sender, � SSRC of the RTP stream, � Comes from IETF fraction of packets lost, last sender's name, SSRC of SIP long-term vision sequence number, average associated RTP stream interarrival jitter � Provide a mapping between � All telephone calls and video conference the SSRC and the Sender report packets: calls take place over the Internet user/host name � SSRC of the RTP stream, the timestamp and the � People are identified by names or e-mail current time of the last RTP � 5% of total bandwidth addresses, rather than by phone numbers packet, the number of � 25% of that for the packets sent, and the sender � You can reach the callee, no matter where number of bytes sent � 75% for the receivers the callee roams, no matter what IP device the callee is currently using 10/5-07 10/5-07 Datakommunikation - Jonny Pettersson, UmU Datakommunikation - Jonny Pettersson, UmU 2
Setting up a call to a known IP address SIP Services • Alice’s SIP invite Bob Alice message indicates her � Setting up a call � Determine current IP port number & IP address. address of callee � Provides mechanisms Indicates encoding that 167.180.112.24 193.64.210.89 for caller to let INVITE bob@193.64.210.89 Alice prefers to receive � Maps mnemonic c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 (PCM ulaw) callee know she identifier to current IP port 5060 Bob's wants to establish a address terminal rings 200 OK • Bob’s 200 OK message call � Call management c=IN IP4 193.64.210.89 m=audio 48753 RTP/AVP 3 indicates his port number, port 5060 � Provides mechanisms � Add new media streams IP address & preferred so that caller and ACK during call port 5060 encoding (GSM) callee can agree on � Change encoding during µ Law audio media type and call • SIP messages can be port 38060 encoding sent over TCP or UDP; � Invite others here sent over RTP/UDP � Provides mechanisms GSM � Transfer and hold calls port 48753 to end call •Default SIP port number is 5060 time time 10/5-07 Datakommunikation - Jonny Pettersson, UmU 10/5-07 Datakommunikation - Jonny Pettersson, UmU Example of SIP message Setting up a call (more) � Rejecting the call • Here we don’t know � Codec negotiation: INVITE sip:bob@domain.com SIP/2.0 Bob’s IP address. � Bob can reject with Via: SIP/2.0/UDP 167.180.112.24 � Suppose Bob doesn’t have Intermediate SIP replies “busy,” “gone,” PCM ulaw encoder From: sip:alice@hereway.com servers will be “payment required,” To: sip:bob@domain.com � Bob will instead reply with necessary “forbidden” 606 Not Acceptable Call-ID: a2e3a@pigeon.hereway.com � Media can be sent over RTP Reply and list encoders he Content-Type: application/sdp • Alice sends and or some other protocol can use Content-Length: 885 receives SIP messages � Alice can then send a new using the SIP default INVITE message, c=IN IP4 167.180.112.24 port advertising an appropriate m=audio 38060 RTP/AVP 0 encoder Notes: • Alice specifies in Via: � HTTP message syntax header that SIP client � sdp = session description protocol sends and receives SIP messages over UDP � Call-ID is unique for every call 10/5-07 Datakommunikation - Jonny Pettersson, UmU 10/5-07 Datakommunikation - Jonny Pettersson, UmU Name translation and user SIP Registrar locataion � When Bob starts SIP client, client sends SIP � Result can be based on: REGISTER message to Bob’s registrar server � Caller wants to call � time of day (work, home) callee, but only has (similar function needed by Instant Messaging) � caller (don’t want boss to callee’s name or e-mail call you at home) address � status of callee (calls sent Register Message: to voicemail when callee is � Need to get IP already talking to address of callee’s someone) REGISTER sip:domain.com SIP/2.0 current host: Service provided by SIP Via: SIP/2.0/UDP 193.64.210.89 � user moves around servers: From: sip:bob@domain.com � DHCP protocol To: sip:bob@domain.com � SIP registrar server � user has different IP Expires: 3600 devices (PC, PDA, car � SIP proxy server device) 10/5-07 10/5-07 Datakommunikation - Jonny Pettersson, UmU Datakommunikation - Jonny Pettersson, UmU 3
Recommend
More recommend