Avaya sipXecs

 Interop Online

Introduction

This server runs sipXecs with a custom "interop" configuration designed to exercise issues we have found are important to interoperability with SIP User Agent clients. It is provided by Avaya in cooperation with the SIPfoundry sipXecs project for open interoperability testing of SIP user agents.

This server is freely available to all, but Avaya does not provide any free support for diagnosing problems you have with these tests. For SIP interoperability assistance with sipXecs, post a message on the sipXecs Developer Mailing List.

NOTE WELL: All communication with this server is logged and used under the "SIPit rules": It may be used by Avaya for internal testing and development, and aggregate information may be released to other parties. Avaya will not deliberately release to other parties any information identifiable to a specific user, product, or company.

Information about your use of this server is visible to the public through debugging interfaces provided here, and through normal SIP capabilities.

Any information you obtain about other users of this server you may use only under the SIPit rules.

You should bring your implementation to SIPit to do thorough interoperability testing with dozens of other implementations.

Links

The configuration of this server.

The registrations on this server.

Dialog Event Package Analysis - Extension:

Testing Setup

The Interop Server is setup to allow multiple simultaneous users by dividing the four digit test extensions up into groups numbered 01 through 99.  Each group consists of nine extensions that can be registered: 1gg1 through 1gg9, where "gg" is the group number.  You will need only one group number to complete the testing outlined in this document.

To select a free group number view the Registrations page.  This is a list of the extensions that are currently registered on the Interop Server.  Find a group number that has no registered extensions.  This will be your group number, hereafter referred to as gg.

The credentials for the nine test extensions are:

Address of Record

sip:1ggX@interop.sipsw.com (for X=1..9)

Username / Extension

1ggX (The user part from the Address of Record)

Realm

interop.sipsw.com

Password

1234

Once you have registered a phone using a free group number, you may consider that group number reserved for the duration of your testing.  Please un-register your phones upon completion. 

Test Cases

  1. Initial Registration and Registration Refresh
  2. Basic Call
  3. Message Waiting Indication Activation
  4. Dual-Tone Multi-Frequency and Message Waiting Indication Deactivation
  5. User Interface Feedback of 403 (Forbidden) Response
  6. Handling of a 483 (Too Many Hops) Response with "sipfrag" Body
  7. User Interface Feedback of 483 (Too Many Hops) Response
  8. Handling of a 482 (Loop Detected) Response with "sipfrag" Body
  9. User Interface Feedback of 482 (Loop Detected) Response
  10. Accept a Blind Transfer as the Transferee
  11. Initiate a Blind Transfer
  12. Initiate a Consultative Transfer
  13. Forked INVITE - Multiple Serial 18x Responses
  14. Forked INVITE - Multiple Parallel 18x Responses
  15. Handling of a Long Via Path Resulting in Large Messages
  16. Detection and Handling of a Merged INVITE Loop
  17. Call Pick-up - Receiving a Call that is Picked-up
  18. Call Pick-up - Making a Call that is Picked-up
  19. Call Pick-up - Performing a Call Pick-up
  20. Forked Call Pick-up - Making a Forked Call that is Picked-up
  21. Call Park - Retrieved
  22. Call Park - Retrieving
  23. Dialog Event Package Contents
  24. Music On Hold
  25. Ad-hoc Conference
  26. DNS SRV Query - UDP
  27. DNS SRV Query - TCP
  28. Busy Lamp Field Monitoring using a Dialog-Event Resource List
  29. Multiple Dialog Event Subscriptions

1. Initial Registration and Registration Refresh

Objective: To determine whether the Test Phone correctly registers, in accordance with RFC 3261. In particular:

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Action
  • Register the Test Phone with the Interop Server.

  • Wait at least 30 minutes, or until a refresh of the Test Phone's registration is observed in a network trace.

Notes & Expected Observations

  • Successful registrations of the Test Phone will be listed on the Interop Server's Registrations page.

  • The authentication nonces provided by sipXecs are specific to the from-tag in the request. Section 8.1.3.5 of RFC 3261 requires that a re-sent request has the same from-tag as the original request, so the nonce that sipX returns in a 401/407 response can always be used in a re-send of the request.

  • The registrar returns to the UA a fictitious contact from another UA with a very short expiration time. (This behavior is allowed by RFC 3261.)

