This test server is provided by Pingtel for open interoperability testing of SIP user agents. It is the sipXpbx sipXpbx open source software with a custom configuration. This configuration is designed to exercise issues we have found are important to interoperability between User Agents and Proxies. This server is restarted once a week, at 00:00 Sunday UTC. The restart process takes approximately 2 minutes.
Display the sipX version running on this server
Display the configuration version running on this server
This server is freely available to all, but Pingtel does not provide any free support for diagnosing problems you have with these tests. If you are in need of help, consulting is available for a fee; contact <interop-config(at)pingtel(dot)com>.
NOTE WELL: All communication with this server is logged and used under the "SIPit rules": It may be used by Pingtel for internal testing and development, and aggregate information may be released to other parties. Pingtel 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.
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 99 - this is your group number; in the addresses below, the group number is shown as "gg". To see if the group number you have chosen is in use, check the registrations page - look for any User values that use that group number. Each group consists of 9 addresses that you can register:
sip:1gg1@interop.pingtel.com
sip:1gg2@interop.pingtel.com
sip:1gg3@interop.pingtel.com
sip:1gg4@interop.pingtel.com
sip:1gg5@interop.pingtel.com
sip:1gg6@interop.pingtel.com
sip:1gg7@interop.pingtel.com
sip:1gg8@interop.pingtel.com
sip:1gg9@interop.pingtel.com
The credentials for the test addresses are:
sip:1ggn@interop.pingtel.com
1ggn
interop.pingtel.com1234The database of current registration information can be seen on the registrations page.
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.
The authentication nonces provided by sipX 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. 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.
A call to "sip:100@interop.pingtel.com" will be answered by an
auto-attendant.
Any SIP UA can call a registered UA by calling its AOR,
"sip:1ggn@interop.pingtel.com".
There is an experimental interface you can use to trace the message flow in this system.
Require Header
The addresses 1gg1 and 1gg2 each have a voicemail box; they may SUBSCRIBE
for the message-summary event package. You can call the
voicemail box directly by calling user
2gg1 or 2gg2.
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.
A call to 3ggx (for any x 1-9)
will be challenged for authentication, and when successfully
authenticated will ring 1ggx.
A call to 4ggx (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 ring 1ggx). 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.
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:
sip:100@interop.pingtel.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).
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 transfering it
to 3ggx. 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).
A call to 5gg0
will be 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. 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 sipX proxy may time out the call attempt before
all four UAs ring.
A call to 6gg0
will be simultaneously forked to 1gg3,
1gg4, 1gg5, and 1gg6. When one 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.
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).
A call to 8ggx (for any x 1-9)
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. The UAC should accept the first one
and return a 482 Loop Detected response to the second. Make sure that
the loop detected error is sent and that the call is correctly set up
when the called UA answers.
Any call to 9000 will return a 483 Too Many Hops. As a
diagnostic aid, this software returns part of the failed request in
the body of the 483 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.
Any call to *78xxxx will pick up the call ringing on the
UA at xxxx. To use this feature:
1ggn.*781ggn.*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.
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 1gg3,
1gg4, 1gg5, and 1gg6.
The call should ring on 1gg3,
1gg4, 1gg5, and 1gg6.
From yet another UA, the executing UA,
call *781gg3.
It should pick up the first 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.
The extensions 5ggx (for any x
1-9) are parking orbits.
(The extensions 5gg0 are used
in the Serial Forking test described above.)
If a call is transferred to a parking 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.
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.
Once a registered UA has generated a dialog event package, this server
can retrieve a copy from its logs and display an analysis of the
dialog event package against some of the criteria in the
Internet-Draft
draft-worley-sip-dialog-03,
"Guidelines for Implementing the Dialog Event Package in User Agents".
To use this feature, execute a call pick-up where the second UA in the procedure (the called UA) is the UA whose dialog event package you would like to examine. Then enter its extension number in the box below and click on the link. Violations of the guidelines are marked in red in the analysis.
You can subscribe to the call park extensions to get their dialog events.
This server supports
ISN dialing.
It is reachable via ITAD 413 (for the time being), so for example, the
auto-attendant can be reached at 100*413.
To contact an ISN destination from this server, the user-part of the URI
should be *1 followed by the ISN dial string.
For example:
413*1 100*413*1 613*262*1 2425*259
User agents that provide "music on hold" via the technique of
draft-ietf-sipping-service-examples-10
can use the URI sip:~~mh~@interop.pingtel.com as an
audio source.
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:
Second test:
This server supports ENUM dialing using the "official" public enum
tree e164.arpa.
To contact an ENUM destination from this server, the user-part of the URI
should be *2 followed by the ENUM dial string.
For example:
*2 1 800 555 1234
*2 43 720 0101011
Additional ENUM test numbers can be found at
http://www.enum-test.at/index_en.html.
Ad-hoc conferencing is useful in call-control applications. It is implemented using an INVITE with the Join header.
Any call to *79xxxx will be turned into an
INVITE-with-Join to the call that is active on the
UA at xxxx, which sets up an ad-hoc conference of the new
caller with the existing participants of the call on xxxx.
To use this feature:
1ggn.*791ggn.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 Join, and whether the second UA generates dialog event notices with usable endpoint identification.
This server also supports the SIP domains
int-udp.pingtel.com and int-tcp.pingtel.com.
These domain names do not have DNS A records, rather they are
configured with DNS SRV records for the UDP and TCP protocols,
respectively. A UA should support DNS SRV records and both the UDP
and TCP protocols, so it should be able to use either of these domain
names in place of interop.pingtel.com to place calls
in all of the tests.
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~F~gg@interop.pingtel.com" which includes the statuses of "sip:1gg2@interop.pingtel.com", "sip:1gg6@interop.pingtel.com", and "sip:1gg9@interop.pingtel.com". The dialog events generated for thse 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, it should subscribe to the URI "sip:~~rl~C~gg@interop.pingtel.com".
As a consequence of maintaining the resource lists, the server maintains a dialog event subscription to all UAs registered to the URIs "sip:1gg2@interop.pingtel.com", "sip:1gg6@interop.pingtel.com", and "sip:1gg9@interop.pingtel.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 sipX feature that requires dialog events, including call pick-up.
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 1gg2, 1gg6, or 1gg9. Configure a second UA to display BLF information from "sip:~~rl~gg@interop.pingtel.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.
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.
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.
This test shows whether a UA sends comprehensive status information, and whether a second UA's BLF correctly displays status information.
Register a first UA as 1gg2 and a second UA as 1gg6. Configure a third UA to display BLF information from "sip:~~rl~gg@interop.pingtel.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.
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.
Require Header
RFC 3261 requires
that if a UA receives a request containing a Require header that names
a SIP extension that it does not implement, it must reject the request
with a 420 Extension Not Implemented response.
Any call to *63xxxx is sent to the UA at
xxxx after having the header Require: merde
added to the INVITE.
Since there is not and never will be a SIP extension named
merde, the destination UA must reject this INVITE with a
420 response.
Display the sipX version running on this server
Display the configuration version running on this server
This server uses a special test configuration of the sipXecs Open Source PBX Project. (It would not make a very friendly configuration in a real PBX :-).)