Sipgate: Manchmal gehts, manchmal "Leider ist ein Fehle

klaymen

Neuer User
Mitglied seit
9 Sep 2004
Beiträge
57
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

Ich bin mir nicht ganz sicher, ob das ein Sipgate oder Asterisk Problem ist... Ich habe Asterisk-1.0-RC2 auf meinem Linux (SuSE 9.1) laufen, welche auch als Firewall dient. Die Kiste hat 2 Interfaces, eins ins Internet und eins in mein LAN. Asterisk kann somit firewallfrei operieren. Im LAN hab ich ein GrandStream BT101. Das GS registriert sich beim Asterisk, und dieser sich bei Sipgate; d.h., asterisk operiert als B2BUA.

Problem: Als ich mein Sipgate Account erstnals auflud, konnte ich ins Festnetz keine Nummern anrufen (ausser Gratisnummern), es kam nur die Stimme "Leider ist ein Fehler aufgetreten". Das ging über Stunden so... als ich dann mal probehalber das GS direkt auf Sipgate verband (also ohne asterisk dazwischen), gings zwar erst auch nicht, aber dann plötzlich klappte alles... Danach habe ich das GS dann wieder via asterisk verbunden, und siehe da, es klappte auch hier. Also dachte ich, das Problem sei wohl bei Sipgate gelegen.

Ein paar Stunden ging es aber wiederum nicht (und übrigens auch via X-Lite nicht). Als ich dann aber wieder das GS direkt verband, klappte es wieder, und jetzt auch wieder via Asterisk. Momentan klappt es (seit einer Stunde), aber vielleicht gehts morgen wieder nicht.

das kann Zufall sein, aber es könnte auch sein, dass nach einer gewissen Zeit irgend etwas expired, was Asterisk nicht handeln kann, sondern nur GS. Vielleicht eine Art Authentifikation, die Sipgate erwartet, wenn man längere Zeit nicht telefoniert hat? Wäre mir aber schleierhaft.

Ich habe den Datenverkehr gelogged. An sich sieht alles prima aus, auch die Authentifikation - etwa so (aus dem Kopf):
Code:
1 - *>Sipgate: INVITE
2 - Sipgate>*: Trying
3 - Sipgate>*: Proxy Authentication required
4 - *>Sipgate: ACK
5 - *>Sipgate: INVITE mit Proxy-Authorization
6 - Sipgate>*: Trying
7 - Sipgate>*: Session Progress
8 - Sipgate>*: OK
9 - *>Sipgate: ACK
....
10- *>Sipgate: BYE mit Proxy-Authorization
Ein Unterschied zwischen dem GS und sowohl Asterisk als auch X-Lite ist, dass GS auch Paket 9 (also das nackte ACK) mit einem Proxy-Authorization Header versieht, während sowohl asterisk als auch X-Lite dies unterlassen. Könnte da eventuell der Bock liegen? Aber wie gesagt, verhält sich da X-Lite auch nicht besser als Asterisk...

Hier noch die relevanten Teile aus meinen Konfig-Files:

sip.conf:
Code:
[general]
defaultexpirey=>1800
register=>1838074:####@sipgate.de/4991130838074
context=sip
port=5060
bindaddr=0.0.0.0
srvlookup=yes

[Sipgate]
type=friend
username=1838074
secret=####
host=sipgate.de
fromuser=1838074
fromdomain=sipgate.de
nat=no
dtmfmode=info
canreinvite=no
insecure=very
disallow=all ; Disallow all codecs
allow=ilbc

[GSIn]
type=friend
username=GSIn
secret=####
dtmfmode=info
host=dynamic
defaultip=10.1.41.188
context=intern
canreinvite=no
nat=0
mailbox=1234

extensions.conf:
Code:
[general]
static=yes
writeprotect=no

[globals]
CONSOLE=Console/dsp
SIPGATEID=1838074
...

[intern]
include => shortcuts
include => nikotel-out
include => sipgate-out
include => stanaphone-out
include => mutual-out
include => sip

[sipgate-out]
exten => _X.,1,SetCallerID(${SIPGATEID})
exten => _X.,2,SetVar(SIP_CODEC=ilbc)
include => sipgate-intern  ; Kurzwahlen, 10000, etc
include => sipgate-plain   ; 1.., z.B. andere Sipgate Kennungen
include => sipgate-de
include => sipgate-intl    ; 00..
include => sipgate-natl    ; 0..
include => sipgate-local   ; Rest

[sipgate-intern]
exten => _XX,3,Dial(SIP/${EXTEN}@Sipgate,60,)
exten => _XXXXX,3,Dial(SIP/${EXTEN}@Sipgate,60,)

[sipgate-plain]
exten => 1.,3,Dial(SIP/${EXTEN:1}@Sipgate,60,)

[sipgate-de]
exten => _0049.,3,Dial(SIP/0${EXTEN:4}@Sipgate,60,)

