Howto:FR - OpenIP - SIP Trunk Touch SIP-Provider (2016): Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
Line 44: Line 44:
; Fax : Transport of faxes to/from the PSTN via G.711(A/U) codec was tested successfully. However transport of faxes to/from the PSTN using the T.38 protocol was not tested successfully. This is important for the innovaphone Fax-server. Since the provider doesn't support T.38, you must use the "Audiofax" feature(i.e 2 DSPs) for each fax-call done by the innovaphone Fax-interface.
; Fax : Transport of faxes to/from the PSTN via G.711(A/U) codec was tested successfully. However transport of faxes to/from the PSTN using the T.38 protocol was not tested successfully. This is important for the innovaphone Fax-server. Since the provider doesn't support T.38, you must use the "Audiofax" feature(i.e 2 DSPs) for each fax-call done by the innovaphone Fax-interface.


; SRTP : [<code>text</code>]
; SRTP : The provider does not support audio encryption using SRTP.
* WORKING_SRTP
** if WORKING_SRTP is none, use text: The provider does not support audio encryption using SRTP.
** otherwise, use text: The provider supports audio encryption using SRTP for ''value'' of WORKING_SRTP (e.g. ... for incoming, outgoing, intern) calls.


; DTMF (RFC2833) : [<code>text</code>]
; DTMF (RFC2833) : OK
* WORKING_DTMF_RFC2833
** if yes, use text: OK
** if no, use text: Transmitting DTMF-tones as RTP-events was not possible. This will cause problems with 3rd party devices, since most endpoints send & expect DTMF tones as defined in RFC2833.


; NAT Traversal : [<code>text</code>]
; 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.
*check WORKING_NAT_SCHEMES
** if WORKING_NAT_SCHEMES contains C & A, use text: The provider detects clients behind NAT and can handle calls to them without requiring the clients to use NAT-traversal methods like STUN.
*** WORKING_NAT_SCHEMES contains only A but no C, use text above. Add comment: However MediaRelay is required, since the provider does not support a change of the remote RTP-endpoint during a call.
** if WORKING_NAT_SCHEMES contains D & B, but (no C or A), use text: The provider cannot handle calls to clients behind NAT. Clients are requires to use NAT-traversal methods like STUN. Drawback of this solution is that STUN doesn't work for all NAT routers (i.e. routers doing symmetric NAT). Because of this limitation, it depends on the customer network equipment whether the SIP-tunk is usable or not.
*** WORKING_NAT_SCHEMES contains only B but no (C,A,D) use text above. Add comment: However MediaRelay is required, since the provider does not support a change of the remote RTP-endpoint during a call.  


; Reverse Media Negotiation : [<code>text</code>]
; Reverse Media Negotiation : OK
*check WORKING_REV_MEDIA_NEG
** if yes, use text: OK
** if no, use text: Reverse-media negotiation is not supported, MediaRelay and Exclusive coder must be activated on the SIP-interface.


; Mobility Call : [<code>text</code>]
; 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.  
* WORKING_DTMF_SIP_INFO
** if yes, use text: OK
** if no, use text: 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 : [<code>text</code>]
; 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.
* WORKING_REDUNDANCY
** if no, use text: Registration of two SIP-interfaces on the same SIP-account is not supported by the provider. As a result, you cannot have a ''Standby'' gateway/PBX using the same account for failover or load-balancing purposes.
** if WORKING_REDUNDANCY=yes, but WORKING_REDUNDANCY_FAILOVER = no, use text: 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.
** if WORKING_REDUNDANCY=yes and WORKING_REDUNDANCY_FAILOVER = yes, use text: Registration of two SIP-interfaces on the same SIP-account is supported by the provider. The provider has a 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 default SIP-registration interval) incoming and outgoing calls might be rejected/fail.
** check USE_TTL in providerdata.h. If not default(i.e 120 sec.), replace 2 minutes in above test with its value.


; IP-Fragmentation : [<code>text</code>]
; IP-Fragmentation : OK
*check WORKING_FRAGMENTATION:
** if yes, use text: OK
** if no, use text: IP-Fragmentation is not supported by the provider. When using UDP as Transport protocol, this might cause problem since the fragmentation of the packets cannot be influenced by the sender (PBX), but depends on the routers (IP-hops) to the SIP-provider. The result will be failed calls.


