Customer Test Plan: SIP Interoperability

Customer Test Plan: SIP Interoperability April 2010 290-00038, Rev 10

Contents About This Guide... 5 Chapter 1: Overview... 7 Introduction to SIP Testing... 7 Acronyms... 10 Chapter 2: The Calix SIP Interoperability Test Plan... 13 Test Plan Summary... 13 Test Plan Strategy... 14 Summary of Test Cases... 14 Chapter 3: Test Cases... 17 Registration... 17 Endpoint Functionality (No Authentication)... 18 Endpoint Functionality (With Authentication)... 19 Caller ID... 20 Call Forwarding... 20 Call Waiting... 21 3-Way Calling... 22 Home Intercom (Revertive Ring)... 23 Voicemail and VMWI... 23 Digit Map Programming... 24

4 Distinctive Ringing... 24 SIP Call Forking... 25 Fax/Modem Support... 25 Call Park and Retrieval... 26 Automatic Call Back (ACB)... 27 Codec Support... 28 Multi-Line Hunt Groups... 29 Multiple Appearance Directory Number... 30 Media Gateway Protection Switch Support... 30 Out of Band DTMF Receipt (RFC2833)... 31 Fault Tolerance and Disconnection... 31 PC Client and SIP Endpoint Basic Call... 32 E-911 Support... 32

About This Guide 5 This guide outlines various test scenarios and efforts needed to verify whether certain Calix products inter-operate with different vendor SIP softswitches.

6

Chapter 1 Overview Introduction to SIP Testing SIP is an IETF application layer control protocol, described in RFC-3261, that handles the setup, modification, and tear-down of multimedia sessions. SIP (sometimes referred to as "client server/request response protocol") supports the following features for establishing and ending sessions: User location User availability User capabilities Session setup Session management

8 Since SIP is a control protocol, it interacts with RTP, RTCP, UDP/IP, and SDP to provide telephony and other multimedia services. The basic SIP architecture, as deployed in a Calix network is shown below. In the diagram above, the Bearer Traffic is the RTP traffic stream that carries the actual phone call. The Control Traffic is the signaling channel which is used in the call setup and tear down. Control Traffic is typically a set of messages used by each endpoint to determine how to setup the Bearer Traffic channel transport. As illustrated above, the separation of the media path/media conversion function from the call control and signaling function supports the idea of a softswitch architecture. The softswitch architecture separates the component that handles call control (known as the call agent) and the component that controls media conversion (known as the media gateway). Different softswitch vendors use different approaches and design methodologies when they develop their respective softswitches and these differences create a need for Interoperability testing of Calix products with different softswitch vendors. The diagram below illustrates the typical signaling that occurs in any SIP conversation. The Control Traffic includes invitation, ringing, acknowledgment at both ends, and the call termination commands. The Bearer Traffic is represented here as the media exchange function.

The table below shows the standard message set for the SIP protocol. Any conversation established via SIP uses the messages (Method Tokens) in the first section of the table. In addition, every message sent requires acknowledgment by its receiver. This acknowledgment takes the form of a returned 3-digit status number. The 2nd section of the table shows the various classes of response. Within each class (1xx, 2xx, and the like), many different returned values are possible. Note: for additional information on the SIP messaging protocol, refer to the SIP RFC#3261.. 9 SIP Method Token Invite Options Bye Cancel Register INFO SIP Response Invite a user to a call Queries server about its capabilities Terminate a session Terminate request Register user s current location Used for mid-session signaling Description Description 1xx 2xx 3xx 4xx 5xx 6xx Informational - indicates the request is still being processed and a definitive response is not yet available. Example: 180 - Ringing - The called agent has located a destination and is attempting to alert the user. Success - The request was successful and must terminate the search. Example: 200 OK - The request has succeeded. Redirection - gives information about the user's location, or about alternative services that are available to satisfy the call. Example: 301 - Moved Permanently - the user is not found at the address in the request URI. Request Failure - confirmed failure response from the server. The client should not retry the same request without modification. Example: 400 - Bad Request (syntax error) Server Failure - Occurs when a server has erred. Does not terminate a search if other possible locations remain untried. Example: 501 Not Implemented - The server does not support the functionality required. Global Failure - Indicates a server has definitive information about a user, not just the instanced indicated in the request URI. Example: 600 Busy Everywhere - The receiver's end system was contacted successfully but the receive is busy and does not wish to the take at this time. For additional information on SIP Method Token and Response codes, refer to RFC3261.

10 Acronyms ADSL Asymmetric Digital Subscriber Line ARP Address Resolution Protocol BAR Backup and Restore CLI Command Line Interface CMS Calix Management System CPE Customer Premise Equipment CUP Calix Upgrade Procedure DHCP Dynamic Host Configuration Protocol DSL Digital Subscriber Line DSLAM Digital Subscriber Line Access Multiplexer DUT Device under Test E5 Calix IP DSLAM EUT Entity under Test FE Fast Ethernet GE Gigabit Ethernet GIGE Gigabit Ethernet ICMP Internet Control Message Protocol IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IP Internet Protocol IPoE IP over Ethernet LC Line card Controller MAC Media Access Control MMF Multi Mode Fiber MLHG Multi-Line Hunt Group PC Personal Computer PM Performance Monitoring PPPoE PPP over Ethernet RFC Request for Comments RTP Real time Transport Protocol RTCP Real Time Control Protocol SC Shelf Controller SDP Session Description Protocol SFP Small Form-factor Pluggable SIP Session Initiation Protocol SMF Single Mode Fiber STB Set Top Box STP Spanning Tree Protocol TBD To be determined

11 TCA Threshold Crossing Alert TEngine Test Engine (Automation Tool) VDSL Very high data rate Digital Subscriber Line VID VLAN ID VLAN Virtual Local Area Network XDSL ADSL/ADSL2+/VDSL2

