asterisk und mehr als ein account beim gleichen provider

noway0815

Neuer User
Mitglied seit
12 Mai 2006
Beiträge
117
Punkte für Reaktionen
0
Punkte
16
Hallo,
ich habe ein sipgate plus account mit 3 extensions und ein account fuer meine frau. Sie werden alle erfolgreich registeriert, aber wann immer eine dieser nummern angerufen wird erscheint immer die ID der letzten peer in der sip.conf angemeldeten nummer: So z.B.
Code:
sip.conf
register => 123456e0:[email protected]/123456e0
register => 123456e1:[email protected]/123456e1
register => 123456e2:[email protected]/123456e2

[sipgate0]
type=friend
host=sipgate.de
username=123456e0
secret=XXXXXX
fromuser=123456e0
fromdomain=sipgate.de
insecure=port,invite
canreinvite=no
context=incomming
nat=no

[sipgate1]
type=friend
host=sipgate.de
username=123456e1
secret=XXXXXX
fromuser=123456e1
fromdomain=sipgate.de
insecure=port,invite
canreinvite=no
context=incomming
nat=no

[sipgate2]
type=friend
host=sipgate.de
username=123456e2
secret=XXXXXX
fromuser=123456e2
fromdomain=sipgate.de
insecure=port,invite
canreinvite=no
context=incomming
nat=no

extensions.conf
[incomming]
exten => sipgate0,1,Goto(sipgate_in0,s,1) 
exten => sipgate1,1,Goto(HebaSalama_in,s,1)
exten => sipgate2,1,Goto(CallThrough,s,1)

[sipgate0_in]
exten => sipgate0,1,Dial(SIP/1000,60)
exten => sipgate0,n,Hangup()

[sipgate1_in]
exten => sipgate1,1,Dial(SIP/1001,60)
exten => sipgate1,n,Hangup()

[sipgate2_in]
exten => sipgate2,1,Dial(SIP/1002,60)
exten => sipgate2,n,Hangup()

Egal welche Nummer angerufen wird, erscheint immer die user ID der letzten ob es SIPgate0, SIPgate1 oder SIPgate2. Je nachdem welchen Reihenordnung die peers haben.

Es hat auch nicht geholfen fuer jede nummer eine eigene exten. zu machen.

Was ist hier falsch

Gruss
noway0815
 
Probier mal so:

Code:
register => 123456e0:[email protected]/123456e0
register => 123456e1:[email protected]/123456e1
register => 123456e2:[email protected]/123456e2

[123456e0]
type=friend
host=sipgate.de
username=123456e0
secret=XXXXXX
fromuser=123456e0
fromdomain=sipgate.de
insecure=port,invite
canreinvite=no
context=incomming
nat=no

[123456e1]
type=friend
host=sipgate.de
username=123456e1
secret=XXXXXX
fromuser=123456e1
fromdomain=sipgate.de
insecure=port,invite
canreinvite=no
context=incomming
nat=no

[123456e2]
type=friend
host=sipgate.de
username=123456e2
secret=XXXXXX
fromuser=123456e2
fromdomain=sipgate.de
insecure=port,invite
canreinvite=no
context=incomming
nat=no

Code:
[incomming]
exten => 123456e0,1,Goto(sipgate_in0,s,1)
exten => 123456e1,1,Goto(HebaSalama_in,s,1)
exten => 123456e2,1,Goto(CallThrough,s,1)

Funktioniert bei mir einwandfrei.

Btw. bitte nutze [noparse]
Code:
...
[/noparse].
 
Es hat bei mir auch mal funktioniert! kann es an asterisk-version liegen?!
welche asterisk version hast du?
ich benutze version: Asterisk 1.4.40-rc2

Gruss
noway
 
Hat mit 1.2 und 1.4 funktioniert, und funktioniert aktuell mit 1.6. Allerdings 2 sipgate Basic.

Schau mal, ob Du mit CALLERID(dnid) oder dem SIP Header "To" was raus bekommst.
 
