1 © NOKIA FILENAMs.PPT/ DATE / NN Helsinki University of Technology Department of Electrical and...

1 © NOKIA FILENAMs.PPT/ DATE / NN

Helsinki University of TechnologyDepartment of Electrical and Communications Engineering

Jarkko Kneckt

point to point and point to multi point calls over IP

Helsinki 27.11.2001

Supervisor: Raimo KantolaInstructor: Heikki Salovuori MSc.


AGENDA

• Different types of call services• Differences between simplex (streaming) and duplex calls• Role of server in simplex calls

• Used protocols• General introduction to VOIP protocols• Discussion on what simplex connections need for signaling

protocol• Introduction to our choise for simplex call signaling

• Voip client implementation • General operation of VOIP client• General architecture of simplex call type VOIP client


Call services

D U PLEX C ALL = (N orm al ca ll)Both parties can speak and lis ten at the sam e tim e

<SIM PLEX = S tream ing> call("W alkie Talkie like" call)

one party can speak at the tim e. There can be severallis teners


Why have simplex calls 1

1.No quality of service in internet• Streaming call is send only one direction.

Receiver cannot speak at the same time as speaker is speaking. => Receiver can use bigger jitter buffer to buffer packet sending speed variation than used in normal VOIP applications.

2. New way to communicate • Message to one receiver (or many receivers) at the

time. From previous same kind applications average duration of one simplex call is 7 seconds. This causes special needs to be able to start call fast, setup should take 0,5 – 1 s.


Why have simplex calls 2

SERVERSERVER

SERVER

= unicasted voice packetover in ternet

Servers in picture areused only by this application. Servers forward this application packets.

IP network

3. Streaming call is easy to copy several receiver


New problems in simplex call handling

