Frage: Sipgate Plus eingehende Anrufe auf falschem Account

Hallo liebe Forumsmitglieder,

ich teste gerade die Community-Version 7.10.00 auf einem APU1D4 Board um endlich meine FRITZ!Box abzulösen.
Nun würde ich gerne eine erste Frage zu sipgate plus (wie sipgate basic nur 3 Rufnummern auf 3 Accounts) stellen.

Man erhält 3 Accounts (XXXe0, XXXe1 und XXXe2) auf welchem man je eine der 3 Rufnummern zuteilt.
Also habe ich 3 Ämter mit der sipgate basic Amtsvorlage eingerichtet.

Das geht soweit auch prima, jede Nebenstelle ruft entsprechend der Durchwahl auf dem passenden Amt raus.

Eingehende Anrufe sind seltsam, diese kommen nicht auf dem der Rufnummer zugeteilten Account/Amt rein sondern immer über den Account XXXe1.
Daher löse ich alle eingehenden Anrufe mit Regeln im Amt XXXe1 auf, da scheinbar nur über dieses Amt Anrufe reinkommen.

Nun zur Frage: Ist dieses Verhalten so bekannt und OK?

Ich hätte erwartet, dass für jede Rufnummer auch der passende Account und somit Amt genutzt wird.

Viele Grüße,
dksoft

Guten Morgen,

welche Vorlage hast du genau verwendet, die BASIC oder TEAM?
Das Routing ist bei einigen Providern unterschiedlich, dies hängt u.a. auch mit dem Lastaufkommen zusammen.
Hast du das Verhalten von sipgate schon überprüft, wenn du mehr als einen Anruf gleichzeitig auf eine Rufnummer bekommst?

Gruß
Markus

Hallo Markus,

ich habe einen Test Account von sipgate team mit 5 Rufnummern und kann aber mit der Vorlage von mobydick diesen Account bzw. die 5 Accounts nicht richtig installieren. Das Problem ist bei eingehenden Anrufe, die bekomme ich nicht rein. Ausgehende geht. Ich habe eine lizenzierte Version 7.10.02 von der mobydick. Ist das Problem schon bekannt bei euch?

Hier ist was CLI zeigt:

-- Executing [50016153962095@no-auth-in:1] Gosub("SIP/IP-00000655", "sub_emergency-check,s,1(50016153962095)") in new stack
-- Executing [s@sub_emergency-check:1] Verbose("SIP/IP-00000655", "1,sub_emergency-check:: exten: 50016153962095 - descent: ") in new stack

sub_emergency-check:: exten: 50016153962095 - descent:
– Executing [s@sub_emergency-check:2] GotoIf(“SIP/IP-00000655”, “1?50016153962095,1”) in new stack
– Goto (sub_emergency-check,50016153962095,1)
– Channel ‘SIP/IP-00000655’ sent to invalid extension: context,exten,priority=sub_emergency-check,50016153962095,1
– Executing * Return(“SIP/IP-00000655”, “”) in new stack
– Executing [50016153962095@no-auth-in:2] GotoIf(“SIP/89.163.210.184-00000655”, “0?mdc_emergency,dial,1:mdc_emergency,invalid,1”) in new stack
– Goto (mdc_emergency,invalid,1)
– Executing [invalid@mdc_emergency:1] NoOp(“SIP/IP-00000655”, “mdc_emergency:: is no emergency call”) in new stack
– Executing [invalid@mdc_emergency:2] Answer(“SIP/IP-00000655”, “”) in new stack
– Executing [invalid@mdc_emergency:3] Playback(“SIP/IP-00000655”, “beeperr”) in new stack
– <SIP/IP-00000655> Playing ‘beeperr.alaw’ (language ‘en’)
– Executing [invalid@mdc_emergency:4] Hangup(“SIP/IP-00000655”, “20”) in new stack

Vielen Dank für das Feedback.*

Guten Morgen artpr,

wenn Anrufe im Kontext “no-auth-in” landen, dann kann der asterisk den eingehenden Anruf keinen Account zu ordnen. Das kann verschiedene Gründe haben, meist ist jedoch die Ursache, dass der Provider einen Load-Balancer einsetzt. Siehe hierzu auch http://community.pascom.net/showthread.php?834-MobyDick-mit-Siproxd&highlight=load+balancer.

Hierzu müsste man u.a. die SIP Pakete anschauen, was dort als Absender (IP) eingetragen ist und inwieweit diese mit den angelegten Trunk Accounts übereinstimmt.

Wenn du eine schnelle Unterstützung brauchst, kannst du dich auch an unseren Support wenden.

Gruß
Markus

Hallo Markus,

Vielen Dank für deine Unterstützung.

Ich habe inzwischen das Problem gelöst. Ich habe verschiedene Varianten probiert und am Schluss bin auf die Idee gekommen bei eingehenden Anrufen als “Ziel Rufnummer” die SIP-ID einzutragen und eben nicht die Rufnummer oder ein Stern oder Variablen. Als Information für die Interessenten, Sipgate überträgt die SIP-ID als Rufnummer. Und für Accounts mit verschiedenen SIP-ID’s die dann Anrufe empfangen und an verschiedenen Queues oder Durchwahlstellen weiterleiten müssen, das ist ein Muss. Den nur so kann ein Account und ein SIP-ID als solches identifiziert und richtig behandelt werden. Also mit diesen Einstellungen auch ausgehende Anrufe funktionieren problemlos. Das andere Problem bei solchen Test Accounts bei Sipgate ist, dass man sehr lange Rufnummern bekommt die dann aus dem Ausland gar nicht erreichbar sind, und auch aus Deutschland ziemlich viel Kopfzerbrechen verursachen! So hat man das Gefühl, dass die Anrufe nicht eingehen und das die Accounts eventuell nicht richtig konfiguriert sind

Ich werde später noch die Optionen die ich beim Sipgate Account in der MobyDick eingetragen habe, hier posten.

Gruß,

artpr

Hallo zusammen,

hier sind die Option die man eintragen kann damit der Sipgate Team Account funktioniert:

Benutzername: ‘‘sip-id@sipgate.de’’

Passwort: xxxxx

Host: proxy.live.sipgate.de

Optionen:

host=proxy.live.sipgate.de
fromdomain=sipgate.de
fromuser=SIP-ID
outboundproxy=proxy.live.sipgate.de
insecure=port,invite
canreinvite=no
nat=force_rport,comedia instead
qualify=yes
disallow=all
allow=alaw
dtmfmode=rfc2833
transport=udp

Typ: Peer (funktioniert aber auch mit Friend und User)

Registrierung: Ja

Port: leer lassen

Durchwahl reg.: leer lassen

Ext. aus Header: Ja

CLIP Modus: Sip Header

CLIR Modus: Name + Nummer

Und bei Regel: ‘‘Eingehende Rufe’’ unbedingt bei Ziel die die SIP-ID eintragen (wenn mehere Konten eingerichtet sind, ist ein Muss)

In diesem Fall würde ich auch Passcom vorschlagen, bei der Konfiguration von Sipgate Team mit der Vorlage, meine Anleitung zu berücksichtigen.

Hallo artpr,

danke für deine ausführliche Info. Ich werd dann gleich noch ein Ticket anlegen, so dass die Änderung im nächsten Release mit dabei ist.
Leider kommt es häufig vor, dass die Provider auf ihrer Seite die Konfiguration ändern. Auch wenn es nur Details sind, dann klappt es halt nicht mehr.
An dieser Stelle mal ein Lob an alle Community User!

Gruß
Markus