Hallo Again,
Nun bin ich wiedermal "Zuhause" und habe immer noch das alte problem, obwohl ich auf asterisk 1.6 umgestiegen bin. Die Configuration hat sich aber nicht geaendert.
Das SIP_HEADER(to) ist ok und auch die CALLERID(dnid). Es wird immer das peer falsche angezeigt.

wie man sieht:
Executing [Call-Back0@incoming:1] MSet("SIP/International-000000b6", "~~EXTEN~~=Call-Back0") in new stack
-- Executing [Call-Back0@incoming:2] NoOp("SIP/International-000000b6", CALLERID(dnid): Call-Back0 *** TO: <sip:[email protected]> ") in new stack

Call-Back0 ist 004930XXXXXXXX2. Damit ist das OK.
Das MSet zeigt aber das peer International und das ist 004930XXXXXXXX0
Was kann da schief laufen. Ich bin Ratlos !!!!!!!!

Und Noch etwas: das Problem liegt nicht nur bei sipgate. Andere Anbieter habe es auch. Es liegt eindeutig an asterisk.

Grus
Noway0815
 
Zuletzt bearbeitet:
Wenn es Dir "nur" um das von Asterisk selektierte peer geht:
Ja, das ist ein - versionsübergreifendes - Manko von Asterisk: Existieren mehrere peers mit der gleichen IP-Adresse (hier also SIPGATE mit 217.10.79.9), dann wird bei einem eingehenden Anruf nicht zwingend der eigentlich angerufene peer, sondern - je nach Asterisk-Version - der in der sip.conf zuerst oder zuletzt definierte peer genommen.

Das bedeutet im Umkehrschluss: Da Asterisk das nicht sauber kann, kannst Du Dich bei eingehenden Anrufen nicht auf den CHANNEL(peername) stützen, um irgendwelche Logik aufzusetzen. Vielmehr musst Du die Daten aus dem SIP-Paket entnehmen, wobei das bei SIPGATE sauber funktioniert, da SIP_HEADER(FROM) und SIP_HEADER(TO) stimmen und sauber in die CALLERID-Parameter überführt werden, mit denen Du ja dann weiterarbeiten kannst, was Du auch selbst schon bestätigt hast.

Wie gesagt, vergiß den peername, der ist tatsächlich bei mehreren eingehenden Accounts zur gleichen IP-Adresse nicht auswertbar. Leider ist da auch seitens Asterisk/Digium IMHO keine Besserung in Sicht.
 
Wie gesagt, vergiß den peername, der ist tatsächlich bei mehreren eingehenden Accounts zur gleichen IP-Adresse nicht auswertbar.

richtig.

Aber ich verstehe nicht was es ueberhaupt fuer einen Sinn machen soll, sich bei mehreren eingehenden Accounts mit demselben Asterisk mehrfach zur gleichen IP-Adresse zu registrieren? Wenn eine Unterscheidbarkeit der Accounts auch anderweitig gegeben ist.

Jede Registration (insbes. wenn sie ueber das Internet laeuft) ist im Endeffekt doch eine 'teure' Operation. Die Ressourcen kostet und fehlschlagen kann. Deswegen sollte man sie wenn immer moeglich sowieso vermeiden.

- sparkie
 
Zuletzt bearbeitet:
Aber ich verstehe nicht was es ueberhaupt fuer einen Sinn machen soll, sich bei mehreren eingehenden Accounts mit demselben Asterisk mehrfach zur gleichen IP-Adresse zu registrieren?

So sehr ich Dir zustimme, ist dies aber leider abhängig von den Tarif-/Zugangsmodellen der Provider. Und SIPGATE gibt da im Plus-Tarif ein eher schlechtes Beispiel aus Sicht einer PBX ab, da die einzelnen Rufnummern tatsächlich auf 3 (mit Fax ggf. 4) "Subaccounts" geroutet werden, die leider auch alle registriert werden müssen, damit di Anrufe zugestellt werden. Vermutlich war man dort mal der Meinung, dass sich nur Endgeräte registrieren würden und die dann jeweils auch nur für eine dedizierte Rufnummer ...
 
da die einzelnen Rufnummern tatsächlich auf 3 (mit Fax ggf. 4) "Subaccounts" geroutet werden, die leider auch alle registriert werden müssen, damit di Anrufe zugestellt werden.

sorry, aber das stimmt nicht. Ich habe genau so einen Sipgate-Plus Account. Und mappe alle meine Telefonnummern auf genau eine SIP-ID (geht ueber die Telefonie-Einstellungen). Ich registriere demzufolge natuerlich auch nur diese eine SIP-ID. Alle Telefonnummern funktionieren einwandfrei und werden an die verschiedenen Endgeraete (ueber die Sip-Header Auswertung) sauber getrennt weitergeleitet.

- sparkie
 
Zuletzt bearbeitet:
Und mappe alle meine Telefonnummern auf genau eine SIP-ID .

Das funktioniert aber nur, wenn alle Gespräche über den einen Asterisk laufen. Wenn eine ID von mehr als einem Gerät oder Asterisk registriert werden sollen, kommt bei deiner Lösung nur der Asterisk dran.
 
@sparkie: Da bist Du eine der seltenen Ausnahmen, die das so konfiguriert hat - standardisiert lassen es die Leute in der Grundeinstellung mit genau dem beschriebenen Effekt.

@kombjuder: Wenn alle geschalteten Rufnummern auf einen (Sub)account gemapped werden, ist implizit, dass auch nur an diesem signalisiert wird. Will man das nicht, also sollen sich mehr als ein (Sub)account registrieren und dann auch Calls zu einer (bestimmten) Rufnummer erhalten, darf man das von sparkie beschriebene Mapping nicht machen.
 
Wenn eine ID von mehr als einem Gerät oder Asterisk registriert werden sollen, kommt bei deiner Lösung nur der Asterisk dran.

ok, ich nehme die komplette Verwaltung aller Rufnummern fuer alle Endgeraete nur in meinem zentralen Asterisk vor, das stimmt. Um den geschilderten Problemen von vorneherein aus dem Weg zu gehen :)