Expected Test Outcome
  • The Test Phone must successfully register.  (Registration will fail if the re-sent REGISTER request does not contain the same Call-ID and From tag as the initial REGISTER request).

  • The Test Phone must successfully refresh its registration before it expires.

  • The Test Phone must not attempt to refresh its registration sooner than 60 seconds before it expires.

2. Basic Call

Objective: To determine whether the Test Phone can dial a basic internal call. This includes correctly handling a 407 (Proxy Authentication Required) rejection of an un-authorized INVITE by re-sending the INVITE with the same Call-ID and From tag, and authorization added, in accordance with RFC 3261. Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Action
  • From the Test Phone, dial 100.

Notes & Expected Observations

  • "100" is the extension of the Interop Server's Auto Attendant. 

Expected Test Outcome
  • The call must be established, with audio heard from the Auto Attendant.

3. Message Waiting Indication Activation

Objective: To determine whether the Test Phone correctly activates Message Waiting Indication (MWI) for a waiting voicemail message.  It must do this by sending a SUBSCRIBE for the message-summary event package, and correctly reacting to the subsequent NOTIFY, in accordance with RFC 3842.

Configuration:

Test Phone Extension: 1gg1 or 1gg2.

Other Phone Extension(s): None.

Action
  • Ensure the Test Phone has SUBSCRIBE'd the message-summary event package.

  • From the Other Phone, dial 2gg1 or 2gg2.

  • Leave a voicemail message at the prompt, then hang up.

Notes & Expected Observations

  • 2gg1 and 2gg2 are direct paths to the voicemail of 1gg1 and 1gg2 respectively.

  • The Test Phone will not receive an INVITE, and will therefore not ring.

Expected Test Outcome
  • The Test Phone's MWI must become activated.

4. Dual-Tone Multi-Frequency and Message Waiting Indication Deactivation

Objective: To determine whether the Test Phone correctly: Configuration:

Test Phone Extension: 1gg1 or 1gg2.

Other Phone Extension(s): None.

Action
  • Ensure the Test Phone's MWI is activated for a waiting voicemail message.

  • From the Test Phone, dial 101 (the voicemail server.)

  • Enter 1234# (PIN) at the prompt.

  • Enter 1 to hear the message, then enter 4 to delete it.

Notes & Expected Observations

  • Entering "1234#", then "1", then "4" should result in the Test Phone sending DTMF events, and not tones in the RTP media stream.  If the Test Phone does not send DTMF events, then the voicemail server will not receive the entered PIN and will therefore deny login.

Expected Test Outcome
  • The Test Phone must be able to login to voicemail.

  • The Test Phone's MWI must become deactivated.

5. User Interface Feedback of 403 (Forbidden) Response

Objective: To determine whether the Test Phone's user interface (UI) provides feedback of the 403 (Forbidden) reason for the call failure, which is sent in accordance with RFC 3261.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): Any other 1ggX.

Action
  • From the Test Phone, dial 4ggX.

Notes & Expected Observations

  • The call will fail.  1ggX (if registered) will not ring.

Expected Test Outcome
  • The Test Phone must communicate a reason for the failure.

6. Handling of a 483 (Too Many Hops) Response with "sipfrag" Body

Objective: To determine if the Test Phone can handle a 483 (Too Many Hops) response with a "sipfrag" Message Body, in accordance with RFC 3261.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Note: The actions for test cases 6. and 7. are identical. If you are capturing network traces, then you'll only need one for these three cases.

Action
  • From the Test Phone, dial 9000.

Notes & Expected Observations

  • The call will fail with a 483 (Too Many Hops) response.

Expected Test Outcome
  • The Test Phone must abandon the failed call, and must be able to continue making and receiving calls.

7. User Interface Feedback of 483 (Too Many Hops) Response

Objective: To determine whether the Test Phone's user interface provides feedback of the 483 (Too Many Hops) reason for the call failure.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Action
  • From the Test Phone, dial 9000.