12

Chapter 2 The Calix SIP Interoperability Test Plan Test Plan Summary The main focus of this test plan is to verify call features and functionalities on Calix products that inter-operate with different types of softswitch. Features to be tested as a part of interoperability testing includes: Three-Way Calling Call waiting Call waiting with Caller ID Caller ID Distinctive Ring Visual Message Waiting Indicator Vertical Service Codes Note: Calix currently performs interoperability testing on the Calix C7, E-Series (GPON or AE), and AE ONT platforms. It is assumed customers implementing this test plan will do likewise based on their network architecture. Test Plan Limits This test plan does not cover test cases that are related to provisioning of Calix SIP endpoints and configuration of Calix equipment. Capacity testing is not covered in this test plan. This test plan is not intended to cover specific vendor softswitches. This test plan should be used as a generic Interoperability plan in the absence of switch vendor test plans.

14 Test Plan Strategy The interoperability test cases are based on vendor supplied test cases. All test cases must be reviewed between Calix and any softswitch vendor team prior to implementation. Once reviewed and accepted, a test matrix will be created specifying the supported features per softswitch, test plan pass or fail criteria, with any other pertinent information populating the matrix at the completion of the test effort. In the event vendor supplied test cases are not available, generic DVT test case applicable to interoperability will be used to execute and verify features and services. Summary of Test Cases The following test cases should be executed as part of SIP Interoperability testing Test case Heading Description Registration Initial registration with no authentication and renew with authentication Initial Registration with authentication Basic-Endpoint Functionality Basic Endpoint Functionality - Outgoing Call With No Authentication Outgoing call canceled Basic-Endpoint Functionality With Authentication Incoming call Incoming call canceled Long duration call User signaling - busy tone User signaling - dial tone timeout SoftSwitch announcements Do Not Disturb (DND) Call keep alive Caller ID Call number and name delivery SIP INVITE or SUBSCRIBE/NOTIFY 3-Way Calling Basic 3-Way call media mixing provided by SoftSwitch Basic 3-Way call media mixing provided by Device Under Test (DUT) Automatic Callback Automatic callback - DUT calling Automatic callback - DUT busy Call Park and Retrieval Parking calls Retrieving calls The DUT picks up a call parked by another phone in the same group Call Forwarding Unconditional call forwarding Delayed call forwarding Busy call forwarding Selective call forwarding

15 Test case Heading Description Call Waiting Call waiting Call waiting ignored Calling name display Calling number display Cancel call waiting for next call Cancel call waiting for remainder of current call Digit Map Programming Basic dial plan testing Simple digit matching Distinctive Ringing Priority ring cadences Distinctive ring cadences Distinctive call-waiting notification Message Waiting Indicator Leaving and retrieving voicemail Fault-Tolerance and Disconnection Visual Message Waiting Indicator (VMWI) Rebooting the device Network interface failure Network outage recovery on softswitch side Fax /Modem Sending /Receiving a fax direct media Sending /Receiving a fax indirect media Sending/Receiving fax with fallback from a low bandwidth codec Sending /Receiving a fax direct media with T.38 Sending /Receiving a fax indirect media with T.38 Sending a T.38 fax with PSTN interworking Receiving a T.38 fax with PSTN interworking V.90/V.92 Dialup performance Codec Support G.711 codec negotiation led by DUT Home Intercom (Revertive Ring) G.711 codec negotiation led by SoftSwitch G.726-32 codec negotiation led by DUT G.726-32 codec negotiation led by Softswitch G.729 codec negotiation led by DUT G.729 codec negotiation led by SoftSwitch New call to other extension Transfer call to other extension Multi Line Hunt Groups Basic call from DUT to MLHG pilot number Basic call to MLHG pilot number with DUT in MLHG Call to MLHG pilot number while one MLHG member is off hook Call to MLHG pilot number. One of the MLHG members has DND enabled Call the MLHG from four lines consecutively Multiple Appearance-Directory MADN Lines - multiple lines available Numbers MADN Lines - one line available MADN Lines - no lines available, queuing RFC2833(Out Of Band) DTMF signals received using direct media DTMF Receipt DTMF signals received using indirect media SIP Call Forking Multiple registrations for a single subscriber Initiate a call to a multiple registered line Initiate a call from a multiple registered line

16 Test case Heading Support for Media Gateway Protection Switch Description Established calls remain up over protection switch Basic Call Between PC Client SIP endpoint to PC client: Originator disconnect after answer and SIP Endpoints PC client to SIP endpoint: Originator disconnect after answer SIP endpoint to PC client: Terminator disconnect after answer PC client to SIP endpoint: Terminator disconnect after answer SIP endpoint to PC client: Originator disconnect before answer PC client to SIP endpoint: Originator disconnect before answer E-911 Support Emergency assistance with Operator ring back Emergency assistance (E911) call with Operator hold

Chapter 3 Test Cases The test cases below should be run for each supported feature. In all cases, the User interface is the Calix CMS and the Entity Under Test (EUT) would be the appropriate shelf (C7, F5, FD). Registration Test Number 1 EUT: Initial registration with no authentication and renew with authentication ---> Verify the registration attempt with no authentication should fail with and registration renew with authentication should succeed. 2 EUT: Initial Registration with authentication ---> Verify that only users with valid User ID and password allowed to register with SIP server.