Ich habe folgendes deswegen nicht selbst getestet:

Wenn jemand verschiedene Asterisks und/oder Endgeraete auf eine gemeinsame SIP-ID registriert, bekommen dann nicht *alle* Endgeraete einschliesslich aller Asterisks den Ruf parallel zugestellt, wenn ein Ruf auf der gemeinsamen SIP-ID reinkommt?
 
Zuletzt bearbeitet:
@kombjuder: Wenn alle geschalteten Rufnummern auf einen (Sub)account gemapped werden, ist implizit, dass auch nur an diesem signalisiert wird. Will man das nicht, also sollen sich mehr als ein (Sub)account registrieren und dann auch Calls zu einer (bestimmten) Rufnummer erhalten

ich betreibe zwar keine SIP Telefone, aber kann man an so einem Geraet nicht wenigstens einstellen auf welchen SIP-HEADER(to) es hoeren soll?
 
IMHO Nein.
Das Endgerät verhält sich bezüglich einer bestehenden SIP-Registrierung so wie vergleichsweise der Asterisk (in einem entsprechenden Kontext) mit

Code:
exten => _.,1,Dial(....)

Soll heißen: Sobald auf einem Endgerät ein INVITE zu einem registrierten Account kommt, ist dem Endgerät der TO-HEADER IMHO egal und das INVITE wird beantwortet (also Endgerät klingelt oder signalisiert der Quelle (dem Provider) Rufumleitung oder DoNotDisturb oder was es sonst noch geben mag ....)
Können also zu einer Registrierung verschiedene TO-HEADER kommen, wird ein Endgerät alle akzeptieren.
Asterisk als PABX täte das bei vorgenanntem Schnipsel auch, bei einer dedizierten Auswertung des TO-HEADERS natürlich ggf. nicht ...
 
Hallo zusammen,

die SIP-HEADER(to) Auswertung ist sicherlich die beste Variante. Allerdings kann man die drei Accounts aus dem oben gezeigten Beispiel auch relativ simpel über die register extension differenzieren.