Notes & Expected Observations

  • The call will fail with a 483 (Too Many Hops) response.

Expected Test Outcome
  • The Test Phone must communicate a reason for the failure.

8. Handling of a 482 (Loop Detected) Response with "sipfrag" Body

Objective: To determine if the Test Phone can handle a 482 (Loop Detected) response with a "sipfrag" Message Body, in accordance with RFC 3261.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Note: The actions for test cases 8. and 9. are identical. If you are capturing network traces, then you'll only need one for these two cases.

Action
  • From the Test Phone, dial 9001.

Notes & Expected Observations

  • The call will fail with a 482 (Loop Detected) response.

Expected Test Outcome
  • The Test Phone must abandon the failed call, and must be able to continue making and receiving calls.

9. User Interface Feedback of 482 (Loop Detected) Response

Objective: To determine whether the Test Phone's user interface provides feedback of the 482 (Too Many Hops) reason for the call failure.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Note: The actions for test cases 8. and 9. are identical. If you are capturing network traces, then you'll only need one for these two cases.

Action
  • From the Test Phone, dial 9001.

Notes & Expected Observations

  • The call will fail with a 482 (Loop Detected) response.

Expected Test Outcome
  • The Test Phone must communicate a reason for the failure.

10. Accept a Blind Transfer as the Transferee

Objective: To determine whether the Test Phone correctly handles a REFER (without a "Replaces=" in the Refer-To header), in accordance with RFC 3515.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): Any other 1ggX.

Action
  • From the Test Phone, dial 100.

  • When prompted for an extension, enter 1ggX.

  • When 1ggX rings, answer the call.

Notes & Expected Observations

  • After entering "1ggX" on the Test Phone, ringback should be heard.

Expected Test Outcome
  • Answering 1ggX must result in the call being connected.

11. Initiate a Blind Transfer

Objective: To determine whether the Test Phone correctly initiates a blind transfer (send authenticated REFER without Replaces), in accordance with RFC 3515.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): Any other 1ggX and Any other 1ggY.

Action
  • From the Test Phone, establish a call with one of the other phones.

  • From the Test Phone, initiate a blind transfer of the call to another phone.

Notes & Expected Observations

  • If "music on hold" is configured on the Test Phone, then the transferee should hear the music as the transfer is being performed.

Expected Test Outcome
  • Upon completing the transfer, the Test Phone must not show any active calls.

12. Initiate a Consultative Transfer

Objective: To determine whether the Test Phone correctly initiates a consultative transfer, in accordance with RFC 3515.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): Any other 1ggX and Any other 1ggY.

Action
  • From the Test Phone, establish a call with one of the other phones.

  • From the Test Phone, initiate a consultative transfer of the call to another phone.

Notes & Expected Observations

  • If "music on hold" is configured on the Test Phone, then the transferee should hear the music as the transfer is being performed.

Expected Test Outcome
  • Upon completing the transfer, the Test Phone must not show any active calls.

13. Forked INVITE - Multiple Serial 18x Responses

Objective: To determine whether the Test Phone correctly handles the multiple received 18x responses with different dialogs when calling a forked destination.  In this case each 18x response will be received approximately 5 seconds apart.  When the call is answered the Test Phone must send the ACK request within the same dialog in which the 200 OK (INVITE) response was received, in accordance with RFC 3261.

Configuration:

Test Phone Extension: 1gg1, 1gg2, 1gg7, 1gg8, or 1gg9.

Other Phone Extension(s): 1gg3, 1gg4, 1gg5, and 1gg6.

Action
  • From the Test Phone, dial 5gg0.

  • One of the Other Phones will ring.  Do not answer this call.

  • After 5 seconds, a different Other Phone will ring.  Answer this call.

Notes & Expected Observations

  • A call to 5gg0 will be serially forked to 1gg3, 1gg4, 1gg5, and 1gg6 in some random order. If not answered, the first extension called will receive a CANCEL when the next is called.  The length of time the first call rings is defined by the "Default Serial Fork Expiration" setting, which has been set to 5 seconds on this server.

Expected Test Outcome
  • Answering the second ringing Other Phone must result in the call being connected with the Test Phone.