Problems in simplex call system handling:(These problems define the role for ”server system” when simplex call mode is used

1. Sim plex call

("W alkie Talkie like" call)Two calls starting at the sam e tim e

C all 2

C a ll 1

Which call should be played?How to minimize traffic , especially air traffic to phone?

2. Term inal user is sending one callwhen new call is starting

C all 1 outgo ingC all 2 startingShould outgoing call be ended?Should starting call be dropped?


New problems in simplex call handling

A ll te rm ina ls a re trying to sta rt sam e sim plex ca llwho can speak ?

3. How to keep a record who are using the service?

4. How to specify which calls you want to listen?5. How to specify rights for calls ? Who can speak?

6. Usability. How to use service so that it is easy and simple to use?


protocols in VOIP

IPv4, IPv6

TC P U DP

R TP

H .323 SIP

R TSP R SVP R TCP

Signaling

Q uality of service

M edia encaps (H .261,M PEG )

M edia transport

SIP and rtp handling are in the scope of this work


• RTP Real Time Protocol

• RTP is protocol, which provides timing information to packets.

• RTP protocol does not include jitter (= time buffering for variation of packet arrival times) buffering function, but jitter buffering can be made according to information in RTP headers. Jitter buffering is own application.

• Normally used to add time information to packets from sender to receiver. Also used to specify realtime connection and codec (audio / video) which has created the sent data.

Functions of RTP


Streaming special needs for signalling

Problem in point to multipoint call. call should start ride away we don’t have

Normally SIP or H.323 is used for VOIP call signalling.

Invite

180 R inging

200 O K

A C K

Call start w ith S IP

C all ongo ing

Now we are not interested to getacknowledge from every called party in point to multipoint call. Sip is not appropriate signalling protocol because

according to protocol we must get acknowledgement from receiver.

However SIP is very easy to adjust the needs for signaling. Sip can be used as signaling protocol inmany different applications.

Acknowledgement in point to multipoint calls would introduce unnecessary delays whenack message is waited. Acknowledged setup messages


How to speed up setup time ?Usage of acknowledgement in point to multipoint calls setup messageswould introduce unnecessary delays when ack message is waited.

On the other hand if we receive some acks but not all should we wait forall acks to arrive or should the call be started right away?question is : how to set limits when point to multipoint call can be started?

Better solution for setup messages is to define a time after call is started. No acknowledgements etc. is send.

Normally in VOIP calls in call setup phase also the codec is chosen. If we could agree on

all issues that are not directly depending on call setup, (used codec, receiver(s))

so that actual setup message contains only relevant information.

SIP or H.323 cannot be used for this kind of signaling. New signaling protocol is needed: One solution is to transfer signaling information on top of RTP. Also completely new protocol could be created on top of UDP.


SIP usage

• SIP (Session Initialization protocol) contains ready made signaling messages without payload. Payload can be add with SDP Session Description Protocol. Only the format of payload is defined, not sent data.

• The role of SIP is a bit different than in normal VOIP solutions

• SIP is used for:• sending log on /log off messages to service (SIP :

REGISTER)• defining which calls are received• defining in point to multipoint calls who are callees


Pros and cons in rtp usage in signalling

Positive Negative

Originally planned for real time data transfer

Works on top of UDP => no connection oriented benefits. No automatic packetloss detection or resend

RTP is well specsed, ready designed interface

RTP is used in almost all VOIP solutions.

Easier to use ready standardized protocolthan try to standardize a completely newprotocol.

RTP header needs only new payload type for signaling


RTP header

Timestamp

SSRC

0 31

12 Bytessequence numberPayload typeMCCV XP

Symbol defination and binary value if standard lenght in bits• V Version. Identifies the version of rtp 2 • P Padding. When set, the packet contains one or more additional padding octetsat the,

end which are not part of the payload 1• X Extension bit. When set the fixed header is followed header is followed by exactly one

extension 1• CC CSRC count. Number of CRSC identifiers that follow fixed header 4• M Marker bit. The interpretation of the marker is defined by a profile. It is intented to

allow significant events such as frame boundaries to be marked in the packet stream 1• PT Payload type. Identifies the format of the RTP payload and determines its

interoperability by the application. A profile spacifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defineddynamically through non-RTP means 7

• sequence number increased by one for each RTP packet sent, and may be used by the default to detect packet loss and to restore packet sequence 16

• timestamp Reflects the sampling instant of the first octet in the RTP data packet. Thesampling instant must be derived from a clock that increments monotonicallyand linearly in time to allow synchronization and jitter calculations. 32

• SSRC identifies the synchronization source. This identifier is chosebn randomly, with the intent that two synchronization sources will have same SSRC identifier 32


RTP header usage in signaling

• RTP header can be used for signaling purposes by defining a payload type for signaling. This way application knows that message contains signaling.

• All the other fields can remain the same.

• Application must build retransmit and confirmation mechanism in message charts.

• RTP signaling is used only for setup and termination messages.

Timestamp

SSRC

sequence numberPayload typeMCCV XP


Point to multipoint call:

Client 1 Client 2Server

1. Leading RTP packet



4.Audio packets of the call

5. Trailing RTP packet

Call ongoing

Call setup

Call termination





. 5. Trailing RTP packet6. Trailing RTP packet 6. Trailing RTP packet

7. Trailing RTP packet 7. Trailing RTP packet

1-3 setup message

All signaling messages are sent 3 times to avoid packet loss errors

4 Audio packets

5-7 Termination messages

RTP signaling example 1


Point to point call

Client 1 Client 2Server




7. Trailing RTP packet

Call ongoing

Call setup

Call termination



3. RTP ACK


7. Trailing RTP packet8. Trailing RTP packet 8. Trailing RTP packet

. 9. Trailing RTP packet . 9. Trailing RTP packet

1-2 setup message

6 Audio packets

7-9 Termination messages

3. RTP ACK

4. RTP ACK4. RTP ACK

3-5 ACK messages to setup.

When we receive ACK we can stop sending leading RTP All signaling messages are sent 3 times to avoid packet loss errors

5. RTP ACK5. RTP ACK

RTP Signaling example 2


Work share between client and server: (see slides 6-7 for serverside general problems of simplex calls)

1. Client proposes new calls server decides can client start a call2. Server looks that client receives only one call at the time3. Client takes care of voice handling. Server only forwards voice

packets to clients.

My implementation (as a part of master thesis work):Client working on linux in laptop, connected with Wlan and IPv6 to internet.

Must have support for RTP signaling, SIP signaling and graphical user interface.

General requiremnets for client


client architecture

G raph ica lU ser

In te rface

S ocket U -U P F

S IP hand ler

S ocket fo r S IP

C all s ta te log icR eceived s ignalling

from server

N oise ou t

V o ice in

R TP tra ffic ou t"aud io da ta"

po in t to m u ltipo in t ca llhand ling

requests and responces

Thread 3

Thread 1

E m beddedsigna lling

Incom ing tra ffic

D evice driversD evice drivers

Functions to ca ll s ip s tackand ca ll back functions for

s ipstack

Jitte r B uffe r

request m ore da tafo r p lay ou t

user uses start / endbutton to ca ll

A udio da ta

Thread 2

S ocket fo r aud ioG roup and one to onesocket

Audio packets

A udio hand ling part

C a ll s ta te changesca llback

A ud io codec

raw vo ice


N etwork ca llback , packet arrives

D epacketize incodec m odule.

H andle audio packetand queue in order tojitter buffer

ID LE

N D oes packet conta inem bedded s ignalling

N Y D epacketizeem bedded s ignalling

H andle s ignalling.M ake changes to

call s tate.

ID LE

D o we haveincom ing call?

Y

ID LE

Flow chart for call state logic shown in previous slide.

RTP packet handling flow chart when rtp contains signaling and

audio packets


Flow chart of audio handling in VOIP Audio

Audio device

Microphone

A/D conversion

Audio device driver

Media subsystem

Encoding

Framing

RTP packetization

UDP / IP packetization

Network device driver

Network device

Physical transmission

Audio device

Audio

UDP / IP depacketization

Network device driver

Network device

Physical transmission

RTP depacketization

Jitter buffer

Deframing

Decoding

Media subsystem

Audio device driver

D/A conversion

Loudspeaker

server in internet ornothing

internetinternet

1 © NOKIA FILENAMs.PPT/ DATE / NN Helsinki University of Technology Department of Electrical and...

Documents

Transcript of 1 © NOKIA FILENAMs.PPT/ DATE / NN Helsinki University of Technology Department of Electrical and...