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

FIXME: This is a temporary version of innovaphone SIP Interop Tests. Merge back to official wiki when finished

FIXME: Article name must have format Country_-_Provider_-_Productname_-_SIP Provider (YYYY)

Current test state

This product is being tested right now. The test is not yet completed.

Tests with MediaRelay

Registration

[text]

• 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

[text]

• 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

[text]

• 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)

[text]

However, [text-redirection]

• check WORKING_CLNS:
  • if yes, use text: OK
  • if no, use text: CLNS is not possible.
  • if WORKING_REDIRECT!=none
    • WORKING_REDIRECT=302, use text-redirection: 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 TrunkLine PBX-object. Additionally you must enable Interworking on the inbound route from the Provider to the PBX(i.e. SIPx -> RSx).
    • WORKING_REDIRECT=History or Diversion, use text-redirection: 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 WORKING_REDIRECT==none and WORKING_CLNS==no, use text-redirection: 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)
  • if WORKING_REDIRECT==none and WORKING_CLNS==yes, add text-redirection: Redirection based on "302 Moved Temporary" is not possible. Since CLNS is possible, it has no effect on forwarded or Mobility calls.

Codecs

[text]

• 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.

Fax

[text]

• 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

[text]

• 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)

[text]

• 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

[text]

• 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

[text]

• 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

[text]

• 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

[text]

• 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

[text]

• 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

[text]

• 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

[text]

• 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.
    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

[text]

• 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

[text]

• 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. Sebastian Gabris 11:15, 14. Jan. 2016 (CET) wäre ein KO kriterium. Unklar jedoch ob man das überhaupt erwähnen soll-

Call Transfer

[text]

• check WORKING_CALL_TRANSFER:
  • if it contains consconn consalert blind extern, use text: OK
    • otherwise:
      • if consconn is missing, use text: Transfer with consultation was not tested successfully.
      • if consalert 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 blind, use text: A blind transfer (i.e. without a consultation call) was not tested successfully.
    • • if extern 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.

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

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.