Application Layer Protocols For Real-Time Media Transmission

The Layers – Again (OSI model) Application/ Representation/Session Application/ Representation/Session Transport Transport Network Network Network Link/ Physical Link/ Physical Link/ Physical Link/ Physical

The Layers – Again (Internet model) Application Application Transport Transport Internetwork Internetwork Internetwork Subnetwork Subnetwork Subnetwork Subnetwork

The Layers (Web browsing example) HTTP HTTP TCP TCP IP IP routing IP Ethernet Ethernet Ethernet Ethernet

The Layers (Real Time Media) SIP/RTP/RTCP SIP/RTP/RTCP TCP/UDP TCP/UDP IP IP routing IP Ethernet Ethernet Ethernet Ethernet

Everything runs over IP The Role of IP Everything runs over IP IP IP runs over Everything

Multi-Multi-Multi-Multi Subnetwork: multiple communications share the same physical channel Internetwork: Each communication may pass multiple subnetworks Transport: End-To-End abstraction Application: multiple users take part in same communication session using multiple types of media

A Real Life Scenario Pure SIP based In internet side

RTP = Real Time Protocol

Field Name in rtpTypes.h Content V version     Field Name in rtpTypes.h Content V version Version of the RTP. Always equal to two. P padding Not used. Padding may be needed by some encryption algorithms with a required fixed block size. X extension Not used. Used if the header is followed by a header extension. CSRC count (CC) count Number of CSRC identifiers that follow the fixed header M marker For applications which send no packets during silence, the first packet of a talk spurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero. Payload type type Identifies the format of the RTP payload at any given time. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload codes may be defined dynamically through SIP negotiation.   Audio applications operating under the AV profile specified in RFC 1890 should, at minimum, be able to send and receive payload types 0 (G.711U) and 5 (DVI4). This allows interoperability without format negotiation and successful negotiation with a conference control protocol. The payload types currently defined in this profile carry either audio or video, but not both. Sequence number sequence The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number is random (unpredictable) to make known-plaintext attacks on encryption more difficult  

Field Name in rtpTypes.h Content Timestamp timestamp     Field Name in rtpTypes.h Content Timestamp timestamp The timestamp reflects the sampling instant of the first octet in the RTP data packet. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent. The timing information enables the application to synchronize audio and video data. SSRC ssrc The SSRC field identifies the synchronization source. A receiver groups packets by synchronization source for playback. Examples of synchronization sources include the sender of a stream of packets derived from a signal source such as a microphone or a camera. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. CSRC list startOfCsrc 0 to 15 items The CSRC list is used when a payload is composed of data from several sources and serves to identify these sources. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 may be identified. CSRC identifiers are inserted by mixers, using the SSRC identifiers of contributing sources. For example, for audio packets the SSRC identifiers of all sources that were mixed together to create a packet are listed, allowing correct talker indication at the receiver.    

An Example Codec iLBC

iLBC Encoding 944 Figure 1.1

iLBC Decoding 944 Figure 1.2

iLBC residual coding from start state 944 figure 1.9

iLBC building an adaptive codebook from start state 944 figure 1.14

Codec response to packet loss - a waveform example

Codec response to packet loss - MOS test Test conducted by Lockhead Martin (former Dynastat testlab)

Codec response to packet loss - some signals G729 at 0% packet loss iLBC at 0% packet loss G729 at 15% packet loss iLBC at 15% packet loss

Structure of the specification A draft on the codec draft-ietf-avt-ilbc-codec-04.txt A draft on the RTP payload profile draft-ietf-avt-rtp-ilbc-04.txt

PLC: Packet Loss Concealment iLBC PLC with normal muting iLBC PLC with rulebased muting Gerne eksempler fra side 10 I Søren og Steffens projekt

SIP = Session Initiation Protocol = An application layer signaling protocol that defines initiation, modification and termination of interactive, multimedia communication sessions between users.

SIP Framework Email Session initiation. Multiple users. Instant Messaging Session initiation. Multiple users. Interactive multimedia applications. Personal Mobility Voice Calls Conferencing Email Distance Learning MPEG, MP3, Audio, HTML,XML Video Conferencing

