Final Year report on EPABX system

(1)

Final Report

V

o

I

P

S

o

f

t

P

B

X

Project Code: SPBX

Project Advisor: Aftab Alam

Project Team:

Umair Ashraf 03-1853 (Team Lead)

Khadija Akram 04-0080

(2)

Acknowledgements

We would like to thank our respected internal faculty advisor Mr. Aftab Alam for his continuous support and guidance throughout the project. We also appreciate the confidence shown by him on our team.

We would also love to acknowledge the support, guidance and help by our external advisor Mr. Asad Gill. He helped and taught us the basic ideas of voice over IP. He also helped us in formulizing the ideas of project into reality.

We also acknowledge the efforts and contributions of our project manager Mr.Yasir Aleem towards this project. In spite of his short stay with us, he guided us very efficiently and his advices helped us to produce more fruitful and better results.

Team Project PBX 12-6-08

(3)

Document Information

Information

Customer FAST-NU

Project Soft PBX

Document Final Report

Document Version 1.0

Identifier SPBX

Status Draft

Author(s)

Umair Ashraf (Team Lead) Khadija Akram

Imran Bashir

Approver(s) Aftab Alam

Issue Date June 10, 2008

Distribution Advisor & Library

Definition of Terms, Acronyms and Abbreviations

Term Description

RS Requirements Specifications

PBX Private Branch Exchange

SIP Session Initiation Protocol

RTP Real Time Protocol

VOIP Voice over IP

IETF Internet engineering Task Force

(4)

9.11.1 Approach ... 52 9.11.2 Entrance Criteria ... 52 9.11.3 Exit Criteria ... 52 9.12 Sanity Testing ... 53 9.12.1 Approach ... 53 9.12.2 Entrance Criteria ... 53 9.12.3 Exit Criteria ... 53 9.13 Data Verification ... 53 9.13.1 Approach ... 53 9.13.2 Entrance Criteria ... 53 9.13.3 Exit Criteria ... 54 9.14 Defect Tracking ... 55

9.15 Guidelines for Assigning severity to a defect ... 57

9.16 Test Suspension and Resumption Criteria ... 58

9.17 Schedule Overview ... 59

9.18 Testing Resources ... 59

9.19 Summary ... 60

10. TEST CASES ... 61

10.1 Dial and Place Call... 61

10.2 Transfer Call ... 65

10.3 Call Conference ... 67

10.4 Phone Book ... 69

10.5 Soft Phone Configuration ... 74

10.6 PBX Configuration ... 79

10.7 PBX Admin Login ... 81

10.8 Create Dial Plan ... 83

10.9 CDR (Call Detail Reporting) ... 85

10.10 Register User ... 87

10.11 Receiving/rejecting a call ... 91

10.12 Speed Dial ... 94

10.13 Missed Calls ... 96

10.14 Terminating the call ... 98

10.15 Call Hold ... 100

11. Appendix ... 102

(7)

1

1. Introduction

VoIP is simply the transport of voice traffic by using the Internet Protocol (IP). It is a technology that allows you to make voice calls over a broadband internet connection instead of a regular phone line. In VoIP your voice is converted into a digital signal that travels over the internet. If you are calling a regular phone number (i.e. on a PSTN), the signal is converted to a regular telephone signal. [Reference 1]

Why should we use VoIP?

Traditional telephony carriers use circuit switching for carrying voice traffic. Circuit switching was designed for voice from the outset; hence it carries voice in an efficient manner. However it is an expensive solution. Nowadays people want to talk much more on phone, but they also want to communicate in a myriad of other ways – through e-mail, instant messaging, video, the World Wide Web, etc. Circuit switching is not suitable for this new world of multimedia communication.

IP is an attractive choice for voice transport for many reasons, including the following:-

Lower equipment cost

Integration of voice and data applications Lower bandwidth requirements

(8)

Lower Equipment Cost

The IP world is different from the monolithic systems of mainframe computers and circuit-switching technology. IP systems tend to use distributed client-server architecture rather than large monolithic systems, which means that starting small and growing as demand dictates is easier. IP architectures and standards are more open and flexible plus they are competition friendly, than telephony standards, enabling the implementation of unique features so that a provider can offer new features more quickly. Hence, the range of choices is large; the equipment cost is drastically lower than that of circuit switching products; and the pace of development is incredibly fast.

Voice/Data Integration and Advanced Services

IP is the standard for data transactions- everything from mail to web browsing to e-commerce. When we combine these capabilities with voice transport on a single network, we can easily imagine advanced features that can be based on the integration of the two.

Lower Bandwidth Requirements

Circuit-Switched telephone networks transport voice at a rate of 64 Kbps. Typical human speech has a bandwidth of 4000 Hz, when we would digitize this voice a telephone system would take 8000 samples per second.

In VoIP we can use coding schemes which enable speech to be transported between 6 Kbps to 32 Kbps. Therefore, VoIP offers significant advantages over circuit-switching from a bandwidth point of view. However we would be using G.711 for this purpose which is also at a rate of 64 Kbps.

Widespread availability of IP

IP is practically everywhere. Every personal computer produced today supports IP. IP is used in corporate LANs and WANs, dial-up internet access etc. As a result there is widespread availability of IP expertise and numerous application-development

(9)

2. Goals and objectives

