Depreciated... Users should setup their own servers for Interop

This server is no longer available. This page is left here for historical perspective and for users who may want to do their own interop.

sipXecs / openUC Interop Online

This test server is provided by eZuce Inc., in cooperation with SIPfoundry, for open interoperability testing of SIP user agents. This server runs eZuce openUC software with a custom configuration. This configuration is designed to exercise issues we have found are important to interoperability between User Agents and sipXecs / openUC. It is not intended to be a complete SIP testbed.
This server is freely available to all, but eZuce does not provide any free support for diagnosing problems you have with these tests. If you are in need of help, consulting may be available for a fee; contact < interop at ezuce dot com>
NOTE WELL: All communication with this server is logged and used under the "SIPit rules": It may be used by eZuce Inc. for internal testing and development, and aggregate information may be released to other parties. eZuce Inc. 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.

Addresses

The tests below are organized so that they can be used by more than one tester at a time - if you pick your own group of extensions. Pick a number between 10 and 19 - this is your group number; in the addresses below, the group number is shown as "gg". If you are having odd behavior try another group number as somebody else may be testing on the same group. If you continue to have registration and test problems please contact the interop email address mentioned above.
Each group consists of 10 addresses that you can register:
sip:1gg0@interop.ezuce.com sip:1gg1@interop.ezuce.com sip:1gg2@interop.ezuce.com sip:1gg3@interop.ezuce.com sip:1gg4@interop.ezuce.com sip:1gg5@interop.ezuce.com sip:1gg6@interop.ezuce.com sip:1gg7@interop.ezuce.com sip:1gg8@interop.ezuce.com sip:1gg7@interop.ezuce.com

Registration

The credentials for the test addresses are:
Address Of Record
For DNS SRV Tests:
sip:1ggn@interop.ezuce.com(for n= 0..9)
For A Record Tests:
sip:1ggn@sip.interop.ezuce.com(for n= 0..9)
User Name
1ggn(The user part of the address)
Domain / Realm
interop.ezuce.com
Password
1234
Confirm that your UA is refreshing its registration correctly - note that the registrar randomizes the expiration time of each register request, so it will normally be less than the requested time. If the UA does not pay attention to the registration time granted, the UA's registration will repeatedly appear and disappear.
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 sipXecs returns in a 401/407 response can always be used in a re-send of the request. However, some UAs will incorrectly use a different from-tag when resending a REGISTER. These UAs will not be able to register.
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.) Some UAs respond incorrectly to the short expiration time by immediately re-registering. A red value in the "CSeq" column of the registrations page means that the UA has incorrectly sent more than 2 registrations in the last 5 minutes, which indicates it probably has this error.

DNS SRV Record Registration & Processing

This server supports the SIP domains interop.ezuce.com and sip.interop.ezuce.com.
The interop.ezuce.com domain name does not have DNS A records, rather it is configured with DNS SRV records for the UDP (_sip._udp.interop.ezuce.com) and TCP (_sip._tcp.interop.ezuce.com) protocols. A UA should support DNS SRV records and both the UDP and TCP protocols.
To pass verification tests UAs should be able to register to interop.ezuce.com domain with TCP and with UDP and place calls in all of the following tests.
Additionally, the UAs should be able to register to sip.interop.ezuce.com domain (A Record) and place calls in all of the following tests.

Confirming Basic Functionality

A call to "sip:100@interop.ezuce.com" will be answered by an auto-attendant. Any SIP UA can call a registered UA by calling its AOR, "sip:1ggn@interop.ezuce.com".

The Tests

1. DTMF Generation and Message Waiting Indication (MWI)

The addresses each have a voicemail box; they may SUBSCRIBE for the message-summary event package. You can call the voicemail box directly by calling user 81ggn to deposit voicemail.
Voicemail can be retrieved by calling 101 from UAs registered as 1gg1 and 1gg2. The voicemail PIN is the same as the SIP registration password for the AOR. The voicemail server interprets RFC 2833 DTMF packets.

2. Authenticated INVITE (407 Proxy Authentication Required)

A call to any extension will always be challenged for authentication, and when successfully authenticated will ring 1ggx.

3. Authenticated INVITE (403 Forbidden)