Beispiel:
Code:
[B]sip.conf[/B]
register => 123456e0:[email protected]/123456e0
register => 123456e1:[email protected]/123456e1
register => 123456e2:[email protected]/123456e2

[sipgate-in]
type                    = friend
insecure                = port,invite
fromdomain              = sipgate.de
host                    = sipgate.de
context                 = wasauchimmer
Code:
[B]extensions.conf[/B]
[wasauchimmer]
exten => 123456e0,n,GoTo(intern,100,1)
exten => 123456e1,n,GoTo(intern,101,1)
exten => 123456e2,n,GoTo(intern,102,1)


Gruß
R.
 
Zuletzt bearbeitet:
So hatte ich es auch mal laufen. Das war aber mit asterisk 1.4. Mit asterisk 1.6 ging das nicht mehr. Ausserdem benutze ich extensions.ael. ist viel viel comfortabler. Es bleibt wohl nur das SSP-HEADER(TO). Aber wieauchimmer, schoen aufpassen: NICHT im peer callerid=xxx eintragen. das wurde bei callback ins Auge gehen.

Gruss
Noway
 
Hallo ihr lieben!

Ich habe mich an den Tipps oben versucht, jedoch erfolglos. Im Resultat war ich nachher so erhitzt, dass ich frustriert die ohenhin gefrickelte Telefonanlage auf dem alten vServer platt gemacht und sie vernünftig neu aufgesetzt habe.

Ich habe nun Asterisk der Version 1:1.6.2.9-2+squeeze4 sammt Asterisk-GUI 2.0 laufen.
Per Webinterface habe ich alle 3 Trunks registriert und jeweils eine eingehende Regel nach der jeweiligen SIP-ID angelegt. Resultat: Er nörgelt, er könne die Extension "s" nicht finden und legt auf.
Also habe ich für jeden eingehenden Trunk einen Wildcard-Pattern angelegt. Resultat: Er nimmt auf dem ersten Trunk an.

Den Vorschlag von rmh habe ich bereits ausprobiert (nachdem ich die Trunks entfernt habe). Mit dem Resultat, dass er sich nicht mehr registrierte.

Meine derzeitige Config sieht wie folgt aus:
users.conf (Auszug):
Code:
[trunk_1]
host = sipgate.de
username = [Meine Kunden-Nummer]e0
secret = [Mein SIP-Passwort]
trunkname = Sipgate0  ; GUI metadata
context = DID_trunk_1
hasexten = no
hasiax = no
hassip = yes
registeriax = no
registersip = yes
trunkstyle = voip
outboundproxy = sipgate.de
fromdomain = sipgate.de
fromuser = [Meine Kunden-Nummer]e0
authuser = [Meine Kunden-Nummer]e0
insecure = port,invite
disallow = all
allow = ulaw,alaw,gsm,g726,speex

[trunk_2]
host = sipgate.de
username = [Meine Kunden-Nummer]e1
secret = [Mein SIP-Passwort]
trunkname = Sipgate1  ; GUI metadata
context = DID_trunk_2
hasexten = no
hasiax = no
hassip = yes
registeriax = no
registersip = yes
trunkstyle = voip
outboundproxy = sipgate.de
fromdomain = sipgate.de
fromuser = [Meine Kunden-Nummer]e1
authuser = [Meine Kunden-Nummer]e1
insecure = port,invite
disallow = all
allow = ulaw,alaw,gsm,g726,speex

[trunk_3]
host = sipgate.de
username = [Meine Kunden-Nummer]e2
secret = [Mein SIP-Passwort]
trunkname = Sipgate2  ; GUI metadata
context = DID_trunk_3
hasexten = no
hasiax = no
hassip = yes
registeriax = no
registersip = yes
trunkstyle = voip
outboundproxy = sipgate.de
fromdomain = sipgate.de
fromuser = [Meine Kunden-Nummer]e2
authuser = [Meine Kunden-Nummer]e2
insecure = port,invite
disallow = all
allow = ulaw,alaw,gsm,g726,speex

