Untereinander Telefonieren?!

[mk0000]

Hallo zusammen,
ich habe folgendes Szenario:

Einen zentralen Asterisk an dem aktuell 2 Sipgate Accounts registriert sind. Beide können telefonieren und angerufen werden. Wenn ich aber nun von dem einen den anderen Anrufe (mit der Sipgate-Rufnummer) schhlägt dies fehl, mit folgender Fehlermeldung:

[Jul  2 20:26:15] NOTICE[2396]: chan_sip.c:16048 handle_response_invite: Failed to authenticate on INVITE to '"Test2" <sip:[email protected]>;tag=as7e575a53'
    -- SIP/1434611e1-08edd3c8 is circuit-busy
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Auto fallthrough, channel 'SIP/340-08ed7b20' status is 'CONGESTION'
[Jul  2 20:26:15] NOTICE[2396]: chan_sip.c:18438 handle_request_invite: Unable to create/find SIP channel for this INVITE

Mache ich das ganze über die angelegte Kurzwahl im Asterisk geht dies Problemlos .Also 340 ruft 341 und anders herum...
Woran kann dies nun also liegen? Ich würde mich sehr über eine Antwort freuen, da mich das Problem schon etwas länger beschäftigt.
Ich benutze übrigens die Version 1.6.1.4, falls dies hilft.

Hier nochmal die wichtigen Ausschnitte aus den Konfigurationsdateien:

sip.conf:

[general]
context = default
bindport = 5060
bindaddr = 0.0.0.0
srvlookup = yes
language = de
tos_sip = cs3
tos_audio = ef
tos_video = af41
maxexpiry = 3600
minexpiry = 60
defaultexpiry = 600
registertimeout = 30
registerattempts = 0
externrefresh = 600
canreinvite = no
allow = alaw
allow = ulaw
t38pt_udptl = no

register = Sipgate-ID1:[email protected]/Sipgate-ID1		;TEST 1
register = Sipgate-ID2:[email protected]/Sipgate-ID2		;TEST 2

;Test1
[Sipgate-ID1]
type = peer
username = Sipgate-ID1
fromuser = Sipgate-ID1
secret = PW1
host = sipgate.de
fromdomain = sipgate.de
nat = yes
insecure = port, invite
qualify = yes
canreinvite = no

[test1_in]
type = peer
fromdomain = sipgate.de
host = sipgate.de
context = test1_sipin

;Test1
[Sipgate-ID2]
type = peer
username = Sipgate-ID2
fromuser = Sipgate-ID2
secret = PW2
host = sipgate.de
fromdomain = sipgate.de
nat = yes
insecure = port, invite
qualify = yes
canreinvite = no

[test2_in]
type = peer
fromdomain = sipgate.de
host = sipgate.de
context = test2_sipin

;Test1
[340]
callerid = Test1<340>
host = dynamic
secret = geheim
type = friend
nat = yes
context = 340
qualify = yes
canreinvite = no

;Test2
[341]
callerid = Test2 <341>
host = dynamic
secret = geheim
type = friend
nat = yes
context = 341
qualify = yes
canreinvite = no

extensions.conf:

[general]
static = yes
writeprotect = no

[test1_sipin]
exten => Sipgate-ID1, 1, DIAL(SIP/340)
exten => Sipgate-ID2, 2, DIAL(SIP/341)

[default]
include => test1_sipin

 

[Arcon]

ähm.. ok..
also in der Fehlermeldung sagt er es ja schon "besetzt", das kann z.b. aus dem grunde kommen, weil du test2_sipin nicht in der extensions hast..

ist wie beim fußbal, gib einem nem ball, und sag ihm nicht für welches team er spielt

 

[stinkstiefel]

Ob er nun test2_sipin angelegt hat oder nicht ist eigentlich fast egal. Asterisk weiss bei zwei Sipgate-Accounts type = peer leider eh nicht genau in welchen context das Gespräch geleitet werden soll.

 

[mk0000]

Vielen Dank für eure Antworten.
Komischerweise laufen aber die Anrufe ansonsten im test1_sipin auf...egal ob Acc 1 oder Acc2 angerufen wird.
Welcher Type sollte gewählt werden?

 

[rentier-s]

Das ist nicht komisch, sondern ganz normal. Das Thema haben wir kürzlich erst hier diskutiert. Asterisk kann einfach nur einen Context pro Host verarbeiten. Bis 1.4 war der letzte, seit 1.6 ist der erste Context-Eintrag für einen Host entscheidend.
Die extra ankommenden peers kannst Du Dir übrigens auch sparen. host und context oben mit rein funktioniert genau so.

Was ich an der ganze Sache nicht verstehe, warum Asterisk trotz insecure ein Problem mit der Authentifizierung meldet? :noidea:

@Arcon: einen fehlenden Context oder no matching extension würde Asterisk IMHO explizit melden.