Our primary goal is to gain a thorough understanding of the VoIP. We would be learning and implementing RTP (Real Time Protocol) and SIP (Session Initiation Protocol).We would be learning the different mechanisms and flows involved in the transference of voice over the internet. We would gain complete insight of the complete mechanism of communication between the Soft Phones and the working of the Soft PBX.

3. Scope of the project

Vision and Scope

The Virtual PBX (Private Branch Exchange)

Numerous IP based PBX solutions are in place and more are being deployed daily. The idea of an IP-based PBX is useful. Firstly, this system integrates the corporate telephone system with the corporate computer network, removing the need for two separate networks. A new office is wired for voice communication, as well. The PBX itself becomes just another server or group of servers in the corporate LAN, which helps to facilitate voice/data integration.

We would be implementing a soft PBX that is going to be a server that performs call-routing functions, replacing the traditional legacy PBX or key system. Our PBX would allow a number of attached soft phones to make calls to one another and to connect to other telephone services.

The basic software would include many features available in proprietary PBX systems: voice mail, conference calling, interactive voice response, and automatic call distribution, just to name a few. Our system would also help the user in building the dial plan for the network.

We would be using the Session Initiation Protocol [See Appendix for more details] as our VoIP protocol. Our PBX would be acting as both the registrar and as a gateway between

(10)

4. Functional Requirements

4.1 Registering a user

The system shall allow a user (caller or callee) to register it to the PBX by its IP Address and caller ID through a soft phone.

The user will set a specific IP address, caller id, and password and caller name in the configuration of the soft phone. After applying these configurations, the soft phone will send a request to the soft PBX and the PBX in response will register the user.

4.2 Dialing and placing Call

The system shall allow users to dial and place a call to each other using Soft phones through a PBX over the Network (internet or intranet)

The caller dials the number and the number will be displayed on the screen and then the user presses the call button and the call will be placed to the specific callee and the session information will be displayed to the caller on the screen of his/her soft phone.

4.3 Accepting (call pick up) /rejecting a call

The system shall allow the user to receive or reject a call of the caller using Soft Phone. For the incoming call, the callee will receive a notification of the incoming call through the ringing tone and information will also be displayed on the screen. The callee can either reject or receive the call. Incase he receives the call a communication session will be established between the caller and the callee. Incase the callee rejects the call the information of the missed call will be updated in the missed call log.

4.4 Terminating the Session

The system shall allow the user to terminate the call at any time.

If a call is already established between the caller and the callee, both of them shall be able to terminate the session at any time. In this case the session will be terminated and both

(11)

4.5 Voice Conferencing

The System shall allow users to have voice conferencing service amongst multiple users at a time.

There will be a specific conferencing no that will be set in the multi conferencing unit. The caller shall be able to join the conferencing session by dialing that conferencing no. In this case a request will be sent to the multi control unit by the PBX to join the conferencing session.

4.6 Missed Call Alert

The System shall support missed call service and provide the information of the missed calls to the user.

4.7 Call Hold

The system shall provide the station user, to hold a call in progress, the ability to dial either an appropriate hold code, or to depress a feature button which would place the call in progress on system hold, and allow the station user to: (1) originate another call or, (2) use any other features provided by the system.

4.8 Call Detail Reporting (CDR)

The PBX shall be equipped to capture Call Detail information. The information to be captured shall as a minimum provide:

Date of Call (Month and Day) Calling Station Number

Called Number (all depressed digits) Time (Time Call Was Placed)

Duration of Call (Minutes and Seconds)

4.9 Caller identification

The System shall allow the user to get the information of the caller person like his/her caller id and the name.

(12)

All the information related to caller person will be displayed on the screen for the callee. 4.10 Dial Plan

The System shall provide complete dial plan option to the users.

The administrator can generate caller ids in different formats like for a particular department the caller id shall start from the number 3 and the caller id number could be in different lengths according to the plan generated by the administrator.

4.11 Speed dialing

The system shall support the services of the speed dialing through a PBX.

4.12 Administrative and management services

The system shall provide the administrative and management services of the PBX like changing dial plans, managing users, managing passwords and creating call Detail Reporting services.

4.13 Phone book service

The system shall support and provide phone book service to the users.

4.14 Call Recording

The system shall allow the user to record the call of the conversation.

4.15 Call Transfer

The system shall allow the user to transfer his/her call to another user at a different location.

4.16 Call forwarding

(13)

5. Non Functional Requirements

5.1 Performance and Reliability

System must be scalable up to 50 devices per PBX.

The system must ensure that sending and receiving packets are not discarded, and a mechanism must be adopted so that packet loss and retransmission should not occur due to algorithm used in the application otherwise, voice quality or service disruptions might occur.

The jitter buffer (see appendix for details) configuration must be implemented in the software to avoid packet delay which should not be more than 100 millisecond between the two consecutive packet transmissions otherwise quality of voice may drop.

The system must ensure to utilize as low bandwidth of the network as possible. In order to prevent high traffic over the internet by the application some compression codec‟s like G.729 (see appendix for more details) shall be supported by the system.

5.2 Robustness

The system should support proper exception handling like incase of unavailability of Network.

5.3 Security

The system shall provide complete security and privacy to the users and no other party shall be allowed to listen to the conversation between the two end users.

(14)

5.4 Standards compliance

The system shall fulfill all the standards of the IEEE and IETF.

The system shall support all standard protocols like SIP and RTP protocols. (See Appendix for details).

5.5 Usability

The system must be providing user-friendly interface to the end users. A dial pad and telephone like features must be provided with the interface so as to provide the end user a Complete Soft phone on his/her desktop.