A call to 41ggx (for any x 1-9) will be challenged for authentication, but even when authenticated only a caller with an extension ending in 7, 8, or 9 is allowed to complete the call (which will ring1ggx). Any other caller will get a 403 Forbidden response. This allows you to test whether or not your user interface communicates the reason for the call failure.

4. Transfer

Most transfer operations are between endpoints in SIP, but you can use this system to make sure that you are doing those operations in a way that operates correctly through a proxy.
There are some specific things to check:
Check whether or not your UA accepts a blind transfer
Whether or not your UA cannot act as the controller for a blind transfer, you can test whether or not it correctly handles being the transferee; a call to "sip:100@interop.ezuce.com" will be answered by an auto-attendant - when you enter a registered extension at the prompt (your UA must use RFC 2833 to send DTMF in the RTP), the auto-attendant will blind-transfer your call (REFER without Replaces).
Authenticated blind transfer
If your UA initiates a blind transfer (sends REFER without Replaces) to any registered UA, the REFER request will be challenged by the proxy with a 407 response. The transfer controller UA must retry the request with authentication added.
The authenticated request will be forwarded by the proxy to the transferee, with a header parameter added to the Refer-To (transfer target) URL. The transferee UA must correctly include the specified header (X-Sipx-Authidentity) in the INVITE it sends to the transfer target. You can test whether or not your UA constructs this header correctly by transferring it to 1ggx. This path is challenged unless authenticated by the above header; if the header is correct, the call will be routed to 1ggx (see Authenticated INVITE test above).
Check consultative transfer
If your user agent(s) can do consultative transfer (REFER with Replaces), then you should also try that through the proxy using another UA. The REFER for a consultative transfer is not challenged for authentication.
Check "semi-consultative" transfer
It is common for the person attempting a consultative transfer to exit from the process with the expectation that the party being transferred will talk to the party that ultimately answers the new call – in effect, to convert a consultative transfer into a blind transfer. Some user agents do not provide a separate blind transfer operation, so the user must use a semi-consultative transfer. With other user agents, users often never discover how to activate the blind transfer operation, and so do semi-consultative transfers instead.
The reliable way for a user agent to carry out this operation is to continue with the consultative transfer sequence until the called party answers, and then send the REFER with Replaces that completes the consultative transfer. This has been known for years, and yet many user agents use unreliable (and sometimes bizarre) methods to handle semi-consultative transfers.
You can verify that your user agents generate the same message flow for semi-consultative transfers that they do for consultative transfers by capturing the call and searching for the substring "1gg".

5. Serial Forking

A call to 5gg0 will be forked to 1gg0, 1gg1, 1gg2, … 1gg9 in numerical order ringing for 5 seconds each. If not answered, the first extension called will receive a CANCEL when the next is called. Make sure that your caller connects with the UA that answers, and that all the others correctly clean up the canceled requests. Note that ringing four contacts can take quite a while, and the calling UA or the sipXecs / openUC proxy may time out the call attempt before all four UAs ring.

6. Parallel Forking

A call to 6gg0 will be simultaneously forked to 1gg0, 1gg1, 1gg2, … 1gg9. When one UA answers, the others will receive a CANCEL. Make sure that your caller connects with the UA that answers, and that all the others correctly clean up the canceled requests.

7. Long Paths / Large Messages