18 Endpoint Functionality (No Authentication) 1 EUT: Outgoing call canceled, Initiate a call from one port to the other while it's in the off-hook state --> Verify that a busy indication is received and terminate the call, no error or failure indications should be present during call set up. After the call disconnect, subsequent call attempts should be successful. 2 EUT: Incoming Call, Initiate a call from one port to the other ---> Verify that a voice path is established and terminate the call, no error or failure indications should be present during call set up. There should be no audible noise or distortion on the phones during the call. After the call disconnect, subsequent call attempts should be successful. 3 EUT: Incoming call canceled: Initiate a call from one port to the other. While the 2nd port phone is in the ringing state, go on-hook with originating phone ---> Verify no error or failure indications should be present during call set up. After the call disconnect, subsequent call attempts should be successful 4 EUT: Long Duration Call, Initiate a call from one port to the other and verify that a voice path is established and leave the call up for a minimum of 12 hrs ---> No error or failure indications should be present during call set up. There should be no audible noise or distortion on the phones during the call. After the call disconnect, subsequent call attempts should be successful 5 EUT: User Signaling - Dial tone timeout, Go back on-hook with phone A and after 1 second, pick up the phone and verify dial-tone is provided => Verify a call can be made to phone B. Place phones A and B back on-hook. Go off-hook on phone A without dialing any digits. ----> Verify that dial-tone is provided for a period of time equal to the Reorder Delay in the VoIP Configuration file. Verify that after the Reorder Delay an OSI is applied to line A for a period of 800-1000 msec. Verify that after the completion of the OSI, a Reorder Tone is applied for 60 seconds. Verify that after the completion of the Reorder Tone, a ROH tone is applied. Verify that if the ROH tone is removed from the line, talk battery is removed from the line (voltage measurement of tip/ring). Attempt to make a call into phone A from phone B. Verify that an error code of xxx is given in response to the VoIP invite message. Go back on-hook with phone A and after 1 second, pick up the phone and verify dial-tone is provided. Verify a call can be made to phone B 6 EUT: Switch Announcements, Call a non-existent subscriber ----> verify switch announcement is played. Call an unregistered SIP subscriber ----> Verify switch announcement is played 7 EUT: Do Not Disturb, Set one of the port to Do Not Disturb, Call the port with DND from non-dnd enable port ---> Call is not established and may generate busy tone, voicemail, or temporarily unavailable message. 8 EUT: Call keep alive, Initiate a call from one port to the other and after a voice path is established, capture the call flow ----> Verify that re-invite generated periodically based on the keep alive value. 9 EUT: Initiate a call from one port to the other and after a voice path is established, go on-hook on the calling phone ----> Verify that after a period equal to the Reorder Delay in the VoIP Configuration file that an OSI is applied to line A for a period of 800-1000 msec. Verify that after the completion of the OSI, a Reorder Tone is applied. Verify that after the completion of the Reorder Tone, a ROH tone is applied. Verify that if ROH is removed, the line is placed in a standby state (voltage measurement of tip/ring) 10 EUT: Initiate a call from one port to the other and after a voice path is established, go on-hook on the called phone ----> Verify that after a period equal to the Reorder Delay in the VoIP Configuration file that an OSI is applied to line A for a period of 800-1000 msec. Verify that after the completion of the OSI, a Reorder Tone is applied. Verify that after the completion of the Reorder Tone, a ROH tone is applied. Verify that if ROH is removed, the line is placed in a standby state (voltage measurement of tip/ring)

19 Endpoint Functionality (With Authentication) 1 EUT: Outgoing call canceled: Initiate a call from one port to the other while it's in the off-hook state ---> Verify that a busy indication is received and terminate the call, no error or failure indications should be present during call set up. After the call disconnect, subsequent call attempts should be successful 2 EUT: Incoming Call: Initiate a call from one port to the other ---> Verify that a voice path is established and terminate the call, no error or failure indications should be present during call set up. There should be no audible noise or distortion on the phones during the call. After the call disconnect, subsequent call attempts should be successful 3 EUT: Incoming call canceled: initiate a call from one port to the other. While the 2nd port phone is in the ringing state, go on-hook with originating phone ---> Verify no error or failure indications should be present during call set up. 4 EUT: Long Duration Call: Initiate a call from one port to the other and verify that a voice path is established and leave the call up for a minimum of 12 hrs ---> No error or failure indications should be present during call set up. There should be no audible noise or distortion on the phones during the call. After the call disconnect, subsequent call attempts should be successful 5 EUT: User Signaling - Dial tone timeout: Go back on-hook with phone A and after 1 second, pick up the phone and verify dial-tone is provided => Verify a call can be made to phone B. Place phones A and B back onhook. Go off-hook on phone A without dialing any digits. ----> Verify that dial-tone is provided for a period of time equal to the Reorder Delay in the VoIP Configuration file. Verify that after the Reorder Delay an OSI is applied to line A for a period of 800-1000 msec. Verify that after the completion of the OSI, a Reorder Tone is applied for 60 seconds. Verify that after the completion of the Reorder Tone, a ROH tone is applied. Verify that if the ROH tone is removed from the line, talk battery is removed from the line (voltage measurement of tip/ring). Attempt to make a call into phone A from phone B. Verify that an error code of xxx is given in response to the VoIP invite message. Go back on-hook with phone A and after 1 second, pick up the phone and verify dial-tone is provided. Verify a call can be made to phone B 6 EUT: Switch Announcements: Call a non-existent subscriber ----> verify switch announcement is played. Call an unregistered SIP subscriber ----> Verify switch announcement is played 7 EUT: Do Not Disturb: Set one of the ports to Do Not Disturb, Call the port with DND from non-dnd enable port ---> Call is not established and may generate busy tone, voicemail, or temporarily unavailable message. 8 EUT: Call keep alive: Initiate a call from one port to the other and after a voice path is established, capture the call flow ----> Verify that re-invite generated periodically based on the keep alive value. 9 EUT: Initiate a call from one port to the other and after a voice path is established, go on-hook on the called phone ----> Verify that after a period equal to the Reorder Delay in the VoIP Configuration file that an OSI is applied to line A for a period of 800-1000 msec. Verify that after the completion of the OSI, a Reorder Tone is applied. Verify that after the completion of the Reorder Tone, a ROH tone is applied. Verify that if ROH is removed, the line is placed in a standby state (voltage measurement of tip/ring)

