point to point and point to multi point calls over IP

Transcription

1 Helsinki University of Technology Department of Electrical and Communications Engineering Jarkko Kneckt point to point and point to multi point calls over IP Helsinki Supervisor: Instructor: Raimo Kantola Heikki Salovuori MSc. 1 NOKIA FILENAMs.PPT/ DATE / NN

2 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 2 NOKIA FILENAMs.PPT/ DATE / NN

3 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

4 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

5 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 5 NOKIA FILENAMs.PPT/ DATE / NN = unicasted voice packet over internet

6 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 Call 2 Which call should be played? How to minimize traffic, especially air traffic to phone? 2. Terminal user is sending one call when new call is starting Call 2 starting Call 1 outgoing Should outgoing call be ended? Should starting call be dropped? 6 NOKIA FILENAMs.PPT/ DATE / NN

7 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

8 protocols in VOIP Signaling H.323 SIP Quality of service RTSP RSVP RTCP Media transport Media encaps (H.261, MPEG) RTP TCP UDP IPv4, IPv6 SIP and rtp handling are in the scope of this work 8 NOKIA FILENAMs.PPT/ DATE / NN

9 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

10 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 because according to protocol we must get acknowledgement from receiver. 10 NOKIA FILENAMs.PPT/ DATE / NN However SIP is very easy to adjust the needs for signaling. Sip can be used as signaling protocol in many different applications. Acknowledgement in point to multipoint calls would introduce unnecessary delays when ack message is waited. Acknowledged setup messages

11 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 on top of RTP. Also completely new protocol could be created on top of UDP. 11 NOKIA FILENAMs.PPT/ DATE / NN

12 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

13 Pros and cons in rtp usage in signalling Positive RTP is well specsed, ready designed interface RTP is used in almost all VOIP solutions. Easier to use ready standardized protocol than try to standardize a completely new protocol. Negative Originally planned for real time data transfer Works on top of UDP => no connection oriented benefits. No automatic packet loss detection or resend RTP header needs only new payload type for signaling 13 NOKIA FILENAMs.PPT/ DATE / NN

14 RTP header 0 31 V PX CC M Payload type Timestamp SSRC sequence number 12 Bytes 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 followfixed 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 defined dynamically 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. The sampling instant must be derived from a clock that increments monotonically and 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 NOKIA FILENAMs.PPT/ DATE / NN

15 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 sequence number Timestamp SSRC 15 NOKIA FILENAMs.PPT/ DATE / NN

16 Point to multipoint call: 1. Leading RTP packet 2. Leading RTP packet 3. Leading RTP packet RTP signaling example 1 All signaling messages are sent 3 times to avoid packet loss errors Call setup 1. Leading RTP packet 2. Leading RTP packet 3. Leading RTP packet 1-3 setup message 4.Audio packets of the call Call ongoing Call termination 4.Audio packets of the call 5. Trailing RTP packet. 5. Trailing RTP packet 6. Trailing RTP packet 6. Trailing RTP packet 7. Trailing RTP packet 7. Trailing RTP packet 4 Audio packets 5-7 Termination messages Client 1 Server Client 2 16 NOKIA FILENAMs.PPT/ DATE / NN

17 Point to point call When we receive ACK we can stop sending leading RTP Call setup 1. Leading RTP packet 2. Leading RTP packet 3. RTP ACK 4. RTP ACK 5. RTP ACK 6.Audio packets of the call 7. Trailing RTP packet 7. Trailing RTP packet 8. Trailing RTP packet 8. Trailing RTP packet Client 1 Server Client 2 17 NOKIA FILENAMs.PPT/ DATE / NN RTP Signaling example 2 All signaling messages are sent 3 times to avoid packet loss errors Call ongoing Call termination 1. Leading RTP packet 2. Leading RTP packet 3. RTP ACK 4. RTP ACK 5. RTP ACK 6.Audio packets of the call. 9. Trailing RTP packet. 9. Trailing RTP packet 1-2 setup message 3-5 ACK messages to setup. 6 Audio packets 7-9 Termination messages

18 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

19 client architecture Thread 1 Noise out Graphical User Interface Device drivers Device drivers Voice in Thread 2 Audio handling part raw voice Audio codec user uses start / end button to call request more data for play out Call state logic Received signalling from server Call state changes callback point to multipoint call handling requests and responces Thread 3 Functions to call sip stack and call back functions for sipstack SIP handler RTP traffic out "audio data" Group and one to one socket Audio data Jitter Buffer Embedded signalling Audio packets Socket Socket for audio U-UPF Incoming traffic Socket for SIP 19 NOKIA FILENAMs.PPT/ DATE / NN

20 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. Depacketize in codec module. IDLE N Do we have incoming call? N Does packet contain Y Depacketize embedded signalling embedded signalling Y Handle audio packet and queue in order to jitter buffer Handle signalling. Make changes to call state. IDLE IDLE 20 NOKIA FILENAMs.PPT/ DATE / NN

21 Flow chart of audio handling in VOIP Audio Audio Audio device Microphone A/D conversion Audio device Loudspeaker D/A conversion Audio device driver Media subsystem Encoding Framing RTP packetization UDP / IP packetization Network device driver Network device Physical transmission internet 21 NOKIA FILENAMs.PPT/ DATE / NN server in internet ornothing internet Audio device driver Media subsystem Decoding Deframing Jitter buffer RTP depacketization UDP / IP depacketization Network device driver Network device Physical transmission