A call to 7ggx (for any x 1-9) will spiral several times within the proxy so that when received at 1ggx it will have several Vias. This checks your handling of large messages (if UDP, they will be fragmented).
[We've attempted to replicate this functionality with dial plan entries that loop through the dial plan 4 times. Please let us know if this meets testing requirements.]

8. Call Pick-Up

Any call to *78xxxx will pick up the call ringing on the UA at xxxx. To use this feature:

From one UA, call a second UA via 1ggn.
Leave the call ringing.
From a third UA, call *781ggn.
The third UA should now be talking to the first UA, and the second should no longer be ringing.
If the second UA answers the call before the third UA calls *781ggn, the third UA should receive a 404 response rather than connecting to the first UA.

This test should work whether or not the first or third UAs are registered to the test server.
This test checks that the first UA correctly handles INVITE with Replaces and the early-only option, and whether the second UA generates dialog event notices with usable endpoint identification.

9. Call Pick-Up of a Hunt Group Parallel Forked Call

10. Call Pick-Up of a Parallel Forked Call

Register UAs, the target UAs, for AORs 1gg3, 1gg4, 1gg5, and 1gg6.
From another UA, the calling UA, call 6gg0, which will be simultaneously forked to 1ggn (n=0-9).
The call should ring on 1ggn.
From yet another UA, the executing UA, call *781gg3. It should pick up the call, ending the ringing on the target UAs and establishing a call between the executing UA and the calling UA.
Hang up and repeat the sequence, changing the second call to *781gg4, *781gg5, and *781gg6 on successive trials. Each should pick up the forked call.
This test checks that the calling UA correctly tracks the four early dialogs generated by the forked call.

11. Call Park and Retrieve Blind Transfer

The extensions 5gg1 is a park orbit. (The extensions 5gg0 are used in the Serial Forking test described above.) If a call is transferred to a park orbit, it will connect to the park server user agent, which plays music. A call can be retrieved from a parking orbit by calling *4xxxx, where xxxx is the parking orbit. If there are several calls parked on the same orbit, the one that was parked there first is retrieved.
Call from one of your UA's to another. On the receiving UA use a blind (unattended) transfer to transfer the call to 5gg1.
On another UA retrieve the call with *45gg1.
This test checks that the parked UA handles in-dialog REFERs and the retrieving UA handles INVITE with Replaces.
You can subscribe to the call park extensions to get their dialog events.

12. Call Park and Retrieve Consultative Transfer

The extensions 5gg1 is a park orbit. (The extensions 5gg0 are used in the Serial Forking test described above.) If a call is transferred to a park orbit, it will connect to the park server user agent, which plays music. A call can be retrieved from a parking orbit by calling *4xxxx, where xxxx is the parking orbit. If there are several calls parked on the same orbit, the one that was parked there first is retrieved.
Call from one of your UA's to another. On the receiving UA use a consultative (attended) transfer to transfer the call to 5gg1. Initially on hearing the park orbit audio, complete the transfer.
On another UA retrieve the call with *45gg1.
This test checks that the parked UA handles in-dialog REFERs and the retrieving UA handles INVITE with Replaces.
You can subscribe to the call park extensions to get their dialog events.

13. Music on Hold

User agents that provide "music on hold" via the technique of http://tools.ietf.org/pdf/draft-worley-service-example-08.pdf can use the URI sip:~_mh@interop.ezuce.com as an audio source. (This source should work with other MoH techniques as well.)

14. Double-Hold Scenarios

The purpose of these tests is to verify that two UAs can handle when both UAs put the opposite ends of one call on hold. It is most informative when both UAs are configured to generate music-on-hold.
First test:

Call from the first UA to the second UA.
At the first UA, put the call on hold.
The second UA should receive music-on-hold.
At the second UA, put the call on hold.
At the second UA, take the call off hold.
The second UA should receive music-on-hold.
At the first UA, take the call off hold.
The UAs should pass audio in both directions.

Second test:

Call from the first UA to the second UA.
At the first UA, put the call on hold.
The second UA should receive music-on-hold.
At the second UA, put the call on hold.
At the first UA, take the call off hold.
The first UA should receive music-on-hold.
At the second UA, take the call off hold.
The UAs should pass audio in both directions.

15. Hold-and-Transfer Scenarios

The purpose of these tests is to verify that a UA continues to produce music-on-hold after the other UA has transferred the call.
First test:

Call from the first UA to the second UA. Answer the call.
At the first UA, put the call on hold.
The second UA should receive music-on-hold.
At the second UA, execute a blind transfer to a third UA.
Answer the call at the third UA.
The third UA should receive music-on-hold (from the first UA).

Second test:

Call from the first UA to the second UA. Answer the call.
At the first UA, put the call on hold.
The second UA should receive music-on-hold.
At the second UA, initiate a consultative transfer to a third UA.
Answer the call at the third UA.
At the second UA, finish the consultative transfer.
The third UA should receive music-on-hold (from the first UA).

Third test:

Call from the second UA to the third UA. Answer the call.
At the second UA, initiate a consultative transfer to the first UA.
Answer the call at the first UA.
At the first UA, put the call on hold.
At the second UA, finish the consultative transfer.
The third UA should receive music-on-hold (from the first UA).

16. BLF (Busy Lamp Field) and Dialog-Event Resource Lists

Some UAs can subscribe to a resource list of dialog events to obtain and display BLF information. BLF (Busy Lamp Field) is a feature of a UA where it displays the busy/not-busy statuses of other AORs (extensions). This server provides a resource list URI "sip:~_rl~Fgg@interop.ezuce.com" which includes the statuses of "sip:1gg1@interop.ezuce.com", "sip:1gg6@interop.ezuce.com", and "sip:1gg9@interop.ezuce". The dialog events generated for these resource list URIs are in full RFC 4662 format, including listing the status of each registered UA for each AOR separately. If your UA requires dialog events in the more restricted format provided by Broadworks (Compact), it should subscribe to the URI "sip:~_rl~Cgg@interop.ezuce.com".
As a consequence of maintaining the resource lists, the server maintains a dialog event subscription to all UAs registered to the URIs "sip:1gg1@interop.ezuce.com", "sip:1gg6@interop.ezuce.com", and "sip:1gg9@interop.ezuce.com". Beware that some UAs cannot serve more than one dialog event subscription. Such UAs should not register for these AORs, and will not work consistently with any sipXecs / openUC feature that requires dialog events, including call pick-up.

17. Multiple Dialog Event Subscriptions

SIP requires that a UA can support multiple subscriptions to its dialog event status. A UA can be tested to ensure that it supports multiple dialog event subscriptions:
Register the UA as 1gg1, 1gg6, or 1gg9. Configure a second UA to display BLF information from "sip:~_rlgg@interop.ezuce.com". In sipXecs / openUC "sip:~_{rl~EXTENSION@domain" will default to Full resource list (sip:}~rl~F~EXTENSION@domain) and not Compact (Broadworks).
From a third UA, call the first UA. The first UA should ring, and the second UA's BLF should indicate that the first UA is ringing.
From a fourth UA, pick up this call by calling *781ggn, as appropriate. The fourth UA will be talking to the third UA. Hang up this call. The second UA's BLF should indicate that the first UA is idle.
From the third UA, call the first UA again. Answer the call at the first UA. The second UA's BLF should indicate that the first UA is busy.