20 Caller ID 1 EUT: Caller ID: This test will verify that the Caller ID CLASS feature that deals with Call Number Delivery: Provisioned SIP UA VoIP ports for Caller ID service and initiate calls between VoIP ports --> Verify the Caller ID information displayed. 2 EUT: Caller ID:This test will verify that the Caller ID CLASS feature that deals with display name and phone number of the calling party in the SIP INVITE or a SUBSCRIBE/NOTIFY on a per soft switch vendor: Provisioned SIP UA VoIP ports for Caller ID service and initiate calls between VoIP ports --> Verify the Caller ID information contains the calling party name and the calling party phone number. Call Forwarding 1 EUT: Delayed Call Forwarding: Activate call forward on a port and make an incoming call --> verify that the call is forwarded to the destination correctly and when the call is ended properly 2 EUT: Busy Call Forwarding: Activate call forward on a port and make an incoming call --> verify that the call is forwarded to the destination correctly and when the call is ended properly 3 EUT: Selective Call Forwarding: Activate call forward on a port and make an incoming call --> verify that the call is forwarded to the destination correctly and when the call is ended properly 4 EUT: Unconditional Call Forwarding: Activate call forward on a port and make an incoming call --> verify that the call is forwarded to the destination correctly and when the call is ended properly 5 EUT: Unconditional Call Forwarding: Ring Splash on Call Forward. Ring splash pattern should be provisioned. Enable call-forwarding on the phone. Ring splash should be enabled on the softswitch. Dial forwarded phone. ---> The call is forwarded successfully and the audibly ring splash is heard matching the pattern. Note this is a softswitch specific test and results may vary. Please note the results with description of variance.

21 Call Waiting 1 EUT: Basic call waiting: ---> The SIP IAD shall accommodate a second incoming call while the subscriber is active in another call session. The SAS is heard on the controlling party to indicate 2nd party has called the controlling party. 2 EUT: Basic call waiting: Repeated Hook Flash Between Parties ---> Call switch occurs between first and second party for each hook flash. 3 EUT: Basic call waiting: 2nd Party Hang-up 1st Party on Hold ---> The line goes quiet after 2nd party hangs up. 4 EUT: Basic call waiting: Flash Hook After 2nd Party Hang-up 1st Party on Hold ---> After the flash hook the 1st party is re-connected with controlling party. 5 EUT: Basic call waiting: 1st party Hang-up on Controlling Party ( 2nd party hung-up) ---> Line is quiet on controlling party. Dial tone heard when controlling party phone is taken off-hook again. 6 EUT: Basic call waiting: Controlling party Hang-up (1st party active, 2nd party hung-up) ---> Line is quiet on 1st party. Dial tone heard when controlling party phone is taken off-hook again. 7 EUT: Basic call waiting: 2nd party Hang-up on Controlling Party (1st party on hold, 2nd party active) ---> Line is quiet on 1st party. Controlling party now goes through the alerting sequence (reorder tone after 10 seconds, ROH/Howler tone after 60 seconds). 8 EUT: Basic call waiting: 1st party Hang-up when on hold ( 2nd party active) ---> Stutter dial-tone is received by controlling party to indicate the first party has hung-up. Note this particular result is dependent on softswitch operation. 9 EUT: Basic call waiting: SAS Heard on Controlling Party at Flash-hook ---> SAS is heard on controlling party and disconnect from current active party (hook-flash for >1550 msec). The Flash hook toggles the voice path between the 1st and 2nd parties. 10 EUT: Basic call waiting: SAS Heard on Controlling Party at 2nd party on hold hang-up ---> SAS is heard on controlling party at the time the 2nd party who is on hold hangs up. Note this particular result is dependent on the softswitch operation. 11 EUT: Basic call waiting: Controlling Party Hangs-up with both parties in session (1st party on hold, 2nd party active) ---> This particular result is dependent on softswitch. The 1st party may be disconnected by softswitch with a BYE. The controlling party ONT should send an Alert Power Ring Sequence to indicate that there is a phone call waiting. Upon the controlling party going off hook the call path is present to the 1st party. If the first party hangs up, issues a BYE, before the subscriber goes off hook, the Alert Power Ringing should stop. 12 EUT: Basic call waiting: Controlling Party Hangs-up with both parties in session (1st party active, 2nd party on hold) ---> This particular result is dependent on softswitch. The 2nd party may be disconnected by softswitch with a BYE. The controlling party ONT should send an Alert Power Ring Sequence to indicate that there is a phone call waiting. Upon the controlling party going off hook the call path is present to the 2nd party. If the second party hangs up, issues a BYE, before the subscriber goes off hook, the Alert Power Ringing should stop. OR Softswitch disconnects both the first and second parties via issuing a BYE to both sessions. 13 EUT: Basic call waiting: Caller-ID displayed for 2nd incoming call ---> The SIP IAD shall accommodate offhook transmission of Calling Number Delivery GR-575 when a subscriber is active with current call, and shall alert the subscriber with SAS as per TR-30 and Alerting Signals Using Call-Waiting Tones per GR-506 14 EUT: Call Waiting ignored: The controlling party call the first party ---> verify 2-way media established between the two parties. The second party call the controlling party ---> verify that call is waiting via audible and visual notification, ignore call waiting ---> verify 2-way media remains between controlling party and the first party and no media between controlling and second party.