; Large SIP messages : [<code>text</code>]
; Large SIP messages : OK
*check WORKING_LARGE_MESSAGES:
** if yes, use text: OK
** if no, use text: Large SIP messages (> 1500 bytes) are not supported by the provider. This might lead to sporadic failure of outbound calls, e.g. if the call has redirection information and by additional data the singling message gets to large for the SIP-provider.


; Correct signalling of Ringing-state : [<code>text</code>]
; 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. <br>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.
*check WORKING_RINGING:
** if yes, use text: OK.
** if no, use text: 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. <br>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 : [<code>text</code>]
; Early-Media : The provider supports early-media for outbound calls to the PSTN.
* check WORKING_EARLY_MEDIA
** if yes, use text: The provider supports early-media for outbound calls to the PSTN.
** if no, use text: The provider does not support early-media for outbound calls to the PSTN. As a result, a caller will not hear announcement of an PSTN-provider (e.g. The number you dialled does not exist.) or custom ring-tones (e.g. if making an international call)


; Session Timer : [<code>text</code>]
; 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.
* WORKING_EXPIRES
* is yes, use text: 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.
* if no, use text. The tests regarding the SIP-session timer were not successful. This will result in unwanted call termination on calls exceeding a certain time (default 30 minutes). Because of this, further tests were aborted. [[Benutzer:Sga|Sebastian Gabris]] 11:15, 14. Jan. 2016 (CET) wäre ein KO kriterium. Unklar jedoch ob man das überhaupt erwähnen soll-


; Call Transfer : [<code>text</code>]
; Call Transfer : OK
* check WORKING_CALL_TRANSFER:
** if it contains <code>consconn consalert blind extern</code>, use text: OK
*** otherwise:
**** if <code>consconn</code> is missing, use text: Transfer with consultation was not tested successfully.
**** if <code>consalert</code> is missing, use text: A semi-attended transfer (i.e. without waiting for the consultation call to be answered) was not tested successfully.
** if it contains <code>blind</code>, use text: A blind transfer (i.e. without a consultation call) was not tested successfully.
**** if <code>extern</code> is missing, use text: An external transfer, with consultation call, was not tested successfully. As a result, it is not possible to transfer an external call (i.e. involving a PSTN participant) back to the PSTN.
[[Benutzer:Sga|Sebastian Gabris]] 12:01, 14. Jan. 2016 (CET)sollte es ein comment in providerdata.h geben, um zu sagen was genau nicht funktioniert hat?


== Tests without MediaRelay==
== Tests without MediaRelay==

Revision as of 11:22, 10 June 2016

Tools clipart.png FIXME: This is a temporary version of innovaphone SIP Interop Tests. Merge back to official wiki when finished
Tools clipart.png FIXME: Article name must have format Country_-_Provider_-_Productname_-_SIP Provider (YYYY)

Summary

The tests for the SIP Trunk of the provider OpenIP were completed.

Issues found were:

Clip No Screening
Fax T38
SRTP
Redundancy Failover
Provider only offers 1 codec (G711U or G711A)


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 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
Clip No Screening(CLNS)
CLNS is not possible
However, redirection based on the Diversion number or based on "302 Moved Temporary" is not possible. As a result, forwarded calls or Mobility calls will not see the original calling-number but the diverting parting number as caller(if the TrunkLine - object is configured with Set Calling=Diverting No)
Codecs
The provider support the following codecs: G711u, G711a (However only one can be used at time, it's necessary to ask to switch codec).
Fax
Transport of faxes to/from the PSTN via G.711(A/U) codec was tested successfully. However transport of faxes to/from the PSTN using the T.38 protocol was not tested successfully. This is important for the innovaphone Fax-server. Since the provider doesn't support T.38, you must use the "Audiofax" feature(i.e 2 DSPs) for each fax-call done by the innovaphone 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.
Reverse Media Negotiation
OK
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
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 Profile-Name 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.

Contact

Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:FR_-_OpenIP_-_SIP_Trunk_Touch_SIP-Provider_(2016)&oldid=42390"