Code:
[DID_trunk_1]
include = DID_trunk_1_default
[DID_trunk_1_default]
exten = [Meine Kunden-Nummer]e0,1,Voicemail(11,u)
exten = s,1,Voicemail(11,u)

[DID_trunk_2]
include = DID_trunk_2_default
[DID_trunk_2_default]
exten = [Meine Kunden-Nummer]e1,1,Voicemail(12,u)
exten = s,1,Voicemail(12,u)

[DID_trunk_3]
include = DID_trunk_3_default
[DID_trunk_3_default]
exten = [Meine Kunden-Nummer]e2,1,Voicemail(12,u)
exten = s,1,Voicemail(12,u)

Mag sich ein Asterisk-Guru für jemanden, der sich wenig mit Asterisk auskennt und bei dem Telefonanlagen nicht zu den Hauptinteressen gehören, erbarmen und eine DAU-freundliche Hilfestellung leisten?

Ich danke vielmals im Voraus! :)


Liebe Grüße!





PS:

Es ist beabsichtigt, mehrere Trunks zu nutzen. Dass die verwendeten Trunks derzeit alle einem Kunden gehören und theoretisch schon bei Sipgate gebündelt werden könnten, ist mir bewusst (auch, wenn ich es nicht hinbekommen habe). Es ist jedoch angedacht, mehrere verschiedene Kunden von Sipgate über die Telefonanlage laufen zu lassen.

Ach ja, bevor komische Nachfragen kommen: Mit "Kunde" meine ich Kunde von Sipgate, nicht Kunde von mir. Ich selbst betreibe die Telefonanlage als Hobby und die anderen Kunden nutzen diese ebenfalls privat. Also kein Wohnzimmerprovider oder so ;)
 
Zuletzt bearbeitet:
Hi Artimis,

bei Sipgate erfolgt die Registrierung nach dem Schema:

Code:
register => SIP-ID:[email protected]/SIP-ID
Wenn sich dein Asterisk anschließend nicht mehr registriert, dann liegt das vermutlich an einem Tippfehler deiner Zugangsdaten.
In dem oben gezeigten Beispiel wird mit GoTo in einen Kontext "intern" gesprungen, der selbstverständlich vorhanden sein muss damit das Beispiel funktioniert. Ich bin mir nicht sicher, in wie weit du mit der Funktionsweise von Asterisk vertraut bist bzw. die weiter oben im Thread angesprochenen Thematik der unterschiedlichen Asterisk-Versionen verinnerlicht hast. ...


Gruß
R.
 
Hallo rmh!

Eine solche Zeile ist in meiner derzeitigen Konfiguration gar nicht vorhanden.
Als ich sie anstelle der jetzigen Configs für die Trunks einbaute, wurden diese ignoriert.
Einen Tippfehler konnte ich durch mehrfaches pedantische Überprüfen sowie durch das Mitlesen der SIP-Debugs ausschließen.
 
Die Trunks sind ja auch registriert (sonst kämen keine eingehenden Anrufe), insoweit ist da alles in Ordnung.
Das beschriebene Phänomen (alles landet im ersten Trunk) ist Asterisk-spezifisch, da die Trunks die gleiche (externe) IP verwenden (alles SIPGATE) und Asterisk dann nicht differenziert sondern (versionsabhängig) den ersten oder letzten entsprechenden Eintrag der sip.conf (respektive users.conf) nutzt.
Damit musst Du (und sorry, keine Ahnung, wie man das bei der "tollen GUI" hinbekommt) im eingehenden Kontext eine Differenzierung über die Zielrufnummer machen, um die Anrufe korrekt zu veerteilen, Diese Logik wird m.E. nicht über die GUI konfigurierbar sein, sondern muss mit eigenen extensions (wie auch immer das bei der GUI funktioniert) definiert werden. In diesem Thread haben wir das weiter vorne für einen nativen Asterisk durchexerziert.
 

Neueste Beiträge

Statistik des Forums

Themen
246,274
Beiträge
2,249,296
Mitglieder
373,863
Neuestes Mitglied
RuthBeatty
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.