[Edit:]
Mir ist noch was eingefallen, sipgate weigert sich vielleicht, eine Loopback Verbindung herzustellen. Also zumindest was das mal so. Wenn Du verbose höher stellst oder sip debug einschaltest, müsstest Du einen 482 Fehler mit einer entsprechenden Mitteilung bekommen.

[Edit2:]
Hier noch Deine sip.conf etwas vereinfacht:

[general]
context = default
bindport = 5060
bindaddr = 0.0.0.0
srvlookup = yes
language = de
tos_sip = cs3
tos_audio = ef
tos_video = af41
maxexpiry = 3600
minexpiry = 60
defaultexpiry = 600
registertimeout = 30
registerattempts = 0
externrefresh = 600
canreinvite = no
allow = alaw
allow = ulaw
t38pt_udptl = no

register = Sipgate-ID1:[email protected]/Sipgate-ID1		;TEST 1
register = Sipgate-ID2:[email protected]/Sipgate-ID2		;TEST 2

;Test1
[Sipgate-ID1]
type = peer
username = Sipgate-ID1
fromuser = Sipgate-ID1
secret = PW1
host = sipgate.de
fromdomain = sipgate.de
nat = yes
insecure = port, invite
qualify = yes
canreinvite = no
context = test1_sipin ; <== wird bei 1.4 nicht beachtet

;Test1
[Sipgate-ID2]
type = peer
username = Sipgate-ID2
fromuser = Sipgate-ID2
secret = PW2
host = sipgate.de
fromdomain = sipgate.de
nat = yes
insecure = port, invite
qualify = yes
canreinvite = no
context = test2_sipin ; <== wird bei 1.6 nicht beachtet

Rentier

 

[mk0000]

Hallo Zusammen,
auf Grund vieler Prüfungen habe ich es leider nicht früher geschafft.
Nun aber im Anhang die Debug-TXT.
Ich hoffe ihr könnt mir nun sagen wo das Problem liegt.

Vielen Dank im voraus.

 

[Thomas007]

Du hast unsaubere Context Definitionen und würfelst ein- und ausgehende Anrufe durcheinander.
Du musst erst mal die Registrierungen sauber definieren, hier ein Beispiel für eingehende Calls.

register => UserIDw@Context_in_1/DID1
register => UserIDw@Context_in_2/DID2

[Context_in_1]
type=peer
context=inbound
fromdomain=sipgate.de
host=sipgate.de
disallow=all
allow=alaw
allow=ulaw
nat=no
canreinvite=no
dtmfmode=auto
qualify=no



[Context_in_2]
type=peer
context=inbound
fromdomain=sipgate.de
host=sipgate.de
disallow=all
allow=alaw
allow=ulaw
nat=no
canreinvite=no
dtmfmode=auto
qualify=no

Context_in_1 ist mit Absicht kein FQDN. So kann man natürlich auch mehrere Registrierungen bei einem Provider in unterschiedliche Contexte lenken. Macht in der Regel aber keinen Sinn da man an Hand der DID unterscheidet wo der Anruf herkommt und hinsoll.

Ausgehende Calls haben damit überhaupt nichts zu tun und bekommen selbstverständlich einen eigenen Context (Name ungleich FDQN) wo dann auch username und secret definiert sind.
In einem Kontext für eingehende Calls username und secret zu definieren ist Unsinn, die stehen schließlich schon in der Registrierung (register =>..) drin.

So solltest Du Dein Problem lösen können...

 

[rentier-s]

Context_in_1 ist mit Absicht kein FQDN. So kann man natürlich auch mehrere Registrierungen bei einem Provider in unterschiedliche Contexte lenken.

Kannst Du uns dazu bitte in diesem Thread eine Beispielkonfiguration zeigen. Danach wird nämlich öfters gefragt und ich war bis jetzt der Meinung, das wäre technisch nicht möglich, und hab bislang auch noch nie was gegenteiliges gefunden.

Ausgehende Calls haben damit überhaupt nichts zu tun und bekommen selbstverständlich einen eigenen Context (Name ungleich FDQN) wo dann auch username und secret definiert sind.

Was spricht dagegen, eine Peer Definition für beides zu verwenden?

 

[mk0000]

Hallo zusammen,
wie rentier-s schon geschrieben hat, würde ich mich und wahrscheinlich auch viele andere über eine Beispielkonfiguration freuen.

 

[sparkie]

Kannst Du uns dazu bitte in diesem Thread eine Beispielkonfiguration zeigen. Danach wird nämlich öfters gefragt und ich war bis jetzt der Meinung, das wäre technisch nicht möglich, und hab bislang auch noch nie was gegenteiliges gefunden.

also ich verstehe nicht, wozu das eigentlich ueberhaupt erforderlich ist?

Es gibt doch genug andere Unterscheidungsmoeglichkeiten (am Context vorbei) fuer die tatsaechlich gewaehlte Nummer.

- sparkie

 

[rentier-s]