The system shall provide an interface to the Administrator to maintain and configure the system.

5.6 Portability

(15)

6. Hardware Requirements

Pentium 4 system with at least 512 Mb of Ram Full duplex Sound Card

A Conventional LAN based network or Intranet. 100 Mbytes of Disk space

7. Software Requirements

The system shall be developed in rapidly growing and cutting edge technology of .Net and C sharp framework.

(16)

8. Detailed Design and Architecture

8.1 Use Case Diagram

Soft PBX

Place phone Call

Caller Callee Forward Call Missed Call Register user Receive Call

Call Deatail Report

Place coference Call Terminate call «extends» Record Call Accept Call Reject Call Hold Call Phone Book «uses» Operator Change User Change MCU no Music Unhold End Conference Call

Remove User

«uses» «uses» Unhold Call

(17)

8.2 Use Case Description

(18)

(19)

(20)

8.2.3 Use Case Missed calls

Use case Id 3:

Missed Calls

Actors: <user>

Feature: This will allow the user to see the missed calls on the soft phone. Use case Id: 3

Pre-condition: -

Scenarios

Step# Action Software Reaction 1. The use case starts when the callee

wants to see the missed calls on his phone.

2. User directs the soft phone to display missed calls by pressing misses call button.

The soft phone will display the missed calls on the display screen.

The use case ends.

Alternate Scenarios: None

Exceptions: None

Post Conditions

Step# Description

1- Soft Phone will display the missed calls.

Use Case Cross referenced None Concurrency and Response

Number of concurrent users

The system will support maximum 50 users. Expected response time of the use case The response time will be 1 second.

(21)

8.2.4 Use Case Register User

Use case Id 4:

Register User

Actors: <User>

Feature: This will allow the user to register itself to the PBX. Use case Id: 4

Pre-condition: The user must be authorized caller id to register to the system

Scenarios

Step# Action Software Reaction 1. The use case starts when the user

wants to register itself to the system

2. The user presses the register a user button.

System displays a dialogue box to enter the ip address and the port no

3- The user enters the port no and the ip address of the user by pressing the continue button. Alternate-1

System will successfully register the user. Exception-1

The use case ends.

Alternate Scenarios:

none

Exceptions:

1-The user did not enter the valid port no or ip address and repeats step 2.

Post Conditions

1- System will successfully register the user.

Use Case Cross referenced

none

Concurrency and Response

The system will support maximum 50 users. Expected response time of the use case The response time will be 1 second.

(22)

8.2.5 Use Case Generate Report

Use case Id 5:

Generate Report

Actors: <operator/administrator>

Feature: This will allow the operator to generate a report. Use case Id: 5

Pre-condition: The operator must be logged in.

Scenarios

Step

# Action Software Reaction

1. The use case starts when the operator wants to generate the report of the calls.

2. The operator presses the report generate button.

System displays a dialogue box to enter specific duration.

3- The operator enters the duration. System will successfully generate the CDR (call data Report).

Exception-1

The use case ends.

none

Exceptions:

1-The operator did not enter the valid duration.

Post Conditions

Step

# Description

1- System will successfully generate the report.

Use Case Cross

referenced none Concurrency and Response

(23)

8.2.6 Use Case Call Transfer

Use case Id 6:

Call Transfer:

Actors: < User>

Feature: This will allow the user to transfer his/her call to another location. Use case Id: 6

Pre-condition: The user should be having the established communication session.

Scenarios

Step

1. The use case starts when the user wants to forward his/her call to another location by pressing call transfer button.

2.

3.

User presses the transfer button to transfer the call.

User Enters the caller id of the person to whom the call is being transferred.

The system will ask for the caller id where the call is being transferred.

The system will transfer the call to another location and notifies the user that the call is being forwarded. (Exception-1)

(Exception-2) The use case ends.

None

Exceptions:

1- The network is busy or is not available and system will generate exception error. 2- The caller id does not exist and user repeats step3.

Post Conditions

Step

# Description

1- System will transfer the call to another location and the caller will be idle.

Use Case Cross

The system will support maximum 1 user. Expected response time of the use case The response time will be 1 second.

(24)

8.2.7 Use Case call conferencing

Use case Id 7:

Call Conferencing

Feature: This will allow the user to have call conferencing Use case Id: 7

Pre-condition: The user must be registered to the PBX

Scenarios

Step #

Action Software Reaction

1. 1-The use case starts when the user wants to have call

conferencing

2. 2-User dials the conferencing

id ( MCU caller ID) System connects the user to the conferencing session. (Exceptions 1,2,3)

The use case ends.

None

Exceptions:

1- The system generates error that the conferencing id is incorrect and the user repeats step 2

2- The system generates error that the network is unavailable.

3- The system generates error that the maximum no of users are already having the conferencing call over the same conferencing id.

Post Conditions : none

Use Case Cross

referenced Includes <placing and dialing a call> Concurrency and Response

Number of concurrent users = 5

Expected response time of the user case 3 seconds

(25)

8.2.8 Use Case Call Recording

Use case Id 8:

Call Recording

Actors: < Caller,Callee>

Feature: This will allow the user to record the call of conversation. Use case Id: 8

Scenarios

Step

1. 1-The use case starts when the user wants to record a call of conversation.

2. 2-User by presses the call

record button. 3-The soft phone will record the call of conversation, stores it in a file and notifies the user that the call of