14. Forked INVITE - Multiple Parallel 18x Responses

Objective: To determine whether the Test Phone correctly handles the multiple received 18x responses with different dialogs when calling a forked destination.  In this case each 18x response will be received in quick succession.  When the call is answered, the Test Phone must send the ACK request within the same dialog in which the 200 OK (INVITE) response was received, in accordance with RFC 3261.

Configuration:

Test Phone Extension: 1gg1, 1gg2, 1gg7, 1gg8, or 1gg9.

Other Phone Extension(s): 1gg3, 1gg4, 1gg5, and 1gg6.

Action
  • From the Test Phone, dial 6gg0.

  • The Other Phones will all ring, answer one of them.

Notes & Expected Observations

  • A call to 6gg0 will be simultaneously forked to 1gg3, 1gg4, 1gg5, and 1gg6.

Expected Test Outcome
  • Answering the Other Phone must result in the call being connected with the Test Phone.

15. Handling of a Long Via Path Resulting in Large Messages

Objective: To determine whether the Test Phone correctly handles atypically long Via paths in INVITE requests that result in large messages, in accordance with RFC 3261.  If transport layer is User Datagram Protocol (UDP), then the packets will be fragmented. Configuration:

Test Phone Extension: Any 1ggX.

Other Phone Extension(s): Any other.

Action
  • From the Other Phone, dial 7ggX.

  • When the Test Phone rings, answer the call.

Notes & Expected Observations

  • A call to 7ggX will spiral several times within the Interop Server so that the INVITE request received at 1ggX it will have several Via headers.

Expected Test Outcome
  • Answering the Test Phone must result in the call being connected normally.

16. Detection and Handling of a Merged INVITE Loop

Objective: To determine whether the Test Phone correctly detects and handles an error where a single INVITE is forked and received twice, in accordance with RFC 3261.  The two INVITE requests will have the same Call-ID, Cseq, and From tag values, but different branch ids.  The Test Phone must accept the first one and return a 482 (Loop Detected) response to the second.  The call must then be connected normally when answered.

Configuration:

Test Phone Extension: Any 1ggX.

Other Phone Extension(s): Any other.

Action
  • From the Other Phone, dial 8ggX.

  • When the Test Phone rings, answer the call.

Notes & Expected Observations

  • A call to 8ggX will be forked such that two INVITE requests will be received at 1ggX with the same Call-ID, Cseq, and From tag values, but different branch ids.

Expected Test Outcome
  • The Test Phone must accept the first INVITE, and subsequently send a 482 (Loop Detected) response to the second INVITE. (Use a network trace to confirm this.)

17. Call Pick-up - Receiving a Call that is Picked-up

Objective: To determine whether the Test Phone correctly generates dialog-info event package NOTIFY requests with usable endpoint identification, in accordance with RFC 4235.

Configuration:

Test Phone Extension: Any 1ggX.

Other Phone Extension(s): Any other 1ggY and 1ggZ.

Note: If 1ggX, 1ggY, and 1ggZ are all instances of the Test Phones then the actions for test cases 17., 18., and 19. are identical. If you are capturing network traces, then you'll only need one for these three cases.

Action
  • From 1ggY, dial 1ggX, but don't answer the call.

  • From 1ggZ, dial *781ggX.

Notes & Expected Observations

  • *78 is the Directed Call Pickup code.

Expected Test Outcome
  • 1ggX (the Test Phone) must stop ringing.

  • The call between 1ggY and 1ggZ must be connected.

18. Call Pick-up - Making a Call that is Picked-up

Objective: To determine whether the Test Phone correctly handles the INVITE with a Replaces header, including the "early-only" flag, in accordance with RFC 3891.

Configuration:

Test Phone Extension: Any 1ggY.

Other Phone Extension(s): Any other 1ggX and 1ggZ.

Action
  • From 1ggY, dial 1ggX, but don't answer the call.

  • From 1ggZ, dial *781ggX.

Notes & Expected Observations

  • *78 is the Directed Call Pickup code.

