Transcript point to point and point to multi point calls over IP

Helsinki University of Technology
Department of Electrical and Communications Engineering
Jarkko Kneckt
point to point and point to multi point calls over IP
Helsinki 27.11.2001
Supervisor:
Instructor:
1
© NOKIA
FILENAMs.PPT/ DATE / NN
Raimo Kantola
Heikki Salovuori MSc.
AGENDA
•
Different types of call services
•
•
•
Used protocols
•
•
•
•
© NOKIA
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
•
•
2
Differences between simplex (streaming) and duplex calls
Role of server in simplex calls
General operation of VOIP client
General architecture of simplex call type VOIP client
FILENAMs.PPT/ DATE / NN
Call services
DUPLEX CALL = (Normal call)
Both parties can speak and listen at the same time
<SIMPLEX = Streaming> call
("Walkie Talkie like" call)
one party can speak at the time. There can be several
listeners
3
© NOKIA
FILENAMs.PPT/ DATE / NN
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.
4
© NOKIA
FILENAMs.PPT/ DATE / NN
Why have simplex calls 2
3. Streaming call is easy to copy several receiver
Servers in picture areused only by this application.
Servers forward this application packets.
IP network
SERVER
SERVER
SERVER
= unicasted voice packet
over internet
5
© NOKIA
FILENAMs.PPT/ DATE / NN
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.
Simplex call
("Walkie Talkie like" call)
Two calls starting at the same time
Call 1
Which call should be played?
How to minimize traffic , especially
air traffic to phone?
Call 2
2.
Terminal user is sending one call
when new call is starting
Call 2 starting
6
© NOKIA
FILENAMs.PPT/ DATE / NN
Call 1 outgoing
Should outgoing call be ended?
Should starting call be dropped?
New problems in simplex call handling
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?
All terminals are trying to start same simplex call
who can speak ?
6. Usability. How to use service so that it is easy and simple to use?
7
© NOKIA
FILENAMs.PPT/ DATE / NN
protocols in VOIP
Media transport
Media encaps (H.261,
MPEG)
Signaling
Quality of service
H.323
SIP
RTSP RSVP RTCP
RTP
TCP
UDP
IPv4, IPv6
SIP and rtp handling are in the scope of this work
8
© NOKIA
FILENAMs.PPT/ DATE / NN
Functions of RTP
• 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.
9
© NOKIA
FILENAMs.PPT/ DATE / NN
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.
Call start with SIP
Invite
180 Ringing
200 OK
ACK
Call ongoing
Now we are not interested to get
acknowledge from every called party in
point to multipoint call.
Sip is not appropriate signalling protocol becau
according to protocol we must get
acknowledgement from receiver.
However SIP is very easy to adjust the needs f
signaling. Sip can be used as signaling protoco
many different applications.
Acknowledgement in point to multipoint calls would introduce unnecessary delays w
ack message is waited. Acknowledged setup messages
10
© NOKIA
FILENAMs.PPT/ DATE / NN
How to speed up setup time ?
Usage of acknowledgement in point to multipoint calls setup messages
would introduce unnecessary delays when ack message is waited.
On the other hand if we receive some acks but not all should we wait for
all 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
11
on top of RTP.
© NOKIA
FILENAMs.PPT/ DATE / NN
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
12
© NOKIA
FILENAMs.PPT/ DATE / NN
Pros and cons in rtp usage in signalling
Positive
RTP is well specsed, ready designed
interface
Negative
Originally planned for real time data
transfer
Works on top of UDP => no connection
RTP is used in almost all VOIP solutions.
oriented benefits. No automatic packet
loss detection or resend
Easier to use ready standardized protocol
than try to standardize a completely new
protocol.
RTP header needs only new payload type
for signaling
13
© NOKIA
FILENAMs.PPT/ DATE / NN
RTP header
0
V
PX
CC M Payload type
31
12 Bytes
sequence number
Timestamp
SSRC
Symbol defination and binary value if standard
• V
Version. Identifies the version of rtp
• P
Padding. When set, the packet contains one or more additional padding octetsat the,
end which are not part of the payload
• X
Extension bit. When set the fixed header is followed header is followed by exactly one
extension
• CC CSRC count. Number of CRSC identifiers that follow fixed header
• 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
• 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 defined
dynamically through non-RTP means
• 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
14
lenght in bits
2
1
1
4
1
7
16
•
timestamp
•
SSRC
identifies the synchronization source. This identifier is chosebn randomly, with the
intent that two synchronization sources will have same SSRC identifier
© NOKIA
Reflects the sampling instant of the first octet in the RTP data packet. The
sampling instant must be derived from a clock that increments monotonically
and linearly in time to allow synchronization and jitter calculations.
32
FILENAMs.PPT/ DATE / NN
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.
V
PX
CC M Payload type
Timestamp
SSRC
15
© NOKIA
FILENAMs.PPT/ DATE / NN
sequence number
RTP signaling example 1
Point to multipoint call:
All signaling messages are sent 3 times to avoid packet loss errors
Call setup
1. Leading RTP packet
1. Leading RTP packet
2. Leading RTP packet
2. Leading RTP packet
3. Leading RTP packet
1-3 setup
message
3. Leading RTP packet
Call ongoing
4.Audio packets of the call
4 Audio
packets
4.Audio packets of the call
Call termination
5. Trailing RTP packet
6. Trailing RTP packet
6. Trailing RTP packet
7. Trailing RTP packet
7. Trailing RTP packet
Client 1
16
. 5. Trailing RTP packet
© NOKIA
Server
FILENAMs.PPT/ DATE / NN
5-7 Termination
messages
Client 2
RTP Signaling example 2
Point to point call
All signaling messages are sent 3 times to avoid packet loss errors
When we receive ACK we can stop sending leading RTP
Call setup
1. Leading RTP packet
1. Leading RTP packet
2. Leading RTP packet
2. Leading RTP packet
3. RTP ACK
3. RTP ACK
4. RTP ACK
4. RTP ACK
5. RTP ACK
5. RTP ACK
1-2 setup
message
3-5 ACK
messages to
setup.
6 Audio
packets
Call ongoing
6.Audio packets of the call
6.Audio packets of the call
Call termination
7. Trailing RTP packet
8. Trailing RTP packet
8. Trailing RTP packet
. 9. Trailing RTP packet
. 9. Trailing RTP packet
Client 1
17
7. Trailing RTP packet
© NOKIA
Server
FILENAMs.PPT/ DATE / NN
7-9 Termination
messages
Client 2
General requiremnets for client
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 call
2. Server looks that client receives only one call at the time
3. 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.
18
© NOKIA
FILENAMs.PPT/ DATE / NN
client architecture
Thread 1
Graphical
User
Interface
Noise out
user uses start / end
button to call
Device drivers
Device drivers
Voice in
point to multipoint call
handling
requests and responces
Thread 2
Audio handling part
raw voice
Audio codec
Call state logic
request more data Received signalling
for play out
from server
Audio data
Functions to call sip stack
and call back functions for
sipstack
Call state changes
callback
Thread 3
SIP handler
Audio packets
Jitter Buffer
RTP traffic out
"audio data"
Group and one to one
socket
19
© NOKIA
FILENAMs.PPT/ DATE / NN
Embedded
signalling
Incoming traffic
Socket
U-UPF
Socket
for audio
Socket for SIP
RTP packet handling flow chart when
rtp contains signaling and audio
packets
Network callback, packet arrives
Flow chart for call state logic
shown in previous slide.
IDLE
N
Do we have
incoming call?
Depacketize in
codec module.
N
Does packet contain
embedded signalling
Y
Depacketize
embedded signalling
Y
20
© NOKIA
Handle audio packet
and queue
in order to
jitter buffer
Handle signalling.
Make changes to
call state.
IDLE
IDLE
FILENAMs.PPT/ DATE / NN
Flow chart of audio handling in VOIP
Audio
Audio
Audio device
Audio device
Loudspeaker
Microphone
D/A conversion
A/D conversion
Audio device driver
Audio device driver
Media subsystem
Media subsystem
Decoding
Encoding
Deframing
Framing
Jitter buffer
RTP packetization
RTP depacketization
UDP / IP packetization
UDP / IP depacketization
Network device driver
Network device driver
Network device
Physical transmission
Network device
Physical transmission
internet
21
© NOKIA
FILENAMs.PPT/ DATE / NN
server in
internet
ornothing
internet