conversation is being recorded. (Exceptions-1)

The use case ends.

none

Exceptions:

1- System does not record the call of conversation.

Post Conditions :

Step #

Description

1- Soft PBX will have the record of the call of conversation.

none

The system will support at max 1 recording at a time.. Expected response time of the use case

(26)

(27)

8.2.10 Use Case Call Hold

Use case Id 10:

Call Hold

Feature: This will allow the user to hold a call. Use case Id: 10

Scenarios

Step

1. The use case starts when the user wants to hold a call.

2. User presses the call hold button. System will hold the call for the user and play hold music.

Execption-1

The use case ends.

Alternate Scenarios: None Exceptions: none Post Conditions : Step # Description

1- System will hold the call for the user.

None

Number of concurrent users 50

Expected response time of the use case The response time will be 2 seconds.

(28)

8.2.11 Use Case Call Unhold

Use case Id 11:

Call Un Hold

Feature: This will allow the user to Un hold the call. Use case Id: 11

Pre-condition: The call must be hold first to initiate this use case.

Scenarios

Step #

Action Software Reaction

1. The use case starts when the user wants to un hold the call and talk to another user

2. User presses un hold button. System will again establish a

communication session between the calle and the caller.

Exception-1

The use case ends.

None

Exceptions:

1- The system could establish the session with the callee as the network is unavailable.

Post Conditions: The caller and callee will be having the communication session

again after the un hold operation.

Use Case Cross

referenced Includes < dialing and placing a call> Concurrency and Response

(29)

8.2.12 Use Case terminating the call

Use case Id 12

:

Terminating the call Actors: < User>

Feature: This will allow the user to terminate the call. Use case Id: 12

Scenarios

Step

1. 1-The use case starts when the user wants to terminate the call.

2.

User presses the cancel button to terminate the call.

System will disconnect the call and

display the user that the call is connected. The use case ends.

Alternate Scenarios: none Exceptions: none Post Conditions : Step # Description

1- System will not maintain the communication channel anymore.

Use Case Cross

(30)

8.2.13 Use Case Call forwarding

Use case Id 13:

Call forwarding

Actors: < operator/administrator>

Feature: This will allow the user to forward the call of a user to another location. Use case Id: 13

Pre-condition: The administrator must be logged in

Scenarios

Step# Action Software Reaction 1. The use case starts when the user

wants to forward the calls to another caller id.

2.

3.

User presses the call forward button to forward the call.

User Enters the caller id and the id of the person to whom the call is being forwarded.

The system will ask for the caller id and the id where the call is being forwarded of that caller id

The system will forward and route the call to another location and notifies the user that the call is being forwarded. (Exception-1)

(Exception-2) The use case ends.

Alternate Scenarios: None Exceptions: none Post Conditions Step# Description

1- System will forward the call to another location and the caller will be idle.

Use Case Cross

(31)

8.2.14 Use Add caller id/dial plan

Use case Id 14:

Add caller id/dial plan

Feature: This will allow the operator to add a caller id to the system. Use case Id: 14

Scenarios

Step

1. The use case starts when the operator wants to adds a caller id or dial plan

2. The operator presses the add button

System displays a dialogue box to enter the caller id and the ip address

3- The operator enters the caller id and the ip address of the user by pressing the continue button. Alternate-1

System will successfully enters the new entry in the dial plan

Exception-1

The use case ends.

none

Exceptions:

1-The user did not enter the valid caller id or ip address or the caller id and the ip address already exists.

Post Conditions

Step #

Description

1- System will successfully register the user.

Use Case Cross

(32)

8.2.15 Use Case Change caller id/dial plan

Use case Id 15:

change caller id/dial plan

Feature: This will allow the operator to change a caller id to the system. Use case Id: 15

Scenarios

Step# Action Software Reaction 1. The use case starts when the

operator wants to change a caller id or dial plan

2. The operator presses the add button

System displays a dialogue box of all the registered caller ids and their ips

3- The operator selects caller id and the ip address of the user by pressing and enter the new values Alternate-1

System will successfully enters the new entry in the dial plan

Exception-1

The use case ends.

none

Exceptions:

1-The user did not enter the valid caller id or ip address or the caller id or the ip address already exists.

Post Conditions

1- System will successfully change the dial plan.

Use Case Cross

(33)

8.2.16 Use Case Delete Caller id /dial plan

Use case Id 16:

delete caller id/dial plan

Feature: This will allow the operator to delete a caller id to the system. Use case Id: 16

Scenarios

Step

1. The use case starts when the operator wants to delete a caller id or dial plan

2. The operator presses the add

button System displays a dialogue box of all the registered caller ids and their ips

3-

4-

The operator selects caller id and the ip address of the user and presses the delete button.

The user confirms by clicking yes Alternate 1

The system will display a confirmation dialog box

System will successfully delete the entries Exception-1

The use case ends.

1 The user presses the cancels button.

Exceptions:

none

Post Conditions

Step

# Description

1- System will successfully delete the dial plan.

Use Case Cross

(34)

8.2.17 Use Case Change hold on music play list

Use case Id 17:

change hold on music play list

Actors: <operator/administrator>

Feature: This will allow the operator to change the hold on music of the system. Use case Id: 17

Scenarios

Step# Action Software Reaction 1. The use case starts when the operator wants

to change a music play list

2. The operator presses the hold on music button

System displays a dialogue box to the give the new file for hold on music