Expected Test Outcome
  • 1ggX must stop ringing.

  • The call between 1ggY (the Test Phone) and 1ggZ must be connected.

19. Call Pick-up - Performing a Call Pick-up

Objective: To determine whether the Test Phone correctly handles a 200 OK response that was sent as a result of an INVITE with a Replaces header, in accordance with RFC 3891.

Configuration:

Test Phone Extension: Any 1ggZ.

Other Phone Extension(s): Any other 1ggX and 1ggY.

Action
  • From 1ggY, dial 1ggX, but don't answer the call.

  • From 1ggZ, dial *781ggX.

Notes & Expected Observations

  • *78 is the Directed Call Pickup code.

Expected Test Outcome
  • 1ggX must stop ringing.

  • The call between 1ggY and 1ggZ (the Test Phone) must be connected.

20. Forked Call Pick-up - Making a Forked Call that is Picked-up

Objective: To determine whether the Test Phone correctly handles the INVITE with a Replaces header, including the "early-only" flag, in accordance with RFC 3891. The added challenge for the Test Phone in this case is that the dialog to be replaced will be one of four early dialogs that must be tracked.

Configuration:

Test Phone Extension: 1gg1.

Ringing Phone Extensions: 1gg3, 1gg4, 1gg5, and 1gg6.

Call Pickup Phone Extension: 1gg2.

Action
  • From the Test Phone, dial 6gg0.

  • From 1gg2, dial *781gg3.

  • Disconnect the call and repeat the above sequence with 1gg2 dialing *781gg4, *781gg5, and *781gg6.
Notes & Expected Observations

  • A call to 6gg0 will be simultaneously forked to 1gg3, 1gg4, 1gg5, and 1gg6.

Expected Test Outcome
  • After each repetition of the sequence:

    All of 1gg3, 1gg4, 1gg5, and 1gg6 must stop ringing.

    The call between the Test Phone and 1gg2 must be connected.

21. Call Park - Retrieved

Objective: To determine whether the Test Phone correctly handles a REFER with a "Replaces=" in the Refer-To header, in accordance with RFC 3515.

Configuration:

Test Phone Extension: Any 1ggX.

Other Phone Extension(s): Any 1ggY

Note: The actions for test cases 21. and 22. are identical. If you are capturing network traces, then you'll only need one for these two cases.

Action
  • From the Test Phone (1ggX), dial the Other Phone (1ggY.)

  • From the Other Phone, park the call with the Test Phone by transferring it to 5gg1.

  • From the Other Phone, retrieve the parked call by dialing *45gg1.

Notes & Expected Observations

  • The extensions 5gg1 through 5gg9 are the group's park orbits.

Expected Test Outcome
  • The Test Phone must hear Park audio while parked.

  • The call must be re-connected normally when the Test Phone is un-parked.

22. Call Park - Retrieving

Objective: To determine whether the Test Phone correctly handles the INVITE with a Replaces header (without the "early-only" flag) in accordance with RFC 3891.

Configuration:

Test Phone Extension: Any 1ggY.

Other Phone Extension(s): Any 1ggX

Note: The actions for test cases 21. and 22. are identical.  If you are capturing network traces, then you'll only need one for these two cases.

Action
  • From the Other Phone (1ggX), dial the Test Phone (1ggY.)

  • From the Test Phone, park the call with the Other Phone by transferring it to 5gg1.

  • From the Test Phone, retrieve the parked call by dialing *45gg1.

Notes & Expected Observations

  • The extensions 5gg1 through 5gg9 are the group's park orbits.

Expected Test Outcome
  • The Other Phone must hear Park audio while parked.

  • The call must be re-connected normally when the Other Phone is un-parked.

23. Dialog Event Package Contents

Objective: To determine if the dialog event package contents generated by the Test Phone are in accordance with Internet-Draft draft-worley-sip-dialog-03 - "Guidelines for Implementing the Dialog Event Package in User Agents".

Configuration:

Test Phone Extension: Any 1ggX.

Other Phone Extension(s): Any other 1ggY and 1ggZ.

Note: The actions for test case 17. are identical to this one, and may not need to be repeated.