22 3-Way Calling 1 EUT: Initiate call from controlling party to the first party, dial Tone on Flash hook when initiated 2nd leg of call ---> Dial tone becomes present on controlling phone after flash hook to initiate 3-Way call. Initiate call between the controlling party and the second party, call path between controlling party and second party (1st party on hold) ---> Voice path is established between controlling party and second party while the first party is on hold. 1st party line is quiet. 2 EUT: 3-Way voice path present upon Flash-hook by controlling party after second leg established ---> The 3-Way voice path is present between all three parties. No audible noise or distortion should be heard. Capture flash-hook SIP INFO method received. 3 EUT: 3rd party call attempt with 3-Way call in progress. Call attempt to each of the parties in the 3-Way call. ---> Call attempt fail with busy tone. 4 EUT: 3-Way call 1st party goes on-hook ---> Voice path exists between controlling party and second party. 5 EUT: 3-Way call 2nd party goes on-hook ---> Voice path exists between controlling party and 1st party. 6 EUT: 3-Way call controlling party goes on-hook ---> This is a softswitch dependent outcome. Voice path exists between 1st and 2nd parties or it is torn down. Either way capture SIP messaging to characterize the softswitch. 7 EUT: Controlling party to 2nd party call attempt fail. The 2nd party should either be in another call session or off-hook. Attempt to call the 2nd party from the controlling phone. After the busy is heard perform flash-hook to end call attempt and to be reconnected with 1st party. ---> Call attempt to 2nd party fails with busy tone on controlling party. 1st party line in quiet. Flash-hook on the controlling phone re-establishes voice path to 1st party. 8 EUT: On-device media mixing for multi-party calls: Initiate call from controlling party to the first party, dial Tone on Flash hook when initiated 2nd leg of call ---> Dial tone becomes present on controlling phone after flash hook to initiate 3-Way call. Initiate call between the controlling party and the second party, call path between controlling party and second party (1st party on hold) ---> Voice path is established between controlling party and second party while the first party is on hold. 1st party line is quiet. 9 EUT: On-device media mixing for multi-party calls: 3way voice path present upon Flash-hook by controlling party after second leg established ---> The 3-Way voice path is present between all three parties. No audible noise or distortion should be heard. Capture flash-hook SIP INFO method received. 10 EUT: On-device media mixing for multi-party calls: 3rd party call attempt with 3-Way call in progress. Call attempt to each of the parties in the 3-Way call. ---> Call attempt fail with busy tone. 11 EUT: On-device media mixing for multi-party calls: 3-Way call 1st party goes on-hook ---> Voice path exists between controlling party and second party. 12 EUT: On-device media mixing for multi-party calls: 3-Way call 2nd party goes on-hook ---> Voice path exists between controlling party and 1st party. 13 EUT: On-device media mixing for multi-party calls: 3-Way call controlling party goes on-hook ---> This is a softswitch dependent outcome. Voice path exists between 1st and 2nd parties or it is torn down. Either way capture SIP messaging to characterize the softswitch. 14 EUT: Controlling party to 2nd party call attempt fail. The 2nd party should either be in another call session or off-hook. Attempt to call the 2nd party from the controlling phone. After the busy is heard perform flash-hook to end call attempt and to be reconnected with 1st party. ---> Call attempt to 2nd party fails with busy tone on controlling party. 1st party line in quiet. Flash-hook on the controlling phone re-establishes voice path to 1st party.

23 Home Intercom (Revertive Ring) 1 EUT: Revertive ring: Case I: New call to other extension: Configure SIP UA with home intercom feature and two extension phones connected to SIP UA: Pick up one of A's phones and call A --> Confirm: Busy tone is heard; Hang up the phone --> Confirm: All A's phones ring; Pick up two of A's phones ---> Confirm: Ringing stops, and there is 2-way media between the phones; Hang up the phones, and pick one up again ---> Confirm: Dial tone heard, and able to make an outbound call. 2 EUT: Revertive ring:case II: Transfer call to other extension: B calls A ---> Confirm: One of A's phones picks up, and there is 2-way media with B; Flash-hook on A's phone ---> Confirm: Hear stutter dial tone on A's phone; Hang up A's phone ----> Confirm: All A's phones now ring; Pick up A's other phone ---> Confirm: Ringing stops, and there is 2-way media with B; Hang up the phones, and pick one of A's again ----> Confirm: Dial tone heard, and able to make an outbound call. Voicemail and VMWI 1 EUT: VMWI Display Activated (Phone on-hook). The SIP end point should be connected to a VMWI capable phone. Leave a voice message. ---> The Visual Message Waiting server is active and messagewaiting indicator is lit. 2 EUT: VMWI Display Activated (Phone off-hook). The SIP endpoint should be connected to a VMWI capable phone. The SIP endpoint should be off-hook. Leave a voice message ---> The Visual message-waiting indicator is lit after the SIP endpoint goes on-hook. 3 EUT: VMWI Display De-Activated. The SIP endpoint should be connected to a VMWI capable phone. Leave a voice message. Either from the phone or another delete the voice mails waiting. ---> The Visual Message Waiting server is active and the phones message-waiting indicator is lit. After the delete of all voice mails waiting the VMWI is no longer lit. 4 EUT: VMWI Tone Activated. Leave a voice message. ---> Verify stutter tone should be heard before full dial tone to indicate that message is waiting. 5 EUT: VMWI Tone De-Activated. Leave a voice message. Either from the phone or another delete the voice mails waiting ---> Verify stutter tone is no longer heard before full dial tone to indicate that message is waiting.

