Howto:LU - MIXvoip - SIP Trunk SIP-Provider (2021): Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
(New page: == Summary == The tests for the [https://www.mixvoip.com/sip_trunking/ Mixvoip SIP Trunk] of the provider [https://www.mixvoip.com/ Mixvoip] were completed successfully. Issues found were...)
 
Line 23: Line 23:


== Tests with MediaRelay ==
== Tests with MediaRelay ==
; Registration : [<code>text</code>]
; 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.  
* check WORKING_PROTOCOLS for ''udp'', ''tcp'' and ''tls''.
** if all 3 protocols are usable, use text: The provider supports UDP, TCP and TLS as transport protocol. The tests were completed using TLS, since it offers encryption of the transmitted SIP-packets.
** if only udp & tcp are supported, use text: 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.
** if only udp is supported, use text: 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 : [<code>text</code>]
; CLIP : OK
* check WORKING_CLIP:
** if yes, use text: OK
*** if there is a comment, add comment: E.g. However incoming international calls from Germany display not the user-provider but only the networking-provided number.
** if no, use text: CLIP didn't work, the test had to be aborted as this point. There must be a comment on this point, specifying what exactly didn't work. Add the comment.


; CLIR : [<code>text</code>]
; CLIR :  CLIR didn't work
* check WORKING_CLIR:
** if yes, use text: OK
*** if there is a comment, add comment: E.g. However incoming international calls from Germany display not anonymous but 0.
** if no, use text:  CLIR didn't work. There must be a comment on this point, specifying what exactly didn't work. Add the comment.


; Clip No Screening(CLNS) : [<code>text</code>]
; Clip No Screening(CLNS) : CLNS is not possible, however
: Additionally, [<code>text-redirection</code>]
:* 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
* check WORKING_CLNS:
:* 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
** if yes, use text: OK
 
*** if there is a comment, add comment
 
** if WORKING_REDIRECT!=none
; Codecs : The provider support the following codecs: G711A, G711U
*** WORKING_REDIRECT=302, use text: 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.
:::To use call redirection with ''302 Moved temporary'', you have to enable ''Reroute supported'' at your [[Reference10:PBX/Objects/Trunk_Line | TrunkLine]] PBX-object. Additionally you must enable ''Interworking'' on the inbound [[Reference9:Gateway/Routes/Map | route]] from the Provider to the PBX(i.e. SIPx -> RSx).
*** WORKING_REDIRECT=History or Diversion, use text: CLNS based on Diversion-Information is possible. Moblility 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.
** if no and WORKING_REDIRECT====none, use text: CLNS is not possible. 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 <code>Set Calling=Diverting No</code>)
** if yes and WORKING_REDIRECT====none, add text: Redirection based on the Diversion number or based on "302 Moved Temporary" is not possible. Since CLNS is possible, it has no effect on forwarded or Mobility calls.
; Codecs : [<code>text</code>]
* WORKING_CODECS
* WORKING_CODECS
** this should always contains codecs, use text: The provider support the following codecs: If there is a comment (e.g. some coders are supported only for internal calls), add it.
The following codecs are not supported:


; Fax : [<code>text</code>]
; Fax : ''testing not yet concluded''
* WORKING_AUDIOFAX_PSTN
** if yes, use text: Transport of faxes to/from the PSTN via G.711(A/U) codec was tested successfully.
*** if WORKING_T38_PSTN also yes, use text: 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.
**** WORKING_FALLBACKFAX_PSTN should be yes in this case, use text: Fallback from T.38 to G.711 was also tested successfully.
*** if WORKING_T38_PSTN no, use text: 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.
** if WORKING_AUDIOFAX_PSTN = no, use text: Transmitting faxes via G.711(A/U) codec was not tested successfully. If there is a comment, add it.


; 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) : Transmitting DTMF-tones as RTP-events was not possible. This may create interoperability issues with non-innovaphone devices
* WORKING_DTMF_RFC2833
** if yes, use text: OK
** if no, use text: Transmitting DTMF-tones as RTP-events was not possible. Since this is a requirement for our test-machine, further tests were aborted.


; 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. However MediaRelay is required, since the provider does not support a change of the remote RTP-endpoint during a call
*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 : OK
* 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 : OK
*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 16:42, 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
  • WORKING_CODECS
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.

Contact

Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:LU_-_MIXvoip_-_SIP_Trunk_SIP-Provider_(2021)&oldid=42285"