Action
  • From 1ggY, dial 1ggX.

  • From 1ggZ, dial *781ggX.

Notes & Expected Observations

  • The dialog event package will be analyzed against some of the criteria in the Internet-Draft draft-worley-sip-dialog-03.  Violations of the guidelines are marked in red.

  • Test Phone Extension (1ggX):

Expected Test Outcome
  • "User-Agent:" must match the Test Phone.

  • "NOTIFY bodies without <dialog-info> elements:" must read "None found".

  • "Content-Type application/dialog-info+xml header:" must read "Present".

  • "Subscription-State header:" must read "Present", with a reformatted eXtensible Markup Language (XML) body shown.

  • "XML syntax:" must read "Passed".

  • The subsequent 12 "Guideline" items must have no red violations.

24. Music On Hold

Objective: To determine whether the Test Phone correctly provides "music on hold" (MOH) in accordance with the technique described in draft-worley-service-example-01 - "Session Initiation Protocol Service Example - Music on Hold".

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): Any other.

Action
  • On the Test Phone, set the configuration of the MOH audio source Uniform Resource Identifier (URI) to "sip:~~mh~@interop.sipsw.com".

  • Establish a call between the Test Phoneand the Other Phone.

  • From the Test Phone, place the call on hold.

  • Note what is heard on the Other Phone, which is on hold.

  • From the Test Phone, take the call off hold.

Expected Test Outcome
  • The Other Phone must hear MOH audio while on hold.

  • The call must be re-connected normally when the Other Phone is taken off hold.

25. Ad-hoc Conference

Objective: To determine whether the Test Phone can correctly initiate and host a three-party conference, in accordance with RFC 3261.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): Any two.

Action
  • From the Test Phone, initiate and host a three-party conference with the two Other Phones.

  • Disconnect one of the Other Phones.  Note whether the Test Phone and the remaining Other Phone are still connected.

  • Disconnect the remaining Other Phone.

Expected Test Outcome
  • The conference must be established with voice path between all participants.

  • When one of the Other Phones disconnects to leave the conference, the call between the Test Phone and the remaining Other Phone must still be connected.

26. DNS SRV Query - UDP