24 Digit Map Programming 1 EUT: 2 and 3 digits Star Code Services: configure dialing plan to handle 2 & 3 digit VSCs. Dial several codes. ---> Capture SIP messages to verify VSC sent is correct. 2 EUT: 7, 10, 11 Digit Dialing Plan. Enable dialing plan for 7, 10, and 11 digit dialing plan. Dial several 7, 10 and 11 digit numbers. ---> Calls to all valid numbers are successful. 3 EUT: 2 and 3 digits Star Code followed by 7, 10, 11 Digit Dialing Plan. Enable dialing plan for 7, 10, and 11 digit dialing plan. Dial several 7, 10 and 11 digit numbers. ---> Calls to all valid numbers are successful. 4 EUT: Verify the timeout rules functions properly. Distinctive Ringing 1 EUT: Default R1 ring cadence (GR-506). Call made to phone using default ring pattern. ---> Default R1 ring pattern heard on called phone when distinctive ringing is not present. 2 EUT: R2 ring cadence (GR-506). Call made to phone defining use of R2 ring pattern. ---> Ring cadence is long (800 msec), silent (400 msec), long (800 msec), silent (4000 msec). 3 EUT: R3 ring cadence (GR-506). Call made to phone defining use of R3 ring pattern. ---> Ring cadence is short (400 msec), silent (200 msec), short (400 msec), silent (200 msec), long (800 msec), silent (4000 msec) 4 EUT: R4 ring cadence (GR-506). Call made to phone defining use of R4 ring pattern. ---> Ring cadence is short (300 msec), silent (200 msec), long (1000 msec), silent (200 msec), short (300 msec), silent (4000 msec). 5 EUT: R5 ring cadence (GR-506). Call made to phone defining use of R5 ring pattern. ---> Ring cadence is a single short ring burst (500 msec). 6 EUT: R6 ring cadence (GR-506). The R6 cadence is default to be the same as R1 ring cadence. May want to modify the ring cadence to verify the ring is unique. Past testing performed with the following cadence: long (800 msec), silent (400 msec), long (800 msec), silent (400 msec), long (800 msec), silent (2800 msec). Call made to phone defining use of R6 ring pattern. ---> Ring cadence is as provisioned. 7 EUT: R7 ring cadence (GR-506). The R7 cadence is default to be the same as R1 ring cadence. May want to modify the ring cadence to verify the ring is unique. Past testing performed with the following cadence: long (800 msec), silent (400 msec), short (400 msec), silent (400 msec), long (800 msec), silent (3200 msec). Call made to phone defining use of R6 ring pattern. ---> Ring cadence is as provisioned. 8 EUT: R8 ring cadence (GR-506). The R8 cadence is default to be the same as R1 ring cadence. May want to modify the ring cadence to verify the ring is unique. Past testing performed with the following cadence: Short (400 msec), silent (400 msec), short (400 msec), silent (400 msec), short (400 msec), silent (4000 msec). Call made to phone defining use of R6 ring pattern. ---> Ring cadence is as provisioned.

25 SIP Call Forking 1 EUT: Multiple registrations for a single subscriber, configure a subscriber with multiple call appearance ----> verify that single subscriber using two or more SIP device can be registered at the same time for the same directory number 2 EUT: Initiate a call to a multiple registered line ----> verify an incoming call to the subscriber's directory number causes all of these devices to alert; the call can be answered at any device.d 11 digit numbers. ---> Calls to all valid numbers are successful. 3 EUT: Initiate a call from a multiple registered line ----> verify an outgoing call from any of these devices is associated with the subscriber's directory number, and appears the same to the called party regardless of the originating device. Fax/Modem Support 1 EUT: Sending /Receiving a fax direct media: Send and receive 100 page FAX between SIP endpoints using G.711 ->verify 100 page FAX received reliably 2 EUT: Sending /Receiving a fax indirect media: Send and receive 100 pages FAX between SIP endings using G.711 ->verify 100 pages FAX received reliably 3 EUT: Sending/Receiving fax direct media with fallback from a low bandwidth codec: Send and receive 100 pages FAX between SIP endings using lower bandwidth Codec ->verify 100 pages FAX received reliably and verify the call flows to confirm the codec was changed to G.711.(400 msec), silent (200 msec), long (800 msec), silent (4000 msec) 4 EUT: Sending/Receiving fax indirect media with fallback from a low bandwidth codec: Send and receive 100 page FAX between SIP endpoints using lower bandwidth Codec ->verify 100 page FAX received reliably and verify the call flows to confirm the codec was changed to T.38 5 EUT: Sending /Receiving a fax direct media with T.38: Send and receive 100 page FAX between SIP endpoints using T.38 ->verify 100 page FAX received reliably 6 EUT: Sending /Receiving a fax indirect media with T.38: Send and receive 100 pages FAX between SIP endpoints using T.38 ->verify 100 pages FAX received reliably 7 EUT: Sending/ Receiving a T.38 fax with PSTN interworking indirect media: Send and receive 100 page FAX between SIP endpoint and TDM network ---->Verify 100 page FAX received reliably 8 EUT: V.90/V.92 Dialup performance -> 48 Kbps connect rate >40 Kbps Throughput 95% of attempts

26 Call Park and Retrieval 1 EUT: Basic Parking calls: A is on DUT and in a business group with call park enabled. Action: Establish a call between A and B Confirm: 2-way media. Action: A puts B on hold and dials the call park access code. Confirm: A hears announcement stating which park orbit is to be used. Action: Transfer the held call to the access code call Confirm: B remains held, A drops out of both calls. Action: While B is still parked, perform the above steps with C instead of B. 2 EUT: Retrieving calls: A is on DUT and in a business group with call park enabled. Calls are parked in park orbits X and Y on the Softswitch.Action: from A, dial the parked call retrieval access code. Confirm: A is now in call with the parked user. Action: repeat the above for Y instead of X. 3 EUT: The DUT picks up a call parked by another phone in the same group: A is on DUT and in a business group with call park enabled. Action: Create a call from B to C. Confirm: 2-way media between B and C. Action: B parks the call and hangs up. Confirm: C is parked. Action: A picks up the parked call. Confirm: 2-way media between A and C. Action: Hang up all lines. Confirm: All lines have dial tone.