3- The operator gives the path of new file Alternate-1

System will successfully enters the new music file for hold on music

Exception-1 The use case ends.

1 The operator cancels the operation.

Exceptions:

1-The user did not enter valid path or file and system generates the error.

Post Conditions

Step# Description

1- System will successfully change the dial plan.

(35)

(36)

8.3 Class Diagrams

8.3.1 Soft PBX

(37)

(38)

8.4 Sequence Diagrams

(Call Flow Diagrams)

8.4.1 Bye Call PBX Soft Phone (Caller) Soft Phone (Callee) SIP BYE BYE SIP 200 OK SIP 200 OK Release Release Complete

(39)

8.4.2 Cancel Call Soft Phone (Caller) PBX Soft Phone (Callee) : Callee Dial Callee

Press Cancel Call Buttion

cancel

SIP OK 200

Cancel SIP OK 200

(40)

8.4.3 Invite Call

Soft Phone (Caller)

PBX Soft Phone

(Callee)

SIP Invite (callee #)

SIP 100 Trying Invite Call Proceding Progress SIP 180 Ringing SIP 180 Ringing Connect Connect ACK SIP 200 OK SIP ACK

(41)

8.4.4 MOH Sequence Diagram SIP OK 200 Soft Phone (Caller) PBX MOH (Music on Hold) : Callee

Press HOLD Buttion

Request For MOH

(42)

8.4.5 Receive Call

Soft Phone (Caller) PBX Soft Phone (Callee) : Callee

Click on receive Buttion

(43)

8.4.6 Register

Soft Phone (Caller)

: Callee PBX

Set Caller ID and Password

Register SIP OK 200

Options

(44)

8.4.7 Reject Call

Soft Phone (Caller) PBX Soft Phone (Callee) : Callee

Click On Reject Buttion

SIP BYE

Disconnect RX\TX Connection SIP OK 200

BYE SIP OK 200

(45)

Basic Sequence Diagrams

8.4.8 Callee RTP Process

: Callee RTP Processor CSocket JitterBuffernode Audio Device Audio codec

Start Streaming()

Open Audio Device() Output Data()

DecodePacket() Creat Socket()

Start session

(46)

8.4.9 Caller RTP Process Diagram

RTP Processor Audio Device Audio codec CSocket JitterBuffernode

: Caller InputAudiao() Creat Socket() StartSession OpenDevice() close device Encode Data() AddPacket() CloseSocket()

(47)

8.4.10 Dialed Call Sequence Diagram

: Callee : softphoneapp SIP Engin :

SIPMessageGenerator : InviteStruct : PacketHeader CSocket PBXengine Dial Caller No Place Call Dial Call() Initiate() _Makeinvite() generateMessage() _{CreateInviteStruct()} ConstructPacket() CreateSocket() SendPacket()

(48)

8.4.11 Receive Call Sequence Diagram

: Callee : PBXengine : SIP Engine CSocket : SIP parser : MAP CallNode : SIPcallState Machine SIP Message Generator Softphoneapp CreateSocket() Receive Packet() Parse Message() UpdateMap() Generate Message() UpdateNode() GenerateState() SendPacket() Click on Receive Buttion

Initiate

(49)

8.4.12 Conference Call Sequence Diagram

: Caller/callee : softphoneapp PBXengine SIP Engin MCU

Click on Hold Option

Initiate _MakeInvite()

startConference Call()

8.4.13 Music on Hold Call Sequence Diagram

: Caller/callee : softphoneapp PBXengine SIP Engin MOH

Click on Hold Option

Initiate _MakeInvite()

PlayMusic()

(50)

8.5 Context Diagram

Soft Phone Soft PBX Soft Phone

Rx/Tx UDP Connection SIP SIP R e g is te r u s e r, E d it u s e r, G e n e ra te C D R , C h a n g e M u s ic Operator _Callee Caller D ia l C a ll, H o ld C a ll, M is s e d C a ll T e rm in a te C a ll R e c e iv e C a ll, R e je c t, C a ll H o ld C a ll, T ra n s fe r C a ll

(51)

8.6 Data Flow Diagrams

8.6.1 Level 0 Data Flow Diagram

Soft Phone Soft PBX Soft Phone

Rx/Tx UDP Connection SIP SIP R e g is te r u s e r, E d it u s e r, G e n e ra te C D R , C h a n g e M u s ic Operator Callee Caller D ia l C a ll, H o ld C a ll, M is s e d C a ll T e rm in a te C a ll R e c e iv e C a ll, R e je c t, C a ll H o ld C a ll, T ra n s fe r C a ll

(52)

8.6.2 Level 1 Data Flow Diagram Soft PBX Multipoint Control Unit (MCU) PBX Engine

Soft Phone SIP SIP Soft Phone

Add, Delete & Update User Request Display Updated User Status Change Music & Music No Update Music Status Generate Report Display Report Log Generator R e q u e s t fo r C D R ( C a ll D e ta il R e p o rt ) C h a n g e M u s ic N o U p d a te M u s ic N o D is p la y C D R ( C a ll D e ta il R e p o rt ) R e q u e s t fo r C o n fe re n c e C a ll P la c e C o n fe re n c e C a ll

Music on Hold (MOH)

R e q u e s t fo r M O H P la y M u s ic Callee Caller D ia l C a ll , H o ld C a ll , M is s e d C a ll , T e rm in a te C a ll R e c e iv e C a ll , R e je c t, C a ll H o ld C a ll , T ra n s fe r C a ll Rx/Tx UDP Connection

(53)

8.6.3 Level 2 Data Flow Diagram

PBX SIP Engine

SIP Engin SIP Message Generator MAP SIP Parser MOH MCU

Request For Map Request for Music on Hold

Parse Message Generate Message

Generate State Machine

Request for Conference Call

Call Node Change Music Track

Music on Hold Update Music track

Make Request Update state

Make Conference Call

Update Map U p d a te s ta te

Request to update node

(54)

RTP Processor

JItterBuffer RTP processor Audio Device CSocket Add Packet Get Packet Stream out Stream in

(55)

9. Test Plan

9.1 Purpose

This document is developed to act as a QA plan for soft phone and soft PBX, being developed for Aftab Alam (Project Advisor).

9.2 Scope

The document defines the scope, methodologies, resources and deliverables of testing activities to be undertaken for the application. This document encompasses the items being tested and the testing tasks to be performed to ensure the quality of the system. 9.3 Source Documents

Requirement Specification Document Functional Specification Document 9.4 Derived Documents

None

9.5 Assumptions/Limitations It is assumed that

The system would work under all Microsoft operating systems like windows XP or windows 2000

Pentium 4 system with at least 512 Mb of Ram Full duplex Sound Card

A conventional LAN based network or Intranet 100 Mbytes of disk space

9.6 Modules to Be Tested

(56)

Number Module / Task Name

1

Dial call/Place a call, Call conference, Call transfer, Call Record(Soft Phone )

2

Phone book service/Search person‟s number, add person‟s number(Soft Phone )

3

Soft phone configuration module/Soft phone

Configuration(Soft Phone )

4 Register user/Registering user to the PBX(Soft Phone )

5 Call detail reporting/Call information(Soft PBX)

6- PBX configuration module/PBX configuration(Soft PBX)

7- Admin Login(PBX)

8- Create dial plan(PBX)

9.7 Features not to be tested

Call hold/Call hold, Talking to another user during call hold(Soft Phone ) Missed calls/View missed calls(Soft Phone )

Receive a call/receive call, Terminate a call(Soft Phone ) MOH(Soft PBX)

MCU(Soft PBX)

Sip engine generator(Soft PBX) Call recording/Record call(Soft PBX)

9.8 Strategy

For each test type following strategy will be followed.

9.9 Functional Testing

The purpose of functional testing is to reveal defects related to the component‟s functionality. It aims to assist in ensuring that the item under test conforms to the source documents.

(57)

9.9.1 Approach

Test cases will be based on source documents to cover the functionality for each module. Two test cycles would be conducted for each of the new module/task. One test cycle would be conducted to verify the bugs, which remained open in system. Testing methodology that would be used is black box testing. We would not be doing white box testing since we are constrained by resources of time and persons that are required for testing.

9.9.2 Entrance Criteria

The development team delivers a module for testing

9.9.3 Exit Criteria

When all test cases for high priority functionality are passed

9.10 Integration Testing

The purpose of integration testing is to ensure that all the modules provide their functionality to the user, when all of them are deployed jointly and there is no ripple effect of one on the other.

We would be performing the integration testing by combining two applications i.e., soft phone and a soft PBX. We are performing this testing since it‟s very crucial for checking the functionalities of our system as they get fulfilled only when the system is integrated. By combining the two applications and running them jointly, we would be able to identify the workable and non workable functionalities of our system.

(58)

9.10.1 Approach

Users will access various components of the application one by one and simultaneously to ensure that all the modules can run concurrently without any problem. Testing methodology that would be used is black box testing. We would not be doing white box testing since we are constrained by resources of time and persons that are required for testing.

All modules are delivered for QA Review and functional testing is complete.

9.11 User Interface Testing

User Interface testing verifies the user‟s interaction with the software. The goal of UI Testing is to ensure that the User Interface provides the appropriate access and navigation to the user through the functions of the application. We would be doing this testing since our system is very interactive.

9.11.1 Approach

Navigate each window to verify the proper states of the objects on each screen as given in the Style Guideline for Web Application document.

When released to Quality Assurance, User Interface will be tested for each module.

(59)

9.12 Sanity Testing

Sanity testing will be performed prior to Integration testing to ensure that the software application is stable for testing and is functioning according to the requirements. Sanity test is meant to run relatively quickly to get a quick assessment of the new software build. This sanity check will let the QA decide if the deployment is of sufficient quality to go forward with a full test effort. We wouldn‟t be dong this testing since we have limited resources available.

9.12.1 Approach

Before integration testing, QA would conduct sanity test based on “product risk matrix”. Any problems found would be reported to the project manager and the head of QA department.

Sanity testing can start as soon as application is deployed for integration testing.

If verified from „product risk matrix‟ and random testing of application that all the previously available functionality is delivered.

9.13 Data Verification

The purpose of data verification is to ensure that Payroll Application can run smoothly on the Client‟s data.

We would be doing data verification since our system is highly interactive.

9.13.1 Approach

Data verification approach is given against each module in the following table.

(60)

Data is verified and any differences are noted and pointed to the Development

Module Data File Verification Strategy

Dial a call

File maintained in the PBX containing caller id

- Black box testing

Phone book service

File maintained in the soft phone containing

person’s information

Soft phone configuration File maintained in the containing soft phone ip address and port

number

PBX configuration File maintained in PBX configuration containing PBX IP address and port number

CDR

F

File maintained in PBX containing PBX ip address and port number

Register User

Fi File containing

callerid and password

Create dial

(61)

9.14 Defect Tracking

Defects found in software application will be assigned a severity grading and reported in Test Director. A development team member then assigns the defect to a developer, from where it is investigated, characterized and dealt with. It may be fixed, not fixed, reported as pending, found to be a feature or not a defect at all, etc. Feature requests and certain defects can be tailored by the project manager, with the consent of head of QA, to serve the "release criteria”.

We would be doing defect tracking since our system have high probability of breakage resulting from catastrophic errors. This would enable us to identify and remove the catastrophic errors which would increase our confidence in the system. This would also help us to identify those errors which need to be immediately removed.

(62)

Defect Tracking Process Flow Defect Found Problem Identified Development Investigate Test Bug fixtue communicated to Dev Lead/PM Developer fixes the defect Defect Verified Dev Lead/PM notify QA Defect Closed Test Passed Retested Retest in the next cycle Released Release Reported Reopen Open Not a Bug Pending Not Fixed Added in Test Repository Assigned to a Developer in Test Repository Development Status updated to

Fixed in the Test repository QA Status Updated in Test Repository QA Status changed to Closed in Test Repository QA Status Updated in Test Repository Add defect Assign Defect

Change Dev Status

Change QA Status

(63)

Severity Level Criteria for a Defect

A five-level criterion will be used to assign Severity to a Defect in the Defect Repository.

9.15 Guidelines for Assigning severity to a defect

Urgent

The defect results in the failure of the complete software system, or of a subsystem within the system in such a way that testing cannot continue. Complete inability to use the subsystem under test is the examples of this type. This is reserved for only the most catastrophic of problems

Very High

The defect results in the failure of a subsystem, or of a software unit (program or module) within the system. Data corruption errors lie in this area.

High

The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or inconsistent results. However, there are acceptable processing alternatives, which will yield the desired result.

Medium

The defect does not cause a failure, and the desired processing results are easily obtained by working around the defect. These issues are generally not damaging to system operation, but instead, are more of an annoyance to the user

(64)

The defect is the result of non-conformance to a standard, is related to the aesthetics of the system, or is a request for an enhancement. Defects at this level may be deferred or even ignored.

Rule of Thumb

Common sense should always have precedence over these rules. Any functional or aesthetic area emphasized by the customer would carry greater severity than the severity assigned by above guidelines.

Quality Control

All the test cases will be technically reviewed between the test cycles. Any deviations from the test requirements will be noted accordingly and the test cases will be updated to ensure that these test cases conform to the updated application requirements from the client.

Team Meetings

The test team will meet once every two weeks/after-each-test-cycle to evaluate the progress to date and to identify error trends and problems as early as possible. The test team leader will meet with development/project manager once every two weeks as well. These two meetings can be scheduled on different weeks. Additional meetings can be called as required for emergency situations.

9.16 Test Suspension and Resumption Criteria

Integration testing would only be conducted after application passes Sanity testing. If application fails in sanity testing then the test-effort will remain suspended until all the previously working functionality is available again and newly fixed defects are verified at random basis.

(65)

9.17 Schedule Overview

QA Schedule will be provided separately in Microsoft Project 2000 Format

Test Configuration Control

Process QA Lead Notified System Ready for Update Development/ Operations Update the Test Server System Busy Requester Notified of the delay Password Changed and Testing Started

Analyze Test activity on the server

Yes

No

Access rights on Test Server changed

by QA Lead Test Server Update/

Install Request

QA Lead to Communicate Username/Password

for system access

A requester can be any person from the Development or the Operations Department

9.18 Testing Resources

Name Responsibilities

Time -

Software -

Hardware -

Man power To test the system and to identify the errors

Testing tools -

(66)

9.19 Summary

Following is the summary of test execution on the system. Majority of the bugs, which are not closed in release 1, have been given Low priority by the development for shipping them with future releases.

Bugs

Total Bugs reported by QA =5 ________________________________________________ Bugs Closed till Extended Integration Testing = 5

Closed for ATM = 3

Closed by PM = 2

Remaining Bugs (QA Status) = 1

Development Priority of Open bugs

--- Low = 2 Medium =1 High = 1 Unknown = 1 Suggestions

Total Suggestion posted in test repository QA =10 __________________________________________________

Suggestions Closed = 5

Closed for ATM =5

(67)

10. TEST CASES

10.1 Dial and Place Call

GUI No 1 (Soft phone Interface)

(68)

(69)

(70)

Test Case ID: 1 (Dial call and place call)

QA Test Engineer Khadija Akram Reviewed By: Testing Team lead (Umair

Ashraf )

Test case Version: 1.0

Test Execution Date: 7-05-2008

Use Case Reference(s) Use case id 1 (Dial call)

GUI Reference(s)

GUI No 1 (soft phone interface) GUI No 2

GUI No 3 GUI No 4 GUI No 5

Objective

To Completely Verify and Validate the dial call functionality of the soft phone System. This test case will completely check the behavior of dial call operation for various inputs in the soft phone system.

Product / Ver/ Module Soft phone System Ver 1.0 /dial call Function)

