Gateway anbinden, das sich bei GS5 per inbound_username/inbound_password einloggt, Rufnummernübertag

[AndreasB]

Hallo GS5 Freunde,

ich versuche folgende Ziel-Situation zu erreichen:

Alte Telefonanlage soll per AVM VoIP Gateway 5188 (DDI-Account) an GS5 angebunden werden. GS5 telefoniert dann per VoIP Provider ins öffentliche Telfonnetz (letzteres funktioniert auch).

Folgende Konfiguration A funktioniert nicht:

Gateway Einstellungen:
username     asdf        
password     qwer
GS5 versucht sich erfolglos anzumelden am AVM VoIP Gateway ( SIP/2.0 403 Forbidden ) und der Gateway versucht sich erfolglos anzumelden an GS5 ( SIP/2.0 404 Not Found )

Folgende Konfiguration B funktioniert teilweise:

Gateway Einstellungen:
inbound_username     asdf        
inbound_password     qwer
GS5 versucht nicht sich anzumelden am AVM VoIP Gateway, aber der AVM Gateway registriert sich erfolgreich an GS5

Komplette Konfiguration von Variante B:

<gateway description="" identifier="gateway1" inbound="true" name="AVM VoIP Gateway" outbound="true" technology="sip">
    <gateway_settings count="5">
        <setting class_type="String" description="AVM VoIP Gateway" name="domain" value="192.168.0.1"/>
        <setting class_type="String" description="" name="number_source" value="sip_to_user"/>
        <setting class_type="String" description="" name="inbound_username" value="asdf"/>
        <setting class_type="String" description="qwer" name="inbound_password" value="qwer"/>
        <setting class_type="Boolean" description="" name="register" value="true"/>
    </gateway_settings>
    <gateway_parameters count="1">
        <parameter class_type="String" description="" name="caller-id-in-from" value="true"/>
    </gateway_parameters>
    <call_routes count="2">
        <call_route name="AVM_VoIP_Gateway " position="1" routing_table="inbound">
            <route_elements count="0">
            </route_elements>
        </call_route>
        <call_route name="AVM_VoIP_Gateway " position="1" routing_table="outbound">
            <route_elements count="2">
                <route_element action="match" mandatory="true" pattern="^(987654%d%d?)$" position="1" replacement="%1" var_in="destination_number" var_out="destination_number"/>
                <route_element action="set" mandatory="false" pattern="^%+(49.+)$" position="2" replacement="%1" var_in="val:caller_id_numbers" var_out="caller_id_name"/>
            </route_elements>
        </call_route>
    </call_routes>
</gateway>

============================================================================

Bei Variante B funktioniert das Telefonieren z.B. per SoftPhone an GS5 über den AVM Gateway zur alten Telefonanlage auch.
Dann komme ich aber bei der Hauptrufnummer raus. Immer. Egal bei welcher eigentlich beabsichtigten/angerufenen internen Zielrufnummer.
Grund ist, dass GS5 bei der Konfiguration mittels inbound_username keine Zielrufnummer an den AVM Gateway sendet im To: header, sondern nur den usernamen asdf:

        INVITE sip:as...@192.168.0.1;uniq=D5D44420A5746AE7C4D1C3B877DA7 SIP/2.0
        Via: SIP/2.0/UDP 192.168.0.2;rport;branch=z9hG4bKr98X4c2y7vBgB
        Max-Forwards: 69
        From: "49345698765432" <sip:3...@192.168.0.2>;tag=p59117gQZK3BH
        To: <sip:asdf@192.168.0.1;uniq=D5D44420A5746AE7C4D1C3B877DA7>

Damit kann der AVM Gateway natürlich nichts anfangen, aber er stellt das Gespräch trotzdem zur alten Telefonanlage durch - an die Hauptrufnummer.
Ein D-Kanal Trace auf der ISDN Leitung ergibt dann auch nur die Hauptnummer:  "DD350     Called party number: 9876540 " also die alte Telefonanlage bekommt niemals die richtige Zielrufnummer mit.
Der AVM Gateway setzt diese Zielrufnummer auf dem D-Kanal offensichtlich selbstständig.

Welche Lösungen gibt es? Wenn ich für Konfiguration B weiter nach einer Lösung suche, finde ich im "FreeSWITCH Cookbook" ein passendes Kapitel (siehe Zitat), sehe mich aber allein nicht in der Lage das selbsständig in GS5 zu adaptieren:

Manipulating To: headers on registered endpoints to reflect DID numbers

Sometimes, when routing calls to endpoints that are registered to your system, you want to utilize custom To: headers. For example, if you are routing DIDs to a PBX or switch, the device you are calling might expect the phone number you wish to reach in the To: header. However, the customer or PBX may only have a single registration to your service that represents multiple DIDs that need to be routed.

By default, no flags exist to change the To: header to match the DID when calling a registered endpoint. Since the registration to your server is typically done via a generic username that is not related to the DID, you must program your dialplan to retrieve a user's registration information and parse out the username portion of the To: header, replacing it with your own. Care must be taken to replace only the username portion and to keep the remaining parameters intact, especially if NAT traversal is expected to continue operating.

Getting ready
Be sure that you have your DIDs and users configured. In this example, we will use testuser as the username with a phone number of 4158867999 and our domain is my.phoneco.test.

How to do it...
Create a dialplan extension, specifically for handling calls to the DID number and use some regular expression syntax to parse out the information. Here is an example:

<extension name="call_4158867999">
    <condition field="destination_number" expression="^\+?1?4158867999$"/>
    <condition field="${sofia_contact(test...@my.phoneco.test)}" expression="^[^\@]+(.*)">
      <action application="bridge" data="sofia/external/4158867999$1"/>
    </condition>
</extension>

How it works...
You would typically make bridge calls to testuser using the bridge command with an argument of user/testuser. In this scenario, however, you wish to call testuser's registered endpoint but replace testuser with a phone number - 4158867999, in our example. To do this, you must retrieve testuser's current dialstring and remove the username, replacing it with the DID number.

In the example, we leverage the sofia_contact API and some regular expression magic. The first condition simply matches the user's DID phone number we only want to act if the destination number is 4158867999. The interesting stuff happens in the second condition. The field is ${sofia_contact(test...@my.phoneco.test)}. By wrapping an API call in ${}, the dialplan literally executes the API and uses the result as the field value. If we go to fs_cli and type sofia_contact test...@my.phoneco.test, we get the result, which is something like this:

sofia/external/joh...@12.34.56.7;fs_nat=yes

The regular expression pattern ^[^\@]+(.*) is applied against this value. The result is that everything after the @ is placed in the $1 variable. In our example, $1 contains @12.13.56.7;fs_nat=yes. Finally, we execute the bridge with the dialstring sofia/external/4158867999$1. With $1 expanded out, our destination is as follows:

sofia/external/41588...@12.34.56.7;fs_nat=yes

We have successfully replaced testuser with 4158867999 while preserving the necessary IP address and parameters for contacting the server and sent the call to the proper destination.

Welche Lösungen gibt es? Hat jemand eine Idee?