18. BLF Status Display

This test shows whether a UA sends comprehensive status information, and whether a second UA's BLF correctly and comprehensively displays status information.
Register a first UA as 1gg1 and a second UA as 1gg6. Configure a third UA to display BLF information from "sip:~_rlgg@interop.ezuce.com".
Initially, the third UA should show the first and second UAs as idle.
Take the first UA off-hook and start (but not finish) dialing 1gg6. The third UA should show the first UA as in-use (state "trying") and the second UA as idle.
Finish dialing on the first UA. The second UA should ring. The third UA should show the first UA as in-use (state "early", direction "initiator") and the second UA as ringing (state "early", direction "recipient").
Answer the call on the second UA. The third UA should show the first and second UAs as in-use (state "confirmed").
At the first UA, put the call on hold. The third UA should show the first UA as on-hold (state "confirmed" with local feature parameter +sip.rendering=no), and the second UA as in-use.
At the first UA, take the call off hold. The third UA should show the first and second UAs as in-use (state "confirmed").
At the first UA, hang up the call. The third UA should show the first and second UAs as idle.

19. BLA – Bridged Line Appearance (Optional)

Many users would like to use a traditional 'key system' feature where one user puts a call on hold and another user can pickup that call just by pressing the same monitored registration. As in test 16, this requires that a UA can support multiple subscriptions to its dialog event status.
Register the first UA as 1gg1, 1gg6, or 1gg9. Configure a second UA to display BLF information from "sip:~_rlgg@interop.ezuce.com".
From a third UA, call the first UA. The first UA should ring, and the second UA's BLF should indicate that the first UA is ringing.
On the first UA, answer the call. Place the call on hold. The second UA should indicate that the call is on hold.
On the second UA press the line key that represents the held call. The held call should be transferred to the second UA and the second UA should have a conversation with the third UA.

20. Proxy Loop Detection

Any call to 9001 will return a 482 Loop Detected error. As a diagnostic aid, this software returns part of the failed request in the body of the 482 response. This allows you to test whether or not your user interface conveys the reason for the failure (and is not troubled by the response body). For information on the motivation for this response construction, see Diagnostic Responses for Session Initiation Protocol Hop Limit Errors.

Browser not supported