27 Automatic Call Back (ACB) 1 EUT: Automatic Callback - DUT calling: A is on DUT B and C are on Known Good Automatic callback is configured on the switch for line A Ensure no phones have call waiting, busy call forwarding or voicemail enabled. If you are using SIP lines with multiple call appearances, make sure all call appearances are in use for the phone to be considered busy. Action: Establish a call between B and C Action: Dial B from A Confirm: A plays the busy tone (or an announcement is heard). Action: Hang up A Action: Dial *66 from A Confirm: A Softswitch announcement is played Action: Hang up phone A. Action: Hang up phones B and C Confirm: Phone A starts ringing Action: Pickup phone A Confirm: Phone B starts ringing Action: Answer B Confirm: two-way media between A and B Action: Hang up all phones 2 EUT:Automatic Callback - DUT busy: A is on DUT Automatic callback is configured on the switch for line A Ensure no phones have call waiting, busy call forwarding or voicemail enabled. Action: Establish a call between A and B Action: Dial A from C Confirm: C plays the busy tone Action: Hang up C Action: Dial *66 star code from C Confirm: A Softswitch announcement is played Action: Hang up phones A and B Confirm: Phone C starts ringing Action: Pickup phone C Confirm: Phone A starts ringing Action: Answer A Confirm: two-way media between A and C Action: Hang up all phones

28 Codec Support 1 EUT: G.711 codec negotiation led by DUT: Configure the DUT to support G.711 mu-law or A-law by checking the fixbits on the Remote Media Gateway Model on the Softswitch A is on DUT, and uses indirect media B is a Known Good Action: Call B from A Confirm: Check flows to confirm that G.711 has been negotiated correctly Confirm: two-way voice path Confirm: RTP media is sent in both directions using G.711 only. 2 EUT: G.711 codec negotiation led by Softswitch: Configure the DUT to support G.711 mu-law or A-law by checking the fixbits on the Remote Media Gateway Model on the Softswitch A is on DUT, and uses indirect media B is a Known Good Action: Call A from B Confirm: Check flows to confirm that G.711 has been negotiated correctly Confirm: two-way voice path. Confirm: RTP media is sent in both directions using G.711 only. 3 EUT: G.726-32 codec negotiation led by DUT: Configure the DUT to support and prefer G.726-32 by checking the fixbits on the Remote Media Gateway Model on the Softswitch A is on DUT. B is a Known Good. A is configured to use indirect media. Action: Call B from A Confirm: Check flows to confirm that G.726-32 has been negotiated correctly Confirm: two-way voice path. Confirm: RTP media is sent in both directions using G.726-32 only. 4 EUT: G.726-32 codec negotiation led by Softswitch: Configure the DUT to support and prefer G.726-32 by checking the fixbits on the Remote Media Gateway Model on the Softswitch A is on DUT.B is a Known Good. A is configured to use indirect media. Action: Call A from B Confirm: Check flows to confirm that G.726-32 has been negotiated correctly Confirm: two-way voice path. Confirm: RTP media is sent in both directions using G.726-32 only. 5 EUT: G.729 codec negotiation led by DUT: Configure the DUT to support and prefer G.729 by checking the fixbits on the Remote Media Gateway Model on the Softswitch. A is on DUT. B is a Known Good. A is configured to use indirect media. Action: Call B from A Confirm: Check flows to confirm that G.729 has been negotiated correctly. Confirm: two-way voice path. Confirm: RTP media sent over G.729 only in both directions 6 EUT: G.729 codec negotiation led by Softswitch: Configure the DUT to support and prefer G.729 by checking the fixbits on the Remote Media Gateway Model on the Softswitch A is on DUT.B is a Known Good. A is configured to use indirect media. Action: Call A from B Confirm: Check flows to confirm that G.729 has been negotiated correctly. Confirm: two-way voice path. Confirm: RTP media is sent by G.729 only in both directions

29 Multi-Line Hunt Groups 1 EUT: Basic call from DUT to MLHG pilot number: A is on DUT B and C are Known Goods. At this point A should not be in the MLHG. B is in the MLHG. Action: From A, dial the pilot number for the MLHG. Confirm: phone B rings. Pick up and check 2 way audio. 2 EUT: Basic call to MLHG pilot number with DUT in MLHG: A is on DUT. B and C are Known Goods. A and B should now be in the MLHG (and no other lines should be in the MLHG). Action: From A, dial the pilot number for the MLHG. Confirm: phone B rings. Pick up and check 2 way audio. 3 EUT: Call to MLHG pilot number while one MLHG member is off hook: A is on DUT B and C are Known Goods. A and B should now be in the MLHG (in that order) with C outside. If A is a SIP line, then going off hook is not sufficient. You must make sure the phone is on DND, or that all available lines* are in a call. * - this must match the MCA configured on the switch. Action: Take A off hook. From C, dial the MLHG pilot number. Confirm: Phone B rings. Pick up and check 2 way audio. 4 EUT: Call to MLHG pilot number. One of the MLHG members has DND enabled: A is on DUT B and C are Known Goods. A and B should now be in the MLHG with C outside. A should come before B in the MLHG member order. Action: Enable DND on A. From C, dial the pilot number for the MLHG (D). Confirm: Phone B rings. Pick up and check 2 way audio. 5 EUT: Call the MLHG from four lines consecutively: A is on DUT B and C are Known Goods. Phones E, F, G are known good. A and B should now be in the MLHG with C outside. Queuing is configured on the MLHG, length 1, timeout 15s. If you are using SIP lines with multiple call appearances, be aware that a line is not busy unless all call appearances are in use, or the phone is set to DND on the switch. Sending back a 486 busy for a call appearance that the switch thinks is active will tend to result in the call getting busy treatment (e.g. voicemail) rather than queued. Action: From C, E, F, G, dial the pilot number for the MLHG (D) Confirm: phone A, B rings. Pick up and check 2 way audio. Call F is queued; check that it is treated as busy after 15 seconds. Call from G is rejected.

