[gelöst] Asterisk nimmt keine eingehenden Anrufe entgegen

[rmh]

Lösungshinweis ...
Unter Asterisk 1.6.0.20-rc1 sollte im Register-String der Port weggelassen werden, da es sonst (im konkreten Fall im Zusammenspiel mit Sipgate) zu einer fehlerhaften Registrierung kommen kann.

Funktionierendes Schema ohne Portangabe:
register => 1111111:[email protected]/1111111

Problematisches Schema:
register => 1111111:[email protected]:5060/1111111

Stand: 6. Jan. 2010

---

-
Originalbeitrag ...
Hallo Asteriskgemeinde,

nach drei Tagen Versuch und Irrtum, schaffe ich es immer noch nicht, Asterisk dazu zu bewegen, eingehende Anrufe via SIP entgegen zu nehmen. Zum Einsatz kommt Asterisk 1.6.0.20-rc1. Bei eingehenden Anrufen erhalte ich folgende Fehlermeldung im *CLI:

chan_sip.c:18123 handle_request_invite: Call from 'sipgate_in' to extension 's' rejected because extension not found.

Demnach wird also nach der 's' extension gesucht. Sobald ich diese erzeuge (z.B. exten => s,1,Dial(SIP/Nebenstelle)), kann ich den Anruf auch entgegennehmen. Es ist aber nicht mein Ziel alle eingehenden Anrufe über die 's' extension abzuwickeln (siehe meine extensions.conf).

Meine sip.conf:

; ------------------------------------------------------------------
; sip.conf
; --------
; Allgemeine Einstellungen
; ------------------------
;
[general]
context=default

externhost=meinalias.homedns.org
externrefresh=10
localnet=192.168.0.0/24
bindport=5060					
bindaddr=192.168.0.7			
srvlookup=yes

disallow=all					
allow=alaw
allow=ulaw

language=de
nat=yes
canreinvite=no
minexpiry=60
defaultexpiry=180
maxexpiry=3600

tos_sip=cs3					
tos_audio=ef					
tos_video=af41			
tos_text=af41			

cos_sip=3                   
cos_audio=5                  
cos_video=4          
cos_text=3            


; ------------------------------------------------------------------
; Register SIP Provider
; ---------------------
; Benutzer A Sipgate
register => 1111111:[email protected]:5060/1111111

; Benutzer B Sipgate e0
register => 2222222e0:[email protected]:5060/2222222e0


; -----------------------------------------------------------------
; Kontexte der SIP Provider zum Raustelefonieren
; ----------------------------------------------
;
; Benutzer A
[1111111]
type=friend
insecure=port,invite
username=1111111
fromuser=1111111
fromdomain=sipgate.de
secret=XYZXYZ
host=sipgate.de
qualify=yes
canreinvite=no
dtmfmode=rfc2833

; Benutzer B e0
[2222222e0]
type=friend
insecure=port,invite
nat=yes
username=2222222e0
fromuser=2222222e0
fromdomain=sipgate.de
secret=YZXYZX
host=sipgate.de
qualify=yes
canreinvite=no
dtmfmode=rfc2833


; -----------------------------------------------------------------
; Kontexte der SIP Provider für eingehende Gespraeche
; ---------------------------------------------------
;
[sipgate_in]
type=friend
insecure=port,invite
fromdomain=sipgate.de
host=sipgate.de
qualify=yes
disallow=all
allow=alaw
allow=ulaw
context=incoming


; ----------------------------------------------------------------
; Anmeldekontexte der Endgeraete
; ------------------------------
;
; Benutzer A
[31]
callerid=Benutzer A <31>
type=friend
username=31
secret=geheim
host=dynamic
mailbox=31
dtmfmode=rfc2833
canreinvite=no
qualify=yes
context=intern

; Benutzer B
[68]
callerid=Benutzer B <68>
type=friend
username=68
secret=geheim
host=dynamic
mailbox=68
dtmfmode=rfc2833
canreinvite=no
qualify=yes
context=intern

Hier die dazugehörige extensions.conf

; --------------------------------------------------------------------
; extensions.conf
; ---------------
; Allgemeine Einstellungen
; ------------------------

[general]
static=yes
writeprotect=no

[globals]

[default]
include => incoming

[benutzer_a_intern]
include => intern
include => benutzer_a_out	

[benutzer_b_intern]	
include => intern
include => benutzer_b_out		


; --------------------------------------------------------------------
; Nebenstellen / SIP-Telefone
; ---------------------------
;
[intern]
exten => 31,1,Dial(SIP/31) 
exten => 31,2,Congestion
exten => 31,102,Busy

exten => 68,1,Dial(SIP/68) 
exten => 68,2,Congestion
exten => 68,102,Busy


; --------------------------------------------------------------------
; Raustelefonieren
; ----------------
;
[benutzer_a_out]
include => default
exten => _X.,1,Dial(SIP/${EXTEN}@1111111)
exten => _X.,n,Congestion

[benutzer_b_out]
include => default
exten => _X.,1,Dial(SIP/${EXTEN}@2222222e0)
exten => _X.,n,Congestion


