Transcript VoIP CPE Without DSPs

VoIP CPE without DSPs
Rick Bye
Director of Marketing
D2 Technologies, Inc.
[email protected]
www.d2tech.com
VoIP CPE Without DSPs:
Agenda
•
VoIP Endpoint Device Software Overview




Real-time requirements in VoIP




VoIP Endpoint Example, Functionality, Software Blocks
Traditional Software Architecture (RISC + DSP)
New Software Architecture – VoIP on RISC
Hard Real-Time, Soft Real-Time, Best Effort
Toolchain/BSP Considerations
Software Design Considerations
Conclusions
VoIP Endpoint Example:
Analog Telephony Adaptor (ATA)
 Ethernet to FXS adaptor
Optional second Ethernet port for
bridging/routing; FXO for PSTN
 Enables an analog POTS phone to
make VoIP calls


May support FAX
 SIP User Agent application

Computer
Cable / DSL
Modem
Uses SIP protocol to establish calls
 Implements many CLASS features

WIFI Router
Call Waiting, Caller ID, 3-way Calling,
Call Transfer, Call Forwarding, etc
Analog
Telephony
Adaptor (ATA)
Phone
Other Endpoint examples







Router with VoIP
WiFi Router with VoIP
Cordless/DECT ATA
WiFi handset
Dual mode phones
VoIP enabled PDAs, Game Units, MP3 players…
Etc etc.
Legacy HW/SW Architecture:
RISC + DSP
Voice Application
DSP
Algorithm
Voice Signalling
Protocol
(SIP, H323,
MGCP)
Voice Packetization
RTP
Jitter Buffer
V
IP Stack, NAT
DSP
Algorithm
Channel
Driver
Host
Interface
DSP
Application
O/S Adaptation Layer
DSP
Driver
DSP
Algorithm
Host
Driver
Audio/
Telephone
Interface
Driver
O/S
Host Processor
RISC Processor Responsible for:
 Voice Application, Protocol
 IP Stack, Data/Voice Packets
 DSP Driver
DSP Processor
DSP Processor Responsible for:
 Hard real-time telephony interface
 DSP algorithms (MHz intensive)
 Separate DSP application

Required to be semi-autonomous
FXO
FXS
SPKR/
MIC
New SW/HW Architecture:
Single CPU
Voice Application
Voice Signalling
Protocol
(SIP, H323, MGCP)
Soft DSP
(DSP Algorithms, Voice Packetization,
RTP, Jitter Buffer)
V
O/S Adaptation Layer
IP Stack, NAT
O/S
SoC Processor
Audio/
Telephone
Interface
Driver
FXS
FXO
SPKR/
MIC
Single CPU
Advantages / Challenges
 Advantages:




Eliminates DSP lowering
overall cost
Leverages existing chips
No Interprocessor
communication
Single Tools /
Development Environment
 Challenges:



