Howto:IT - Made in Lab - VoIP In Lab SIP-Provider (2016): Difference between revisions
Jump to navigation
Jump to search
No edit summary |
mNo edit summary |
||
| Line 17: | Line 17: | ||
For more details about this issues, see ''Tests'' sections. | For more details about this issues, see ''Tests'' sections. | ||
[[Category:RecProd|{{PAGENAME}}]] | [[Category:RecProd|{{PAGENAME}}]] | ||
[[Category:3rdParty SIP Provider|{{PAGENAME}}]] | [[Category:3rdParty SIP Provider|{{PAGENAME}}]] | ||
| Line 31: | Line 29: | ||
; Fax : Transport of faxes to/from the PSTN via G.711A codec was tested successfully.Additionally transport of faxes to/from the PSTN using the T.38 protocol was tested successfully. This is important for the innovaphone Fax-server. Even if the provider supports T.38, it is not guaranteed that all Fax-calls use T.38. However each call using T.38 will save you 2 DSP-licenses on the gateway hosting the Fax-interface. | ; Fax : Transport of faxes to/from the PSTN via G.711A codec was tested successfully.Additionally transport of faxes to/from the PSTN using the T.38 protocol was tested successfully. This is important for the innovaphone Fax-server. Even if the provider supports T.38, it is not guaranteed that all Fax-calls use T.38. However each call using T.38 will save you 2 DSP-licenses on the gateway hosting the Fax-interface. | ||
; SRTP : The provider does not support audio encryption using SRTP. | ; SRTP : The provider does not support audio encryption using SRTP. | ||
; DTMF(RFC2833) : OK | ; DTMF (RFC2833) : OK | ||
; 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 since reverse-media negotiation is not supported, MediaRelay and Exclusive coder must be activated on the SIP-interface. | ; 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 since reverse-media negotiation is not supported, MediaRelay and Exclusive coder must be activated on the SIP-interface. | ||
; Mobility Call : Transmitting DTMF-tones as SIP-INFO messages was not possible, which is required in-order to use Mobility-calls without MediaRelay on the SIP-Interface. | ; Mobility Call : Transmitting DTMF-tones as SIP-INFO messages was not possible, which is required in-order to use Mobility-calls without MediaRelay on the SIP-Interface. | ||
Revision as of 12:32, 11 February 2016
Summary
The tests for this product have been completed. See the Summary section for more details.
The tests for the SIP-trunk VoIP-In-Lab of the provider MADE IN LAB Communications were completed.
Issues found were:
- SRTP
- NAT Traversal
- Mobility Call
- Redundancy
- Correct signalling of Ringing-state
For more details about this issues, see Tests sections.
Tests with MediaRelay
- Registration
- The provider supports only UDP as transport protocol. As a result, the SIP-communication is not encrypted. Moreover it requires all involved network elements to support IP-fragmentation.
- CLIP
- OK
- CLIR
- OK
- CLNS
- OK
- codecs
- G711a, G711u, G729A, G722 (on-net calls only). The following codecs are not supported: OPUS.
- Fax
- Transport of faxes to/from the PSTN via G.711A codec was tested successfully.Additionally transport of faxes to/from the PSTN using the T.38 protocol was tested successfully. This is important for the innovaphone Fax-server. Even if the provider supports T.38, it is not guaranteed that all Fax-calls use T.38. However each call using T.38 will save you 2 DSP-licenses on the gateway hosting the Fax-interface.
- SRTP
- The provider does not support audio encryption using SRTP.
- DTMF (RFC2833)
- OK
- 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 since reverse-media negotiation is not supported, MediaRelay and Exclusive coder must be activated on the SIP-interface.
- Mobility Call
- Transmitting DTMF-tones as SIP-INFO messages was not possible, which is required in-order to use Mobility-calls without MediaRelay on the SIP-Interface.
- 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
- Ringing not signalled by the provider. This will lead to incorrect call-state display on the PBX(phone-UI, myPBX, Soap) for outbound calls to the PSTN. The caller will see no status-update on the phone-display/PC-screen, showing that the remote party was reached and is ringing.
Additionally external callers forwarded/transferred back to the PSTN, will get no ring-tone but hear silence while the remote party is ringing. This silence while waiting might lead to aborting the call.
- Early-Media
- OK
- Session Timer
- OK
- Call Transfer
- OK
Tests without MediaRelay
The tests were aborted, since the provider requires MediaRelay. 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 IT_Made-In-Lab_VoIP-In-Lab in the Gateway/Interfaces/SIP menu.
Contact
Customers should contact Made in Lab using the following contact web page.