SIP Distributed Architecture SIP Components Location Server Redirect Server Registrar Server . Proxy Server Proxy Server PSTN User Agent Gateway

User Agents An application that initiates, receives and terminates calls. User Agent Clients (UAC) – An entity that initiates a call. User Agent Server (UAS) – An entity that receives a call. Both UAC and UAS can terminate a call.

Proxy Server An intermediary program that acts as both a server and a client to make requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. Interprets, rewrites or translates a request message before forwarding it.

Location Server A location server is used by a SIP redirect or proxy server to obtain information about a called party’s possible location(s).

Redirect Server A server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, the redirect server does not initiate its own SIP request. Unlike a user agent server, the redirect server does not accept or terminate calls.

Registrar Server A server that accepts REGISTER requests. The register server may support authentication. A registrar server is typically co-located with a proxy or redirect server and may offer location services.

SIP Messages – Methods and Responses SIP components communicate by exchanging SIP messages: SIP Methods: INVITE – Initiates a call by inviting user to participate in session. ACK - Confirms that the client has received a final response to an INVITE request. BYE - Indicates termination of the call. CANCEL - Cancels a pending request. REGISTER – Registers the user agent. OPTIONS – Used to query the capabilities of a server. INFO – Used to carry out-of-bound information, such as DTMF digits. SIP Responses: 1xx - Informational Messages. 2xx - Successful Responses. 3xx - Redirection Responses. 4xx - Request Failure Responses. 5xx - Server Failure Responses. 6xx - Global Failures Responses.

SIP Headers SIP is an ASCII protocol The SIP message is placed in a message Header -------------------------------------------------- SIP Header ----------------------------------------------------------------- INVITE sip:5120@192.168.36.180 SIP/2.0 Via: SIP/2.0/UDP 192.168.6.21:5060 From: sip:5121@192.168.6.21 To: <sip:5120@192.168.36.180> Call-ID: c2943000-e0563-2a1ce-2e323931@192.168.6.21 CSeq: 100 INVITE Expires: 180 User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled Accept: application/sdp Contact: sip:5121@192.168.6.21:5060 Content-Type: application/sdp

SIP Addressing The SIP address is identified by a SIP URL, in the format: user@host. Examples of SIP URLs: sip:hostname@vovida.org sip:hostname@192.168.10.1 sip:14083831088@vovida.org

Process for Establishing Communication Establishing communication using SIP usually occurs in six steps: Registering, initiating and locating the user. Determine the media to use – involves delivering a description of the session that the user is invited to. Determine the willingness of the called party to communicate – the called party must send a response message to indicate willingness to communicate – accept or reject. Call setup. Call modification or handling – example, call transfer (optional). Call termination.

Registration Each time a user turns on the SIP user client (SIP IP Phone, PC, or other SIP device), the client registers with the proxy/registration server. Registration can also occur when the SIP user client needs to inform the proxy/registration server of its location. The registration information is periodically refreshed and each user client must re-register with the proxy/registration server. Typically the proxy/registration server will forward this information to be saved in the location/redirect server. Location/ Redirect Server SIP Phone User Proxy/ Registration Server REGISTER REGISTER 200 200 SIP Messages: REGISTER – Registers the address listed in the To header field. 200 – OK.

Simplified SIP Call Setup and Teardown INVITE Location/Redirect Server Proxy Server Proxy Server User Agent 302 (Moved Temporarily) ACK INVITE Call Setup INVITE 302 (Moved Temporarily) ACK INVITE 180 (Ringing) 180 (Ringing) 180 (Ringing) 200 (OK) 200 (OK) 200 (OK) ACK ACK ACK Media Path RTP MEDIA PATH Call Teardown BYE BYE BYE 200 (OK) 200 (OK) 200 (OK)

Resources WWW.IETF.ORG WWW.VOVIDA.ORG WWW.CS.COLUMBIA.EDU/SIP WWW.IPTEL.ORG WWW.SIPFOUNDRY.ORG