Hm, ich bin von Natur aus neugierig.
Ich geb Dir Recht, dass man die Unterscheidung im Dialplan machen kann. Aber die Frage ist halt schon einige Male aufgetaucht, und wenn es eine Lösung dafür gibt, würde sie mich zumindest interessieren.

Svenja

 

[sparkie]

Hm, ich bin von Natur aus neugierig.

ok, das ist eine sehr gute Begruendung

ich dachte schon, die 'Multi-Context' Variante bietet vielleicht irgendwelche Vorteile.

aus *diesem* Grund bin ich natuerlich auch an einer Loesung interessiert. Welche Variante letztlich die eleganteste ist, kann man sich dann immer noch aussuchen.

[EDIT] so wie ich es sehe dient aber das 'register =' in erster Linie dazu die Verbindung zum SIP Provider aufrecht zu erhalten. Damit Calls vom SIP-Provider auf die eigene Telefonanlage geforwarded werden koennen. Wegen der Firewall Rules sind ja nur intern initiierte SIP Verbindungen moeglich.
Aus Gruenden des Netzwerktraffic etc. ist es IMHO sowieso besser nur so wenig 'register =' wie moeglich abzusetzen. Was also gegen die 'Multi-Context' Variante spricht.[/EDIT]

- sparkie

 

[mk0000]

Nabend zusammen,
ich warte immer noch auf eine Lösung die ich für mein oben genanntes Problem nutzen kann und würde mich daher freuen wenn mir einer weiterhelfen könnte. Die letzten Posts gehen ja doch teilweise in unterschiedliche Richtungen.

Vielen Dank im voraus.

MfG
Michael

 

[rentier-s]

Hallo Michael,

Du willst also immer noch von einem auf dem Asterisk angelegten sipgate-Account auf einen zweiten, am selben Asterisk angelegten sipgate-Account rufen, oder?

Wie ich oben schon geschrieben habe, früher ging das bei sipgate nicht ("Loopback detected"). Kann sein, dass das immer noch so ist. Ggf. mal bei sipgate nachfragen.

Svenja

 

[mk0000]

Vielen Dank für deine Antwort Svenja,
werde dort heute mal nachfragen und mich wieder melden.
Desweiteren gab es ja oben Vorschläge zur umstrukturierung der sip.conf....welche macht am meisten Sinn?
NUr noch kurz ein paar Randinfos:
Ich habe einen Asterisk am laufen der aktuell ca. 30 Sipgate-Accounts besitzt. Die Config ist nach dem oben genannten Beispiel aufgebaut und braucht daher viele Zeilen...würde mich über jeden Änderungsvorschlag freuen.

MfG
Michael

 

[rentier-s]

Hallo Michael,

wenn Du viele Peers mit gleicher Konfiguration hast, solltest Du Dir die Verwendung von Templates anschauen.

Ansonsten denke ich mir immer, Sinn macht was einwandfrei funktioniert. Ob man das um ein paar Zeilen kürzen kann oder nicht, Hauptsache es ist übersichtlich und für Kollegen nachvollziehbar.

Svenja

 

[mk0000]

Hallo zusammen,
hier die Antwort von Sipgate:
Portierte Rufnummern werden wie von sipgate vergebene Rufnummern behandelt. Wenn
Sie von einem Account eine zu sipgate portierte Rufnummer anrufen, handelt es sich
um eine sip2sip Verbindung. Die Meldung "Loop detected" kommt i.d.R. vom Endgerät
das den Loop erkannt hat. Wir beeinflussen diese Verbindungen nicht und sperren
diese auch nicht.

Leider bringt mir das nun nicht viel...

 

[rentier-s]

Hm, OK. Dann kam die Meldung wohl von Asterisk, ich hätte immer gedacht sipgate wäre dafür verantwortlich.

Mehr dazu hier.

Svenja

 

[mk0000]

Vielen Dank für deine Antwort.
Das Loop-Detectet kommt doch aber in meiner debug-Datei von oben gar nicht vor.
Es kommen ja immer noch die Meldung wie oben im ersten Post in der ersten Box zu sehen....und da geht es ja mehr um ein INVITE als um ein Loop-Detect...

Ich wäre daher für jede Hilfe dankbar :-(

 

[rentier-s]

Das hier einmal:

[Jul 29 18:36:26] DEBUG[26270] chan_sip.c: Potential spiral detected. Original RURI was sip:Vorwahl/gewä[email protected], new RURI is sip:[email protected]

Ist ja noch OK, sipgate leitet Dich um von der Telefonnummer auf die sipgate-ID.

Und das hier zweimal:

[Jul 29 18:36:26] DEBUG[26270] chan_sip.c: Potential spiral detected. Original RURI was sip:[email protected], new RURI is sip:[email protected]

Wenn ich das richtig interpretiere, wird hier umgeleitet und versucht, die sipgate-ID direkt auf dem Asterisk zu erreichen.