Environment: windows xp or windows 2000 Environment

Microsoft Internet explorer 6.0

Assumptions: The network connection must be fast enough and it should not be congested otherwise it

might effect the Testing process.

Pre-Requisite: The caller and the calle should both be registered to the ip based PBX

Test Case Description

Testing of the dial call functionality of the soft phone system. It involves testing the behavior of the dial call functionality of the system by checking all possible outputs with respect to the possible inputs given to it.

Input Parameters Expected Output Actual Output Test Conformance Status

Possible Reason(s) in case of failure

(Valid Data)

The dial number should consist of four digits only.

4 digit dial number 1890

Invalid inputs Greater than 4 digit

For all valid data of equivalence classes Output of the system should be successful GUI no 2 will be displayed to the caller and 4 will be

displayed to the callee .Dialing without registering will display GUI no 6

For all valid data of equivalence classes

Successful Validation of the number and display of GUI no 2 to the caller and 4 to the callee will occur.

For all invalid data of equivalence classes.

Passed for all valid input data cases

No Test Case failed!!! No failure occurred .The only possible case was that the network was busy and system responded in terms of exceptional GUI (GUI no 5 exceptional GUI)

(71)

109 108 16

Dial error and system will display GUI no 3

input data cases

10.2 Transfer Call

GUI NO 7