; --------------------------------------------------------------------
; Ankommende Gespraeche
; ---------------------
;
[incoming]
exten => 1111111,1,Dial(SIP/31)
exten => 01234567831,n,Dial(SIP/31)

exten => 2222222e0,1,Dial(SIP/68)
exten => 01234567868,n,Dial(SIP/68)

Ich möchte also erreichen, dass ein eingehender Anrufe anhand der SIP-ID oder der gewählten Rufnummer erkannt wird, und die zugeordnete Nebenstelle klingelt. Nichts besonders also.
Ich habe viel zum Thema gelesen und diverse Anleitungen nachvollzogen. Mein Halbwissen um Asterisk ist aber noch recht frisch und so komme ich hier nicht weiter. Fällt jemanden auf woran es scheitert? Ich bin für jeden Hinweis dankbar!

 

[himpierre]

Warum macht ihr es euch am Anfang immer alle so schwer. Du hast bei Deinen SIP Peers keinen Context definiert also landen die in default nicht in incoming. "canreinvite" gibts bei 1.6.2 übrigens nicht mehr. Nennt sich jetzt "directmedia".

 

[rmh]

Nunja, da die SIP-Provider [1111111] und [2222222e0] nur zum raustelefonieren verwendet werden, ist ein Context hier - nach meinem Verständnis - überflüssig. chan_sip signalisiert ja, wie eingangs gezeigt, dass eingehende Anrufe im Context [sipgate_in] landen. Nach meinem Verständnis sollten diese Anrufe dann über context=incoming in der extensions.conf landen. Warum dann nach der 's' extension gesucht wird, ist mir ein Rätsel.

Übrigens verwende ich in diesem Beispiel wie eingangs beschrieben Asterisk 1.6.0, wobei selbst bei 1.6.2 beide Keywords gültig sein sollten.

Danke dennoch für diesen Hinweis. Ich gehe jeder Vermutung nach und freue mich über weitere Antworten.

 

[kombjuder]

Ich gehe jeder Vermutung nach und freue mich über weitere Antworten.

Einen Kontext default anlegen (exten => _X.,1,Dial...) und im debug schauen ob und mit welchen Werten er den default anspringt.

 

[rmh]

OK, hab ich getestet. Im Detail habe ich die extension.conf wie folgt editiert:

[default]
exten => _X.,1,Dial(SIP/68)

Das hat aber wie vermutet nichts gebracht, da bei eingehenden Anrufen [sipgate_in] angesprochen wird, und damit sollte nicht default, sondern incoming angesprungen werden, so wie es definiert wurde. Das zeigt sich auch unverändert in der ausgabe von chan_sip wie oben. Schon seltsam, dass meine extensions gar nicht erkannt werden und statt dessen die 's' extension gesucht wird.

 

[Joel]

ähmm

[incoming]
exten => 1111111,1,Dial(SIP/31)
exten => 01234567831,n,Dial(SIP/31)

exten => 2222222e0,1,Dial(SIP/68)
exten => 01234567868,n,Dial(SIP/68)

exten => 01234567868,n,Dial....

n????

exten => 01234567831,n,Dial....

n????

Würde da mal auch 'ne 1 statt n hinfummeln.

 

[rmh]

Danke, völlig richtig. Das habe ich nun in meiner extensions.conf korrigiert. Das war's aber noch nicht. Bei eingehenden Anrufen wird jedoch immer noch nach der 's' extension gesucht. ...

 

[Joel]

Probier mal ein "include" vom "incoming" im "default" in der extensions.conf

Und 'nen restart.

 

[rmh]

[default]
include => incoming

hat auch nicht geholfen. sip show users zeigt mir, dass eingehende Anrufe aus der sip.conf [sipgate_in] den Kontext incoming erhalten. Soweit so gut.
Ich werde die Konfiguration nun auf einer anderen Maschine testen. Wenn noch jemandem etwas einfällt, immer her damit, ich raufe mir schon schon seit Tagen die Harre.

 

[Joel]

Und type = peer bei den Sipgate Definitionen, nicht friend.

 

[VoIP_Indianer]

Das läßt sich noch sehr viel einfacher lösen.

Ab Asterisk 1.6 landet ein ankommender Anruf immer im ersten passenden Context der sip.conf. Früher war das genau umgekehrt - da landete er im letzten passenden, der in der sip.conf steht.

Wenn Du also das [sipgate_in] einfach als ersten Context in der sip.conf einbaust, wird der ankommende Anruf auch im gewünschten Context incoming landen und Du brauchst überhaupt nix anderes zu ändern.

 

[Joel]

Danke für die Info

 

[rmh]

Danke für den Hinweis! Leider hat das hinaufsetzen des Blocks [sipgate_in] keine Verbesserung gebracht. Gesucht wird immer noch nach der 's' extension.
Noch eine Frage zum Verständnis: In meinem Beispiel ist incoming der erste passende Context, oder? Darüber steht nur default unter [gernal]. Wenn ich nun in der extensions.conf ein include => incoming unter [default] setze, hätte das dann den selben Effekt und es schließt sich der Kreis?

