Application Layer Protocols For Real-Time Media Transmission.

Post on 20-Dec-2015

225 Views

Category:

Documents

5 Downloads

Preview:

Click to see full reader

Transcript

Application Layer ProtocolsFor Real-Time Media

Transmission

The Layers – Again(OSI model)

Link/Physical

Network

Transport

Application/Representation/

Session

Link/Physical

Link/Physical

Link/Physical

Network

Transport

Network

Application/Representation/

Session

The Layers – Again(Internet model)

Subnetwork

Internetwork

Transport

Application

Subnetwork Subnetwork Subnetwork

Internetwork

Transport

Application

Internetwork

The Layers(Web browsing example)

Ethernet

IP

TCP

HTTP

Ethernet Ethernet Ethernet

IP

TCP

HTTP

IP routing

The Layers(Real Time Media)

Ethernet

IP

TCP/UDP

SIP/RTP/RTCP

Ethernet Ethernet Ethernet

IP

TCP/UDP

IP routing

SIP/RTP/RTCP

The Role of IP

IP

Everything runs over 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 basedIn internet side

RTP = Real Time Protocol

V=2

0 7654321 0 7654321 0 7654321 0 7654321

0 321

P X CSRC count M Payload Type (PT) Sequence number

Timestamp

Synchronisation source (SSRC) identifier

Contributing source (CSRC) identifiers (optional)

payload(application dependent)

   

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 markerFor 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 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 startOfCsrc0 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 CodeciLBC

iLBC Encoding

iLBC Decoding

iLBC residual coding from start state

iLBC building an adaptive codebook from start state

Codec response to packet loss - a waveform example

Codec response to packet loss- MOS test

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 rulebased muting

iLBC PLC with normal muting

SIP = Session Initiation Protocol = An application layer signaling protocol

that defines initiation, modification and termination of interactive, multimedia communication sessions between users.

SIP Framework

– Session initiation.

– Multiple users.

– Interactive multimedia applications.

Redirect Server

SIP Distributed Architecture

Location Server

Registrar Server

User Agent

Proxy Server

Gateway

PSTN

SIP Components

Proxy Server

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 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 components communicate by exchanging SIP messages:

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:

1. Registering, initiating and locating the user.2. Determine the media to use – involves delivering a description

of the session that the user is invited to.3. 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.

4. Call setup.5. Call modification or handling – example, call transfer

(optional).6. 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.

SIP Messages:REGISTER – Registers the address listed in the To header field.200 – OK.

Proxy/ Registration Server

SIP PhoneUser

Location/Redirect Server

REGISTER REGISTER

200200

Simplified SIP Call Setup and Teardown

302 (Moved Temporarily)

INVITE

200 (OK)200 (OK)

ACK

INVITE302

(Moved Temporarily)ACK

INVITE

180 (Ringing)180 (Ringing)180 (Ringing)

200 (OK)ACKACK ACK

RTP MEDIA PATH

BYEBYE BYE

200 (OK)200 (OK) 200 (OK)Call Teardown

MediaPath

Call Setup

INVITE

Location/Redirect ServerProxy Server Proxy Server User AgentUser AgentINVITE

Resources

• WWW.IETF.ORG

• WWW.VOVIDA.ORG

• WWW.CS.COLUMBIA.EDU/SIP

• WWW.IPTEL.ORG

• WWW.SIPFOUNDRY.ORG

top related