[sipgate-intl]
exten => _00.,3,Dial(SIP/${EXTEN}@Sipgate,60,)

[sipgate-natl]
exten => _0.,3,Dial(SIP/0041${EXTEN:1}@Sipgate,60,)

[sipgate-local]
exten => _N.,3,Dial(SIP/004131${EXTEN}@Sipgate,60,)

Danke für jedwede Hilfe :)

Andreas
 
So, ein paar Stunden später, nach diversen ethercap Auswertungen bin ich auf den Bug gestossen - ein asterisk Konfigurationsproblem, und vielleicht hilfts auch Anderen weiter.

Beobachtung 1: Sipgate scheint eine vorgängige Registrierung auch für ausgehende Anrufe, nicht nur für eingehende anrufe zu benötigen (was ja nicht selbstverständlich ist). Daher meine "1-Stunden-Beobachtung": Das Phone führte eine korrekte Registrierung durch (mit einer 1-Stunden-Expiration), darum konnte ich danach 1 Stunde lang via Asterisk problemlos heraustelefonieren. Die Asterisk-Registrierungen bei Sipgate waren offenbar fehlerhaft, obschon sie von Sipgate korrekt bestätigt wurden. Ich bemerkte das dadurch, dass in der 1-Stunden-Limit Sipgate alle paar Minuten (unregelmässig) Keepalive Pakete einerseits auf den SIP-Port von Asterisk, andererseits auf den SIP-Port des Phones (resp. dessen ge-NAT-eten Port der Firewall) schickte, und auch Re-Registrierungen von Asterisk mit 2 Bindings bestätigte (im OK-Paket auf meine Registrierung)
Code:
Contact: <sip:[email protected]> exp. 600
Contact: <sip:[email protected]:1025>, exp. 1468
Das erste Binding stammt von Asterisk (ich habe das testweise auf 10 Minuten heruntergesetzt), das zweite noch vom GrandStream (1025 ist der Port der Firewall, der auf den SIP-Port des Phones weist). Asterisk hat also schon beide Registrierungen festgehalten... bloss, mit verschiedenen Contacts! In der Tat hatte ich in sip.conf den Eintrag:
Code:
register=>1838074:####@sipgate.de/4991130838074  ; <<<<< FALSCH! Telefonnummer als Contact!
Das klappt zwar für einkommende Anrufe... erlaubt aber offenbar keine eingehendenAnrufe! Ich habe das dann geänder nach:
Code:
register=>1838074:####@sipgate.de/1838074 ; <<<<< KORREKT! Sipgate-Nummer als Contact!
Und jetzt scheint alles zu klappen (naja, noch ein paar Stunden warten, obs hinhält :).

Wichtig: In extensions.conf muss man aber trotzdem die Telefonnummer im Dialplan behalten, nicht die Sipgate Nummer, also z.B.
Code:
exten => 4991130838074,2,Macro(stdexten,SIP/GS-ilbc) ; <<<<  KORREKT
und nicht etwa
Code:
exten => 1838074,2,Macro(stdexten,SIP/GS-ilbc) ; <<<< FALSCH
obschon ja in sip.conf jetzt 1838074 als Contact steht! Andererseits schadet es aber i.a. auch nicht, im Dialplan zur Sicherheit beides drinzulassen, also
Code:
exten => 4991130838074,2,Macro(stdexten,SIP/GS-ilbc)
exten => 1838074,2,Macro(stdexten,SIP/GS-ilbc)

Summa summarum sollte man also eine Konfiguration ähnlich der Folgenden benutzen:

sip.conf:
Code:
[general]
defaultexpirey=>1800
register=>1838074:####@sipgate.de/1838074
context=>sip
...

[Sipgate]
type=friend
username=1838074
secret=####
host=sipgate.de
fromuser=1838074
fromdomain=sipgate.de
nat=no ; oder yes, je nachdem
dtmfmode=info
canreinvite=no
insecure=very
disallow=all ; Ich nutze nur ilbc für Sipgate
allow=ilbc

[GSin]  ; lokales BudgetTone Telefon
type=friend
context=intern
...

extensions.conf:
Code:
[general]
static=yes
writeprotect=no

[globals]
CONSOLE=Console/dsp
SIPGATEID=1838074
...

[intern]
include => sipgate-out
include => sip

[sipgate-out]
exten => _X.,1,SetCallerID(${SIPGATEID})
exten => _X.,2,SetVar(SIP_CODEC=ilbc)  ; Ich nutze nur ilbc für Sipgate
exten => _X.,3,Dial(SIP/${EXTEN}@Sipgate,60,)

[sip]
exten => 4991130838074,2,Macro(stdexten,SIP/GS-ilbc)
exten => 1838074,2,Macro(stdexten,SIP/GS-ilbc) ; zur Sicherheit....
 
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.