EDIT: Noch ein möglicherweise wichtiger Hinweis. Ich habe eben gesehen, dass sich Asterisk bei Sipgate wie folgt registriert: sip:s@meine-wan-ip-adresse.
Da liegt doch schon der Hund begraben, oder? Nur wie kommt es dazu?

 

[VoIP_Indianer]

Solange die Registrierung nicht korrekt funktioniert, kann natürlich auch ein ankommender Anruf nicht korrekt zugeordnet werden.

Schau Dir doch mal im SIP debug an, wie die Registrierung Deines Servers bei Sipgate durchgeführt wird.

Wenn der ankommende Anruf die korrekten Daten enthält, funktioniert die Zuordnung richtig.

Du darfst Contexte der sip.conf nicht mit denen der extensions.conf verwechseln. Die entscheidende Reihenfolge bezieht sich nur auf die Peer-Contexte in der sip.conf. In der extensions.conf ist die Reihenfolge der einzelnen Abschnitte (fast) egal.

 

[rmh]

Alles klar, danke für die Informationen. Ich werde dann mal nach der Ursache forschen und hier berichten, wenn ich eine Lösung habe.



EDIT: Das Problem konnte ich eben lösen. Ob es an Sipgate oder an Asterisk 1.6.0 liegt, ist mir schleierhaft:

Bei Registrierungen nach dem Schema:

register => 1111111:[email protected][COLOR="Red"]:5060[/COLOR]/[COLOR="RoyalBlue"]1111111[/COLOR]

wird die Extension nicht erkannt und daher die 's' extension verwendet. Eingehende Anrufe können nicht zugeordnet werden, da man beim Provider (konkret bei Sipgate) unter sip:s@wan-ip-adresse bekannt ist.
Lässt man einfach nur den Port :5060 weg (bei mir eine Altlast von Asterisk 1.4), dann klappt die Registrierung auf anhieb, die Extension wird erkannt und eingehende Anrufe werden korrekt signalisiert.

Ich möchte mich bei allen bedanken die sich der Thematik angenommen haben. Wenn noch jemand eine nachvollziehbare Erklärung liefern kann, nur her damit.
Danke!

 

[VoIP_Indianer]

Ob es an Sipgate oder an Asterisk 1.6.0 liegt, ist mir schleierhaft:
[...]
Wenn noch jemand eine nachvollziehbare Erklärung liefern kann, nur her damit.

Vermutlich schlicht ein Bug in Asterisk 1.6.0. Bei meinem Asterisk mit 1.6.2 läßt sich das Problem nicht reproduzieren.

Davon abgesehen ist die Angabe eines Ports auch nicht wirklich notwendig.

 

[Joel]

Jetzt würde mich aber doch noch interessieren, was passiert wenn er den [sipgate_in] wieder nach unten setzt.

 

[rmh]

[sipgate_in] mit dem zugehörigen context=incoming ist bei mir unter den anderen Sipgate-Konten, und vor den Nebenstellen definiert. Darüber existiert nur [gernal] mit dem context=default. Das funktioniert absolut problemlos. Die gesamte Problematik war einzig und allein auf die Angabe des Ports im register-String zurückzuführen. Die Angabe ist - wie VoIP_Indianer festgehalten hat - nicht notwendig, aber prinzipiell zulässig, daher ist mir das auch nicht als vermeintlicher Fehler aufgefallen. Kleine Ursache, große Wirkung.

 

[VoIP_Indianer]

In Deiner Konfiguration, wo du [incoming] in [default] mit include einhängst (was definitiv KEINEN Sinn macht) kannst Du [sipgate_in] auch komplett weglassen und es wird funktionieren. Deine Anrufe landen derzeit nämlich nicht in [incoming] sondern in [default] und dort ist [incoming] eingebunden. Warum Du überhaupt so ein dubioses (unsauber, schwer durchschaubar) Konstrukt verwendest, wird sich wohl nur Dir selbst erschließen

 

[rmh]

Warum Du überhaupt so ein dubioses (unsauber, schwer durchschaubar) Konstrukt verwendest, wird sich wohl nur Dir selbst erschließen

Lieber VoIP_Indianer. Ehrlich gesagt ist das meine erste selbst gezimmerte Asterisk-Konfiguration in Anlehnung an betateilchens Kurs (an dieser Stelle noch einmal herzlichen Dank), jedoch mit zahlreichen eigenen Basteleien und Codeschnipseln aus dem Asterisk-Buch. Die oben gepostete Konfiguration ist experimentell, zudem macht es mir Spaß verschiedene Dinge zu testen und zu sehen was dann passiert.
Deinen Hinweis (unsauber, schwer durchschauar) nehme ich ernst. Ich will schließlich noch was lernen und das Zusammenspiel der Kontexte verstehen.

EDIT: Übrigens irrst du dich. Eingehende Anrufe werden sehrwohl in incoming signalisiert, auch nachdem ich include => incoming aus [default] der extensions.conf entfernt habe.