Test Case ID: 2 (Transfer call)

Ashraf )

Use Case Reference(s) Use case id 6(Transfer call )

GUI Reference(s) GUI No 1 GUI No 2 GUI No 3 GUI No 5 GUI No 7 Objective

To Completely Verify and Validate the Transfer call functionality of the soft phone System. This test case will completely check the behavior of Transfer call operation for various inputs in the soft phone system.

Product / Ver/ Module Soft phone System Ver 1.0 Transfer call Function)

Assumptions: The network connection must be FAST enough and it should not be congested otherwise it

(72)

with respect to the possible inputs given to it.

Input Parameters Expected Output Actual Output Test Conformance _Status Possible Reason(s) in _{case of failure}

(Valid Data)

The dial number should consist of four digits only 4 digit dial number 1789

Invalid inputs Greater than 4 digit Dial number 90876

Less than 4 digit Number 987 908 90

Output of the system should be successful GUI no2 will be displayed on the caller side and 4 will be displayed on the callee side.

For all invalid data equivalence classes. Dial error and system will display GUI no 3.

Successful Validation of the number and display of GUI no 2 to caller and 4 on the callee side.

Dial error and system will display GUI no 3

Passed for all in valid input data cases

No Test Case failed!!! No failure occurred .The only possible case was that the network was busy and system responded in terms of exceptional GUI (GUI no 5 exceptional GUI)

