Howto:SIP Interop Test Description
innovaphone SIP Interop Tests
Summary
This article describes the SIP provider Tests done by innovaphone when testing the compatibility of a provider. The features are divided in two classes: KO-criteria and optional criteria. When the provider does not pass a test marked as KO-criteria, the provider can not be accepted in the category recommended SIP Provider.
To differentiate the quality of the offered service, the provider receives an additional rating. The current rating value ranges between 0 and 120 points. The test success rate is displayed as a percent value. It is calculated by using the following formula: (rating points achieved / rating points total) * 100.
For test results, see the list of tested SIP providers.
Test Scenario
This scenario describes a setup where the PBX and phones are in a private network. The IP800 must use a stun server, in order to send correct SIP - messages. The IP800 works as media relay, all RTP - streams go through the PBX.
Basic Call
call using g711a(KO)
Purpose: Test of capability to handle G711A RTP - Streams
Test description:
- Tel1 is configured with G711A exclusive coder preference.
- Tel1 calls a phone in the PSTN
call using g711u(KO)
Purpose: Test of capability to handle G711U RTP - Streams
Test description:
- Tel1 is configured with G711U exclusive coder preference.
- Tel1 calls a phone in the PSTN
call using g723(optional)
Purpose: Test of capability to handle G723 RTP - Streams
Test description:
- Tel1 is configured with G723 exclusive coder preference.
- Tel1 calls a phone in the PSTN
call using g729(optional)
Purpose: Test of capability to handle G729 RTP - Streams
Test description:
- Tel1 is configured with G729 exclusive coder preference.
- Tel1 calls a phone in the PSTN
Overlapped sending(optional)
Purpose: Test if the provider supports Overlap Dialling. If not Enblock Dialling must be configured on the SIP - trunk.
Test description:
- Route from PBX to SIP-provider is not configured with 'Force Enblock'.
- Tel1 calls a phone in the PSTN
early media channel(KO)
Purpose: Test if the transmission of RTP - packets is possible before the call has been accepted (200 OK) by both endpoints. This feature is used when the caller receives announcements or dialtones from the SIP - Provider. (i.e. 'The dialled number is incomplete.')
Test description:
- Tel1 calls a not existent(incomplete) phone number in the PSTN.
- PSTN-Provider will play an announce, i.e. 'Number incomplete'.
- The SIP-provider forwards the announcement and terminates the call setup procedure.
Fax using T.38(optional)
Purpose: Test of capability to handle T.38 signalling/data. Without this feature Fax over IP is not possible.
Test description:
- Fax1 sends a message to a fax machine in the PSTN.
- Fax1 receives a message from a fax machine in the PSTN.
Reverse Media Negotiation(optional)
Purpose: Test if Reverse Media Negotiation is implemented by the provider. If this test fails, media relay and an exclusive coder setting must be configured for this provider, resulting in a much lower amount of concurrent calls.
Test description:
- Tel1 calls Tel2. Tel2 picks up the call.
- Tel2 makes a blind transfer to a phone in the PSTN.
- This is the quickest way to send a INVITE message without SDP over the SIP-Trunk.
CGPN can be suppressed(optional)
Purpose: Test if provider accepts anonymous calls
Test description:
- Tel1 is configured to not send his CGPN. 'User Setup'->'Number Presentation' = Off
- Tel1 calls a phone in the PSTN. The display of the PSTN phone should show as Calling Party: 'anonymous'
CLIP no screening(optional)
Purpose: Test if provider accepts calls having a different CGPN as assigned to the SIP trunk
Test description:
- Tel1 is configured with CFU to a PSTN phone.
- A second PSTN phone calls Tel1, the call is forwarded to the first PSTN phone. The display of the first PSTN phone should show as Calling Party the second PSTN phone.
Long time call possible(KO)
Purpose: Test if provider interrupts call after session timer expires (RFC 4028). It is possible that the provide awaits Re-Invite after the timer expires. However the session timer is not implemented by innovaphone, so we will not send a Re-Invite.
Test description:
- Tel1 calls a phone in the PSTN
- call is longer than session expire time-out.(usually 1800 seconds)
External Transfer(KO)
Purpose: In scenarios were Media Relay is not used, the provider will have to connect both calls by short-circuiting his RTP ports.
Test description:
- A phone in the PSTN calls Tel1
- Tel1 picks up the call and transfers it to a second PSTN phone.
- Manual test of voice quality by speaking/listening on both ends.
NAT Detection
Purpose: In scenarios were Media Relay is not used and the PBX and phones are behind a NAT router, the SIP provider must support a NAT detection mechanism. The provider will receive SIP packets containing private IP addresses, this private IP addresses have to be replaced by the provider with the corresponding public addresses. If this test fails, media relay (with STUN server) and an exclusive coder setting must be configured for this provider, resulting in a much lower amount of concurrent calls.
Test description:
- Tel1 is in a private network behind a NAT router.
- Tel1 calls a phone in the PSTN
- check that audio is sent in both directions
Voice Quality OK?(KO)
Purpose: Simple test of overall voice quality during a call.
Test description:
- Tel1 calls Tel2. Tel2 picks up the call.
- Manual test of voice quality by speaking/listening on both ends.
Direct Dial In
Inbound(Provider -> Innovaphone)(KO)
Purpose: Test if the provider forwards the call to the PBX using the correct DDI - number(CDPN).
Test description:
- Tel1 calls phone in the PSTN.
- Check if the PSTN phone display shows the correct CGPN.
Outbound(Innovaphone -> Provider)(KO)
Purpose: Test if the provider handles the CGPN (trunk number + extension) correctly.
Test description:
- Phone in the PSTN calls Tel1.
- Check if the CDPN is forwarded correctly to the PBX.
DTMF
DTMF is also a must have feature for a company. DTMF is crucial for the use of a voice-mail system. Currently there are two methods of transferring DTMF signals, by SIP - INFO message or encapsulated in the RTP - packet. Innovaphone supports both types of DTMF signalling. However you must pay attention at the proper configuration of your innovaphone box, since your provider will typical support just one kind of DTMF tone signalisation.
DTMF tones sent correctly(KO)
Purpose: Test if DTMF signals going from PBX to Provider are received and interpreted correctly.
Test description:
- Tel1 calls phone in the PSTN.
- Check if the DTMF - tones are received at the PSTN phone(using SOAP). For manual test create a Waiting Queue with Map on some PBX connected via PSTN.
DTMF tones sent correctly via SIP-Info(optional)
Purpose: Test if DTMF signals going from PBX to Provider are received and interpreted correctly. When a call is forked via the Mobility object, DTMF - tones are sent only via SIP - Info messages. If this test fails, media relay and an exclusive coder setting must be configured for this provider, resulting in a much lower amount of concurrent calls.
Test description:
- Tel1 calls Tel2. Tel2 has a Fork destination(with Mobility) in the PSTN.
- Check if the DTMF - tones are received at the PSTN phone(using SOAP). For manual test create a Waiting Queue with Map on some PBX connected via PSTN.
DTMF tones received correctly(KO)
Purpose: Test if DTMF signals going from Provider to PBX are received and interpreted correctly.
Test description:
- PSTN Phone calls Tel1
- Check if the DTMF - tones are received at Tel1(using SOAP). For manual tst create a Waiting Queue on the tested PBX with Map.
Hold/Retrieve
When a call is put on hold, users normally expect to hear some kind of music/announcement signalling them that they should wait. However there are two possibilities. The PBX generates the announcement or the provide generates it.
To test a PBX generated announcement, use the R - key to hold a conversation. This type of holding is tested in the Hold/Retrieve , Transfer with consultation and Transfer with consultation (alerting only) scenario.
To test a provider generated announcement, use the redial key to hold the conversation. This is used when doing a blind transfer.
Call can be put on hold(KO)
Purpose: Test if provider handles hold signalisation by Re-Invite correctly.
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key'. Test if call is on hold(MoH/announcement).
- Tel1 presses again the 'R-Key'. Test if call is retrieved and conversation is continuable.
Held end hears music on hold / announcement from PBX(optional)
Purpose: Test if provider handles hold using the sendonly attribute correctly. The MoH will be transmitted by the PBX to the provider and must be then forwarded to the waiting phone.
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key'. Test if call signalisation is correct and MoH is audible on waiting phone.
Transfer with consultation
Call can be transferred(KO)
Purpose: Test of call-transfer with consultation
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key' and dials the number of Tel2, answer the call on Tel2.
- Test if audio channels between Tel1 and Tel2 are established correctly.
- Tel1 hangs up. PSTN phone changes its status from 'hold' to 'active'.
- Test if audio channels between PSTN phone and Tel2 are established correctly.
Held end hears music on hold(optional)
Purpose: Test for MoH/Announcement on hold phone.
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key' and dials the number of Tel2.
- Test if PSTN phone hears MoH.
Transfer with consultation (alerting only)
Call can be transferred(KO)
Purpose: Test of call-transfer with consultation
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key' and dials the number of Tel2.
- Tel1 doesn't wait for Tel2 to pickup the call and hangs up. PSTN phone changes its status from 'hold' to 'active'.
- Test if audio channels between PSTN phone and Tel2 are established correctly.
Held end hears music on hold(optional)
Purpose: Test for MoH/Announcement on hold phone.
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key' and dials the number of Tel2.
- Test if PSTN phone hears MoH.
Call returns to transferring device if the third endpoint is not available(KO)
Purpose: Test if returning calls are handled correctly by the provider.
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'R-Key' and dials the number of Tel2.
- Tel1 doesn't wait for Tel2 to pickup the call and hangs up. PSTN phone changes its status from 'hold' to 'active'.
- Tel2 doesn't answer the call. Depending on the configured Recall 'Timeout' the call falls back to Tel1.
- Tel1 answers calls and checks if audio is working in both directions
Blind Transfer
Call can be transferred(optional)
Purpose: Test of blind transfer
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'Redial-Key' and dials the number of Tel2.
- Call is passed to Tel2 and Tel2 picks up the call.
- Test if audio channels between PSTN phone and Tel2 are established correctly.
Held end hears music on hold(optional)
Purpose: Test for MoH/Announcement on hold phone.
Test description:
- Tel1 calls phone in the PSTN.
- Tel1 presses the 'Redial-Key' and dials the number of Tel2.
- Test if PSTN phone hears dial-tone(or MoH).
Broadcast Group & Waiting Queue
Caller can make a call to a Broadcast Group(KO)
Purpose: Test of basic functionality of the Broadcast feature, using Re-Invite.
Test description:
- PSTN Phone calls a 'Broadcast Group' number.
- Tel1 and Tel2 are ringing. Tel1 picks up the call.
- Test if audio channels between PSTN phone and Tel1 are established correctly.
Caller can make a call to a Waiting Queue(KO)
Purpose: Test of basic functionality of the Waiting Queue feature, using Re-Invite.
Test description:
- PSTN Phone calls a 'Waiting Queue' number.
- Tel1 and Tel2 are ringing. Tel1 picks up the call.
- Test if audio channels between PSTN phone and Tel1 are established correctly.
Announcement if nobody picks up the call(KO)
Purpose: Test if announcement feature at Waiting Queue is working correctly.
Test description:
- PSTN Phone calls a 'Waiting Queue' number.
- Tel1 and Tel2 are ringing.
- PSTN phone hears an announcement from the PBX, i.e. 'All operators are busy. Please hold the line.'
- Tel1 picks up the call.
- Test if audio channels between PSTN phone and Tel1 are established correctly.