Incoming Calls via several SIP providers don't work

Symptoms

Incoming calls via certain SIP providers are rejected with ERROR 404 (URL not found).

Outgoing calls are possible.

Cause

 SIP provider uses asterisk (e.g. Voiceflex). Therewith the number mapping dosen't work correctly:

The LinkManager needs to assign incoming calls to a Trunk. To do this, it tries to map an incoming INVITE using the REGISTER from the registration of the Trunk. 
In addition, it tries to use the numbers and/or SIP URIs for mapping by combining the numbers and the realm configured for the trunk (<number>@<provider realm>).

If there is an INVITE with such a URI (<number>@<provider realm>) in its To-Header it is assigned to the trunk,  the <number> and the <provider realm>  are configured for..
Example:

INVITE sip:02314777242@80.79.77.23 SIP/2.0 
To: <sip:02314777242@myprovider.com>

An INVITE with a SIP-URI configured at the trunk is used for such mapping. 
Example:

INVITE sip:80.79.77.23 SIP/2.0 
To: <sip:my.name@mydomain.org>

For some providers (using asterisk) an incoming INVITE contains the same URI in the Request line and in the To-Header. Asterisk does not allow to fill these message elements different. 
Example:

INVITE sip:02314777242@80.79.77.23 SIP/2.0 
To: <sip:02314777242@80.79.77.23>

This may lead to problems, specifically for DDI accounts, because the mapping, using the mechanisms described above, does not work. In particular, it is not useful to enter all URIs in the form sip:<nummer>@80.79.77.23, because the IP addresses are changed repeatedly for ports with dynamic IP address assignement.

Resolution

After installing this Quickfix URIs (configured at the trunk) which contain wildcards. Example: 02314777*@* This allows mapping also for Asterisk based providers. However during configuration, the administrator needs to be aware of the fact that if the URIs are configured ambiguously at the Trunks, wrong mappings can occur. This leads to the conclusion that wildcards should not be used extensively. Example: 'sip:*@*' at several Trunks which are managed by the same LinkManager, will certainly lead to wrong mappings.