(73)

10.3 Call Conference

GUI NO 8

Test Case ID: 3 (Call Conference)

Ashraf )

Use Case Reference(s) Use case id 7(Call Conference )

GUI Reference(s) GUI No 1 GUI No 2 GUI No 3 GUI No 5 GUI No 8 Objective

To Completely Verify and Validate the Call Conference functionality of the soft phone System. This test case will completely check the behavior of Call Conference operation for various inputs in the soft phone system.

Product / Ver/ Module Soft phone System Ver 1.0 Call Conference Function)

Assumptions: The network connection must be FAST enough and it should not be congested otherwise it

Pre-Requisite: The users should be registered with the soft PBX

Test Case Description

Testing of the transfer Call Conference of the soft phone system. It involves testing the behavior of the Call Conference functionality of the system by checking all possible outputs with respect to the possible inputs given to it.

Input Parameters Expected Output Actual Output Test Conformance Status

Possible Reason(s) in case of failure

(Valid Data)

The dial number should consist of four digits only. 4 digit dial number 1789

Output of the system should be successful

Successful Validation of the number and display of GUI 1 will be displayed on the

No Test Case failed!!! No failure occurred .The only possible case was that the network was busy and system responded in terms of exceptional GUI (GUI no 5

(74)

Invalid inputs Greater than 4 digit Dial number 90876

Less than 4 digit Number 987 23

screen.

For all invalid data equivalence classes. Dial error and system will display GUI no 3

Dial error and system will display GUI no3

Passed for all in valid input data cases

(75)

10.4 Phone Book

(76)

(77)

Final Year report on EPABX system

Final Report

V

V

o

o

I

I

P

P

S

S

o

o

f

f

t

t

P

P

B

B

X

X

Project Code: SPBX

Project Advisor: Aftab Alam

Project Team:

Umair Ashraf 03-1853 (Team Lead)

Khadija Akram 04-0080

Acknowledgements

Document Information

Category

Information

Definition of Terms, Acronyms and Abbreviations

Table of Contents

1. Introduction

2.

Goals and objectives

3.

Scope of the project

Vision and Scope

The Virtual PBX (Private Branch Exchange)

4.

Functional Requirements

5.

Non Functional Requirements

6.

Hardware Requirements

7.

Software Requirements

8.

Detailed Design and Architecture

8.1

Use Case Diagram

8.2

Use Case Description

Use case Id 3:

Use case Id 4:

Use case Id 5:

Use case Id 6:

Use case Id 7:

Use case Id 8:

Use case Id 10:

Use case Id 11:

:

Use case Id 13:

Use case Id 14:

Use case Id 15:

Use case Id 16:

Use case Id 17:

8.3 Class Diagrams

8.3.1 Soft PBX

8.4 Sequence Diagrams

8.4.5 Receive Call

8.4.7 Reject Call

8.5 Context Diagram

8.6 Data Flow Diagrams

PBX SIP Engine

RTP Processor

9. Test Plan