Hard real-time
requirements
MHz burden on RISC
Data/Voice/Application
software must co-exist
Information Flow in VoIP
Commands/Events
(10's of ms)
Voice Blocks
(10 ms)
Voice
ISR
Voice
Application and
Protocol
Voice
Processing
Task
SIP Packets
(100's of ms)
Voice Packets
(< jitter buffer size)
Voice Samples
(125 us)
Network
Driver
Voice Packets
(< jitter buffer size)
CODEC
Network
Interface(s)
Data Packets
(Best Effort)
Legend
Hard Real-time
Soft Real-time
Best Effort
Hard Real-Time in VoIP
 Hard Real-Time definition

Deadline-based processes in which a failure to meet the
deadline will result in loss of voice data and
unacceptable system behavior.
 Hard real-time requirements in VoIP:


Telephony Driver
DSP Algorithms
Hard Real-Time Requirement:
Telephony Driver
 Telephony Driver: Transmits voice samples to/from the hardware codec

Synchronous serial interface, 64_kbps per channel
• 8000 samples/s, 8 bits/sample
• One sample transmitted/received every 125 us
 Failing to copy a sample before the 125us deadline will result in a
dropped voice sample

Resulting impacts on voice quality
•
•
•
•

Can be a noticeable click.
Echo canceller can fail, resulting in perceptible echo to far end.
FAX pass-through or FAX Relay can fail.
Causes drift in jitter buffers, which will cause dropped packets if
If subsequent deadlines are missed (domino effect), call failure and system
instability can result.
Hard Real-Time Requirement:
DSP Algorithms

DSP Algorithms process the voice stream from the Telephony Driver and from
the IP stack to do:



Voice Compression
Echo Cancellation
Tone Generation / Detection
•


Packet Loss Compensation
Nature of communication: Block based processing



DTMF, FAX/Modem, Call Progress, Caller ID
Typically 80 voice samples per block
One block processed every 10 ms
Failure to complete DSP algorithm processing by the end of the 10 ms deadline
results in:





Telephony driver will play out old data to hardware CODEC.
Far side also gets bad data due to loss of codec data.
Echo canceller can diverge, causing echo to be heard on subsequent blocks.
Tone detection can fail, resulting in mis-detection of DTMF digits or FAX tones.
Again, if subsequent deadlines are missed (domino effect), call failure and system
instability can result.
Soft Real-Time in VoIP
 Soft Real-Time definition:

Processes which should execute in a timely manner, for
which system behavior degrades (but may not be
unacceptable) if the deadline is missed.
 Soft real-time requirements in VoIP:


Voice Packetization and Transport
Voice Application and Protocol
Soft Real-Time Requirement:
Voice Packetization and Transport


Voice packetization and transport: Packetize the compressed audio and send it
out the IP interface; alternatively, receive a packet from the IP interface and
provide it to the VoIP software.
Nature of communication:



Deadline for processing:


Transmission: Normally, one packet ready every 10, 20, or 30 ms.
Reception: Subject to network jitter, one every 10, 20, or 30 ms.
Processing should complete within the packet duration (10, 20, 30 ms), in order to
keep from getting behind.
Repercussions of failure to meet deadline:


May be handled by the Jitter Buffer on the receiving side.
Best-case
•
•

Missing deadline causes jitter buffer to grow, but does not cause lost packets;
Results in increased latency because of a larger jitter buffer.
Worst-case
•
•
Missing deadline causes jitter buffer to discard a too-late packet;
Packet loss compensation used to minimize impact on voice quality.
Soft Real-Time Requirement:
Voice Application and Protocol
 Nature of communication:

Responds to reception of SIP packets, telephony events, and internal timers
in order to drive Telephony Application functionality.
 Deadline for processing:


Processing should be responsive enough for successful user experience.
Certain time-outs exist in SIP; however, retransmission techniques in the
protocol allow recovery of some missed deadlines.
 Repercussions of failure to meeting deadline:


Noticeable lack of responsiveness of device.
Call failures are possible for excessive delays.
 However, voice application and protocol deadlines are typically on the
order of hundreds of milliseconds to several seconds.

As long as the Voice Application and Protocol are not blocked indefinitely,
they should meet timing requirements.
Best Effort in VoIP
 Best Effort definition:

Processes for which there is no deadline, but for which
faster execution results in better system performance.
 Best Effort requirements in VoIP:

Data IP Packet Transport
Best Effort Requirement:
Data Packet IP transport
 Data Packet IP transport: Process the reception,
transmission, forwarding, and bridging of TCP packets.
 Nature of communication:


Packets can be received at wireline speeds (e.g. 100 Mbps).
Device processes as many packets as it can, discarding others.
 Deadline for processing:

No deadline for processing, other than TCP ACK timeout.
 Repercussions of failure to meeting deadline:


TCP packets retransmitted.
Lower data bandwidth.
 These repercussions are intentional and acceptable.
Implications of Real-time
Requirements
 A VoIP device has multiple processes with different
MHz consumption and real-time needs.
 This places stringent requirements on the OS, BSP,
Memory, Cache, other software running on the
RISC core, and the SoC design itself.

Each of these areas needs careful consideration.
 This requires a system-wide approach rather than
ad-hoc optimization of each piece.
Toolchain / BSP Considerations:
RTOS
 OS requirements:



Guaranteed worst-case task switch latency that meets the VoIP latency
deadlines.
A preemptive kernel.
A scheduler that prioritizes real-time tasks above non real-time tasks.
 Examples:



Wind River VxWorks
MontaVista Linux (contains real-time improvements in the 2.6 Linux kernel)
Others (Nucleus, SuperTask, eCOS)
 Final OS choice involves cost tradeoffs:




License/royalty cost
Flash / Memory footprint.
Strong Tools Development Environment.
Bundled network/application software can lower development costs.
Toolchain / BSP Considerations:
Optimizing Compiler
G729AB relative MHz consumption due to C vs. Assembly
Implementation
100%
95%
Relative MHz
90%
85%
80%
75%
70%
65%
60%
55%
50%
Optimized C
Implementation
Mixed C/Assembly
Implementation
Full Assembly
Implementation
Toolchain / BSP Considerations:
Peripheral Drivers
 Peripheral drivers (Ethernet, Serial, USB, etc) may
have a hard real-time impact on Voice software:

Peripheral ISR’s can hold off tasks past deadlines.
 To avoid this, peripheral drivers may have to be
modified to:


Separate the time critical portions of the driver from
portions that can be run at lower priority.
Minimize the task latency imposed on real-time VoIP
processes due to ISR’s.
Software Design Considerations
 VoIP Software Partitioning


VoIP software should be partitioned into different tasks based on
priority, not function.
This minimizes the MHz consumed in hard real-time tasks
• This decreases negative effects due to the latency it imposes on other tasks.
 Task Priority Organization

Care has to be taken to make the optimal priority assignments for
each task.
• Sub-optimal assignment of task priorities can easily result in 40% higher MHz
load due to the creation of unnecessary task switching.
Conclusion
 Single-core, RISC SoC’s are the new
approach for low-cost VoIP endpoints.
 Combining Voice, Data, and Application
Software has challenges.
 A strong systems-level approach is required
to conquer the challenges.
Thank You
Rick Bye
Director of Marketing
D2 Technologies, Inc.
[email protected]