Howto:LU - MIXvoip - SIP Trunk SIP-Provider (2021): Difference between revisions
Jump to navigation
Jump to search
Line 35: | Line 35: | ||
; Codecs : The provider support the following codecs: G711A, G711U | ; Codecs : The provider support the following codecs: G711A, G711U | ||
; Fax : ''testing not yet concluded'' | ; Fax : ''testing not yet concluded'' |
Revision as of 16:43, 24 May 2016
Summary
The tests for the Mixvoip SIP Trunk of the provider Mixvoip were completed successfully.
Issues found were:
For more details about this issues, see the respective test-results sections.
Current test state
This product is being tested right now. The test is not yet completed.
Tests with MediaRelay
- Registration
- The provider supports UDP and TCP as transport protocol. The tests were completed using TCP, since UDP is an unreliable protocol and requires all involved network elements to support IP-fragmentation.
- CLIP
- OK
- CLIR
- CLIR didn't work
- Clip No Screening(CLNS)
- CLNS is not possible, however
- Redirection using "302 Moved Temporary" is possible. In case of a call forward, the incoming call is redirected to the PSTN. From point of view of the PBX the call doesn't exist after the redirection and is handled by the SIP-Provider. This is equivalent to "Partial Rerouting/Call Deflection" in ISDN. When a redirection is done, the redirection target will receive the original calling number, so for forwarded calls this will have the same effect as CLNS. However this redirection is not usable for Mobility calls or plain CLNS-calls. A plain CLNS-call is an outbound call with a "wrong" CGPN number (i.e. one that does not belong to the trunk). This happens e.g. if a call-center wants to send a service number (such 0800xxx) as CLI
- CLNS based on Diversion-Information is possible. Mobility calls and forwarded calls will show the original CGPN on the outbound call. However this redirection is not usable for plain CLNS-calls. A plain CLNS-call is an outbound call with a "wrong" CGPN number (i.e. one that does not belong to the trunk). This happens e.g. if a call center wants to send a service number (such 0800xxx) as CLI
- Codecs
- The provider support the following codecs: G711A, G711U
- Fax
- testing not yet concluded
- SRTP
- The provider does not support audio encryption using SRTP
- DTMF (RFC2833)
- Transmitting DTMF-tones as RTP-events was not possible. This may create interoperability issues with non-innovaphone devices
- NAT Traversal
- The provider detects clients behind NAT and can handle calls to them without requiring the clients to use NAT-traversal methods like STUN. However MediaRelay is required, since the provider does not support a change of the remote RTP-endpoint during a call
- Reverse Media Negotiation
- OK
- Mobility Call
- OK
- Redundancy
- Registration of two SIP-interfaces on the same SIP-account is supported by the provider. However, the provider has no failover mechanism if one device is down. As a result, you can use both SIP-interfaces for load-balancing purposes. If one device is down, for a duration of up to 2 minutes (i.e registration interval) incoming and outgoing calls might be rejected/fail.
- IP-Fragmentation
- OK
- Large SIP messages
- OK
- Correct signalling of Ringing-state
- OK
- Early-Media
- The provider supports early-media for outbound calls to the PSTN
- Session Timer
- The tests regarding the SIP-session timer were successful. This means that either no session expiry is used or that it is used and works. It does not imply that session expiry actually is used
- Call Transfer
- OK
Tests without MediaRelay
Listed here are only the test-results that differ from the tests with MediaRelay. If no test were done because MediaRelay is required, use text: The tests without MediaRelay were aborted, since it is required by the provider. [reason] e.g: The reason for it, are audio problems when changing the remote RTP-endpoint during a call and missing support for reverse-media negotiation.
Configuration
- Use profile (e.g. FR_OVH_SIP-Trunk) in the Gateway/Interfaces/SIP menu.
Additional Configuration
- if no point below applies, don't use the Header ===Additional Configuration===
- check WORKING_AUDIOFAX_PSTN_REQUIRES_EXCLUSIVE_CODEC
- if yes, check if G.711A is in WORKING_CODECS use text: FAX requires exclusive codec. Enable G711A Exclusive on all Fax-endpoints.
- if yes but only G.711U is in WORKING_CODECS use text: FAX requires exclusive codec. Enable G711U Exclusive on all Fax-endpoints.
- if WORKING_NAT_SCHEMES contains D but no C, then the provider can work without MR but requires STUN on all endpoints
- use text: If MediaRelay is not enabled on the SIP-Trunk, all RTP-endpoints must have a STUN-server configured.