30 Multiple Appearance Directory Number 1 EUT: MADN Lines - multiple lines available: A, B are on DUT. C, D and E are Known Goods. A MADN Number is configured to contain both A and B. Action: From C dial the MADN number Confirm: Phone A and phone B ring simultaneously. Action: Answer phone A Confirm: Phone B stops ringing, and phone A is connected to phone C. 2 EUT: MADN Lines - one line available: A, B are on DUT C, D and E are Known Goods. A MADN Number is configured to contain both A and B If you are testing using SIP lines with multiple call appearances, remember that being in one call will not prevent further calls from being sent to another call appearance. All call appearances must be in calls, or you must use DND. Action: Establish a call between D and A. Action: From C dial the MADN number. Confirm: Only phone B rings. Action: Hang up phones A and D. Confirm: Phone B continues to ring. Action: Pick up phone B. Confirm: Phone B is connected to phone C 3 EUT: MADN Lines - no lines available, queuing: A, B are on DUT C, D and E are Known Goods. A MADN Number is configured to contain both A and B If you are using SIP lines with multiple call appearances, make sure all call appearances are in use or use DND on a line. Action: Establish a call between D and A. Action: Establish a call between C and B. Action: From E dial the MADN number. Confirm: E is queued (hears ring back). Action: Hang up A and D. Confirm: A starts to ring with call from E. Action: Pick up A. Confirm: 2-way media between A and E. Media Gateway Protection Switch Support 1 EUT: Perform Call Agent/ Media Gateway protection switch while active call in progress --->verify all established calls remain up during and after protection switch.

31 Out of Band DTMF Receipt (RFC2833) 1 EUT: DTMF signals received using direct media: A is the DUT B is a known good. Configure both A and B to use direct media. Action: Establish a call from B to A such that A runs a service requiring DTMF input. Action: Using B, enter the required DTMF digits Confirm: Using Wire shark, confirm that the DTMF digits have been sent out of band Confirm: The service on A is run correctly following correct receipt of RFC2833 Out-of-band DTMF digits. 2 EUT: DTMF signals received using indirect media: A is the DUT B is a known good. Configure both A and B to use indirect media (such that the media goes via the Softswitch media gateway). Action: Establish a call from B to A such that A runs a service requiring DTMF input. Action: Using B, enter the required DTMF digits. Confirm: Using Wire shark, confirm that the DTMF digits have been sent out of band. Confirm: The service on A is run correctly following correct receipt of RFC2833 Out-of-band DTMF digits. 3 EUT: RFC2833 DTMF Transmission: Configure the device to use out-of-band DTMF. It may be necessary to modify the MG model to "require out-of-band DTMF for all codec's" and/or "only supports sending [i.e. sending but not receiving] out-of-band DTMF". Make sure A and B are configured without "restricted direct media". Run the whole test collecting pcap trace from a hub next to the DUT. Action: Call from A to B. Action: Press a sequence of digits on the keypads of A and B. Confirm: you hear the same sequence through the earpieces/speakers of A and B. Confirm: check the pcap trace to confirm that the digits were sent out of band. 4 EUT: RFC2833 DTMF Transmission - check the switch can process the digits: Configure the device to use out-of-band DTMF. It may be necessary to modify the MG model to "require out-of-band DTMF for all codec's" and/or "only supports sending [i.e. sending but not receiving] out-of-band DTMF". Run the whole test collecting pcap trace from a hub next to the DUT. Action: Dial the selective call forwarding service using *63 Action: Toggle the service on or off by dialing "3". Confirm: Softswitch announces that selective call forwarding has been switched on/off. Confirm: Use the pcap trace to confirm that the digits were sent out of band (If you have EMS access - confirm that the status of "Selective Call Forwarding" is correctly displayed as on/off). Fault Tolerance and Disconnection 1 EUT: Rebooting the device: Initiate and receive call, reboot the SIP endpoint ----> verify the IP endpoints become available again after reboot and new call can be initiated and receive. 2 EUT: Network interface failure: Establish a call from SIP end point A to SIP endpoint B, disconnect the device's network interface ---> Verify the call is torn down/ disconnected. Hang up B and try to call A.-----> Verify Call is rejected. Reconnect the device's network interface, call A from B --->Verify new call can be initiated and receive successfully. 3 EUT: While active calls are in progress, disconnect or change route statement on the switch or router that hosts the softswitch ---> Characterize the recovery of device under test after network outage and verify inbound and outbound calls can be initiated and received.

32 PC Client and SIP Endpoint Basic Call 1 EUT: SIP endpoint to PC Client: Originator disconnect after answer 2 EUT: PC Client to SIP endpoint: Originator disconnect after answer 3 EUT: SIP endpoint to PC Client: Terminator disconnect after answer 4 EUT: PC Client to SIP endpoint: Terminator disconnect after answer 5 EUT: SIP endpoint to PC Client: Originator disconnect before answer 6 EUT: PC Client to SIP endpoint: Originator disconnect before answer E-911 Support 1 EUT: Originate an emergency assistance call from SIP line ---> Verify that call connects successfully to E- 911 Server or simulator. A goes onhook, A goes offhook (without dialing any digits), and A is re-connected to E-911 Server. 2 EUT: Originate an emergency assistance call (911) from SIP line to E-911 server ---> Verify that call completes successfully. Verify 2-way speech path. Verify connection is suspended when onhook is initiated at A. Initiate an operator ring back request from e-911 Server. Verify connection is restored when offhook is initiated at A. Initiate a second operator ring back request while A is offhook.

33

34