Objective: To determine whether the Test Phone correctly performs DNS Service Record (SRV) record queries for the SIP service using the UDP transport layer, in accordance with RFC 3263.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Action
  • On the Test Phone, set the configuration of the SIP service transport layer to UDP, and set the SIP realm to udp.interop.sipsw.com.

  • Restart the Test Phone (or otherwise re-initializes it's SIP service.)

  • Wait until the Test Phone has completed its restart/re-initialization, or until a DNS SRV query for _sip._udp.interop.sipsw.com is observed in a network trace.
Notes & Expected Observations

  • This server's configuration supports the SIP domain udp.interop.sipsw.com. The Test Phone however will fail to register if a DNS record for this domain does not exist.

  • The important part of the test case is whether the Test Phone makes the appropriate DNS SRV query.

Expected Test Outcome
  • The Test Phone must perform a DNS SRV query for _sip._udp.udp.interop.sipsw.com, which must be observed in a network trace.

27. DNS SRV Query - TCP

Objective: To determine whether the Test Phone correctly performs DNS SRV record queries for the SIP service using the Transmission Control Protocol (TCP) transport layer, in accordance with RFC 3263.

Configuration:

Test Phone Extension: Any.

Other Phone Extension(s): None.

Action
  • On the Test Phone, set the configuration of the SIP service transport layer to TCP, and set the SIP realm to tcp.interop.sipsw.com.

  • Restart the Test Phone (or otherwise re-initializes it's SIP service.)

  • Wait until the Test Phone has completed its restart/re-initialization, or until a DNS SRV query for _sip._tcp.interop.sipsw.com is observed in a network trace.

Notes & Expected Observations

  • This server's configuration supports the SIP domain tcp.interop.sipsw.com. The Test Phone however will fail to register if a DNS record for this domain does not exist.

  • The important part of the test case is whether the Test Phone makes the appropriate DNS SRV query.

Expected Test Outcome
  • The Test Phone must perform a DNS SRV query for _sip._tcp.tcp.interop.sipsw.com, which must be observed in a network trace.

28. Busy Lamp Field Monitoring using a Dialog-Event Resource List

Objective: To determine whether the Test Phone correctly performs Busy Lamp Field (BLF) monitoring using a Dialog-Event Resource List, in accordance with RFC 4235 and RFC 4662.

Configuration:

Test Phone Extension: 1gg2.

Other Phone Extension(s): 1gg6 and 1gg9.

Action
  • Ensure Other Phone 1gg9 is not connected to the network.

  • On the Test Phone, set the configuration of the Resource List URI to one of the following, depending on which Resource List format is supported:

    • Full RFC 4662 - sip:~~rl~F~gg@interop.sipsw.com

    • Broadworks Restricted - sip:~~rl~C~gg@interop.sipsw.com

  • On the Test Phone, set the configuration to perform BLF monitoring of extensions 1gg2 (self), 1gg6, and 1gg9.

  • Note the initial state of the Test Phone's BLF indications. They should all be "idle".

  • From the Test Phone, dial 1gg6 and wait for it to ring.

  • Note the Test Phone's BLF indications. 1gg2 should be "on a call", and 1gg6 should be "ringing".

  • Answer 1gg6.

  • Note the Test Phone's BLF indications. 1gg2 and 1gg6 should both be "on a call".

  • From 1gg6, put the active call on hold.

  • Note the Test Phone's BLF indications. 1gg2 and 1gg6 should still both be "on a call".

  • Connect Other Phone 1gg9 to the network, and wait 30 seconds after it has registered.

  • From 1gg6, dial 1gg9 and wait for it to ring.

  • Note the Test Phone's BLF indications. 1gg2 and 1gg6 should still both be "on a call", and 1gg9 should be "ringing".

  • Answer 1gg9.

  • Note the Test Phone's BLF indications. 1gg2, 1gg6, and 1gg9 should all be "on a call".

  • From 1gg9, disconnect the call with 1gg6.

  • Note the Test Phone's BLF indications. 1gg2 and 1gg6 should still both be "on a call", and 1gg9 should be "idle".

  • From 1gg6, take the call with the Test Phone off hold.

  • Note the Test Phone's BLF indications. 1gg2 and 1gg6 should still both be "on a call".

  • From 1gg6, disconnect the call with the Test Phone.

  • Note the Test Phone's BLF indications. They should all be "idle".

Notes & Expected Observations

  • The challenge for a Test Phone that does not use a Resource List will be in BLF monitoring Other Phone 1gg9 after it is connected to the network, and registers.  It is possible to correctly perform BLF monitoring without a Dialog-Event Resource List, but this creates redundant network traffic and unnecessary load on the call server and endpoints.

Expected Test Outcome
  • The Test Phone must show each BLF indication change from the Actions above.

  • The Test Phone's use of a Resource List for BLF monitoring is a requirement.  If the Test Phone performs direct endpoint Dialog-Event subscriptions for BLF monitoring, then it fails this test case.

29. Multiple Dialog Event Subscriptions

Objective: To determine whether the Test Phone correctly maintains multiple subscriptions to its Dialog Event status, in accordance with RFC 4235.

Configuration:

Test Phone Extension: 1gg6 or 1gg9 (1ggX.)

BLF Phone Extension: A phone configured to perform BLF monitoring of 1ggX, such as the Test Phone from case 28. above.

Call Pickup Phone Extension: Any other.

Action
  • From the BLF Phone Extension, dial 1ggX, but don't answer the call.

  • From the Call Pickup Phone Extension, dial *781ggX. Answer, and then hangup that call.

  • Note the BLF Phone's BLF indication. 1ggX should be "idle".

  • From the Call Pickup Phone Extension, dial 1ggX.

Notes & Expected Observations

  • The first Dialog Event subscription to the Test Phone is established for BLF monitoring. The call pickup requires a second Dialog Event subscription to the Test Phone, which is cancelled after the call pickup has been completed.

Expected Test Outcome
  • The BLF indication for 1ggX should show "ringing" for the second call. This shows that the Test Phone was able to handle multiple subscriptions to its Dialog Event status.