Problem mit SIP account der Auth.Name benötigt

dg7feq

Mitglied
Mitglied seit
4 Mai 2004
Beiträge
224
Punkte für Reaktionen
0
Punkte
16
Hallo,
ich versuche einen SIP-Account in der Fritzbox einzutragen der eine Authentification User ID benötigt.
Ich habe mich soweit durchgegoogled und die Config der Box mit FB Edit ausgelesen und den authname editiert.
Nach dem Zurückspielen der Config auf die Box (anscheinend erfolgreich da keine Fehlermeldung) und einem Neustart ist das entsprechende Feld aber wieder leer.

Der Provider benötigt folgende Zugangsdaten:

Username : +66240xxxxx
Password : xxxxx
Authorizations User ID : [email protected]
Domain : catnextgen.com
Outbound Proxy : 202.129.61.102 (= sip1.catnextgen.com)

So sieht es jetzt in der Config aus:

ua10 {
enabled = yes;
username = "$$$$45IUPSMA2EV2YQJRUGM4FJUM2Y2X5NEMC1OQ2BUZDVXJLNYMH4ADPO3KXOTNYA6BBUVV51QYVZGZCAAA";
authname = ""; --- ich gehe mal davon aus das hier die Authorizations User ID reingehört
passwd = "$$$$HSVGNPJL3VVFU3K24YUQR55WOH2PXDK6LDAUEHW3LLT6YB1MO1CHAVVJKZYK52NZX5G4IJRBVAPGQAAA";
registrar = "sip1.catnextgen.com";
ttl = 30m;
sipping_enabled = no;
sipping_interval = 280s;
name = "+6624026157";
providername = "";
ims_client = no;
with_displayname = no;
dtmfcfg = dtmfcfg_automatic;
rtpevent_keep_packetrate = no;
register_failwait = 0w;
register_failwaitmax = 30m;
stunserver = "";
stunserverport = 3478;
use_internat_calling_numb = no;
is_nat_aware = no;
localip = 0.0.0.0;
protocolprefer = protocolprefer_ipv4only;
ignore_received_header = no;
always_clir = no;
clirtype = clir_displayname;
colptype = colp_none;
clipnstype = clipns_off;
vad_enabled = no;
only_one_dialog = no;
presence_supported = no;
mwi_supported = yes;
mwi_inmemoria = no;
ccbs_supported = no;
reg_support = regsupport_auto;
packetization = packetization_fixed;
tx_packetsize_in_ms = 30;
xrtp_periodic = 0;
reject_refer = yes;
no_register_fetch = no;
do_not_register = no;
only_call_from_registrar = no;
invite_without_register_allowed = no;
outboundproxy = "202.129.61.102";
outboundproxy_without_route_header = no;
factory_3pty_uri = "";
no_hold_speech = no;
dditype = ddi_none;
ddireception = "";
webui_trunk_id = "";
alias_head_number = "";
cfxsignaling = cfx_standard;
backup_wanted = no;
use_session_timer = no;
use_rport = yes;
add_rtpmap_for_all_codecs = no;
answer_only_one_codec = no;
without_annexb_no = no;
srtp_supported = no;
use_488_for_no_t38 = no;
g726_via_rfc3551 = no;
no_g726_32_offer_with_pt2 = no;
g726_fixed_ptime30 = no;
dtmf_inband_on_g711g722 = no;
enable_3xx = yes;
t38_reinvite_from_remote = no;
use_t38version0 = no;
rtcp_xr_media_attribute = no;
ptime_a_attribute = yes;
tones_and_announcements_for_service = no;
read_p_asserted_identity_header = no;
route_always_over_internet = no;
sipiface = sipiface_automatic;
altc_attribute_rfc6947 = no;
gui_readonly = no;
convertstate = 0;
snmp_instance = 0;
}

Ich bin für jegliche Tipps dankbar... :)

- - - Aktualisiert - - -

Nachtrag:

FB Version: 7270 v 3 mit 74.06.06
FB Editor 0.7.0.6
 
Hallo, erst einmal Danke, daß du dich aus dem anderen Thread so sauber entfernt hast (machen leider nicht alle so).

So, nun zu deinem Problem:
Ja, "authname" sollte schon die Authorizations User ID sein.
Du könntest probieren nur die Zeichen vor dem "@" einzugeben.

Aber ich würde es als 1. versuchen über die GUI
Dort mußt du unbedingt "Eigene Rufnummer für die Anmeldung verwenden" anklicken,
dann wird "authname" gefüllt mit dem, was du bei "Benutzername" angegeben hast.

Ich habe es gerade getestet, nur leider fehlt mir dein PW. ;)
 
Zuletzt bearbeitet:
dann wird "authname" gefüllt mit dem, was du bei "Benutzername" angegeben hast.
Meine Erfahrung mit cheapvoip zeigt, dass authname gefüllt wird mit dem, was unter "Internetrufnummer" steht.
Da dieses Feld aber kein @ zulässt und die Modifikation der voip.cfg auch nicht klappt, behaupte ich mal, dass mit der Fritz kein Account mit catnextgen möglich ist.

Ein Teilnehmer mit ähnlichen Problemen hat sich aus Verzweiflung auf den Asterisk gestürzt:
http://www.ip-phone-forum.de/showthread.php?t=255166&p=1888435&viewfull=1#post1888435

oder mit Phonerlite telefonieren. Damit soll es klappen.

Uups, ist ja der selbe Teilnehmer dg7feq.
 
Zuletzt bearbeitet:
Ist das ein spezifisches Problem der älteren Firmware-Version?

Wenn ich (113.06.55-irgendwas) für einen Account einen Wert bei "authname" eintrage, dann kann der problemlos ein @ enthalten und genau der dort abgelegte Wert wird auch als "username" im "Authorization"-Header vom voipd verwendet.

Ansonsten würde ich zuerst auf eine nicht geglückte Modifikation der Einstellungen über den FBEditor tippen ... warum sollte die FRITZ!Box (solange da keine TR-069-Konfiguration vom Provider erfolgt, was hier offenbar nicht der Fall ist) von sich aus den Wert in "authname" noch einmal ändern? Wenn es tatsächlich ein Fehler in der Firmware ist, mag das sein ... aber als "geplantes Verhalten" macht es - zumindest auf den ersten Blick - ja wenig Sinn.

Ich würde hier noch einmal eine Korrektur der Einstellungen über den Shell-Zugriff vornehmen (mit "nvi", dabei nicht vergessen, den ctlmgr vorher zu stoppen, damit dessen Kopie im Speicher nicht irgendwann doch wieder die Änderung rückgängig macht - und hinterher den ctlmgr wieder starten) und im Anschluß den voipd beenden und neu starten (ob der SIGHUP richtig behandelt, weiß ich nie sicher).
 
Ich hätte blond getippt, dass
Code:
name = "+6624026157";
dass das Plus-Zeichen Ärger macht? U.U. mal durch 00 ersetzen.
LG
 
Die Versuche vor 3,5 Jahren waren dann aber sicherlich noch mit einer älteren Firmware-Version. Die 06.05/06.06 gab es noch nicht und generell hat sich bzgl. SIP mit dessen zunehmender Verbreitung bei den Providern und dem Wechsel auf FRITZ!OS 6 ja einiges getan.

Ich kann in #1 nicht so richtig erkennen, wie der genaue Ablauf beim Editieren der Einstellungen nun war ... der FBEditor liefert an dieser Stelle nur selten Fehlermeldungen (mein persönlicher Eindruck) und wenn der anschließende Neustart nicht automatisch erfolgte, ist das schon mal ein ziemlich sicheres Zeichen dafür, daß die Änderungen auch nicht erfolgreich waren.

Ich kann in #1 nicht erkennen, ob der automatisch erfolgte und selbst wenn, ist das auch wieder noch kein Beweis für erfolgreiche Änderungen (hier ist der Umkehrschluß eben nicht richtig -> kein Neustart = Mißerfolg ist sicher, aber Neustart = Erfolg ist nicht garantiert).

Auch wenn es etwas starrsinnig wirken mag (und ich so gar keine Lust habe, das jetzt auf der 06.06 selbst zu testen, ob es nicht doch ein Firmware-Bug ist) ... ich würde nach wie vor erst einmal sicherstellen, daß die Änderung tatsächlich bis in die voip.cfg gelangt und das ist bei der 06.06 ja nun praktisch gar nicht mit Arbeit verbunden (im Gegensatz zu späteren Versionen ohne Telnet und noch späteren mit weiteren Improvements).
 
ok ok


Behandelt? Sorry, es wurde ihm empfohlen, aber hier
lese ich trotzdem +...
egal und sollte nur Tip sein. Bin kein Experte und hatte wohl mal feststellen müssen, das bei der SIP-Geschichte es oftmals Probleme gibt mit nicht rein numerischen Zeichen. Sprich, alles andere als reine Ziffern 0-9 können Ärger machen.

LG

Als Bsp. http://www.ip-phone-forum.de/showthread.php?t=284996&p=2157450&viewfull=1#post2157450
 
Hallo,
ja, der alte thread war mit einer 7170 die schon lange eingemottet ist und ich wollte das ganze jetzt nochmal angehen.
Ich hatte schon einmal die 00xxx in der FB eingetragen für den asterisk account, daher hatte ich jetzt +xxx genommen, Ich schmeiß mal den asterisk account aus der FB raus und richte den cat2call direkt nochmal ein.

Ja, der FB Editor gibt keine Fehlermeldung aus wenn ich die Config zurückspiele, danach starte ich die FB manuell neu.

Prinzipiell klappt die Einbindung über Asterisk ja, aber ich habe da aus Sicherheitsgründen nur eingehende Anrufe eingerichtet. Mein Tarif beinhaltet aber 240 Inlandsminuten (innerhalb Thailands) pro Monat, die ich natürlich auch gerne benutzen möchte. Ich traue mir nur nicht so ganz zu den Asterisk auf dem vServer wirklich hackersicher einzurichten.

Danke schonmal für Eure zahlreichen Infos bis hierher!

Chris
 
Ja, der FB Editor gibt keine Fehlermeldung aus wenn ich die Config zurückspiele, danach starte ich die FB manuell neu.
Damit bin ich bereit, ein kleines Vermögen darauf zu setzen, daß die Einstellung gar nicht im FRITZ!OS angekommen ist.

Der FBEditor benutzt für die Änderung der Einstellungen die "Wiederherstellen"-Seite und diese hat sich auch mit der 06.51 noch einmal gewandelt.

Ich weiß gar nicht, ob es die "alte" Seite mit der unbesehenen Übernahme aller Einstellungen wirklich noch gibt ... bei meinen jüngsten Versuchen kam eigentlich immer die "cfgtakeover"-Seite, unabhängig davon, ob die Checkbox für selektive Übernahme auf der Seite mit der Auswahl der Datei angehakt war oder nicht. Wenn das so wäre (kann man ja mit einfachem Export und Re-Import leicht selbst prüfen), dann kann der FBEditor damit nicht (mehr) umgehen.

In solchen Fällen ist es immer sinnvoller, die geänderte Datei vom FBEditor speichern zu lassen und den Import von Hand auszuführen ... dann sieht man auch, wie die Box reagiert.

- - - Aktualisiert - - -

Doch, auch die Seite mit der direkten Übernahme gibt es noch ... das klappt sogar, wenn man beim ersten Anlauf das Kennwort richtig eingibt. Auf der "cfgtakeover"-Seite bin ich wohl nur gelandet, weil ich vergessen hatte, überhaupt ein Kennwort einzugeben und beim zweiten Versuch wollte die Box immer nur die selektive Übernahme erlauben (aus ihrer eigenen Sicherung wohlgemerkt, also kein Wechsel des Modells oder so).
 
So, ich habe jetzt erstmal über die GUI versucht. Meine bisherigen Einstellungen sehen wie folgt aus, geht aber nicht ( ERROR 482 - loop detected?)
cat2call_fritz_gui.png

der registry string im Asterisk sieht übrigens wie Folgt aus:
+662402xxx:yyyyy:[email protected]@catnextgen.com/+662402xxxx
 
Zuletzt bearbeitet:
Teste mal "Haken raus" bei Anmeldung mit eigener Rufnummer. Nicht, dass [email protected] versucht wird.
Proxy u.U. auchmal weglassen.
Statt der IPs mal mit sip.catnextgen.com probieren.

LG und viel Glück
 
geht leider beides nicht. Anscheinend hat sich auch x firmwareversionen später bei der fritzbox nichts an der Tatsache geändert das Provider mit username und auth. id nur schwer zu integrieren sind.
Oder ist bei den Zugangsdaten meines Anbieters irgend etwas sehr exotisch?
 
Wie sollen wir dabei jetzt helfen?

Ist es wirklich so schwer, ein Telefon in die Hand zu nehmen, mit dessen Hilfe den Telnet-Zugang zu aktivieren, dann per Telnet den Account mal in die voip.cfg so einzutragen, wie es ja offensichtlich mit dem FBEditor versucht wurde und nicht funktioniert hat (wo da die Ursache liegt, interessiert Dich ja auch irgendwie nicht weiter) und dann nach dem Beenden und Neustarten des voipd einfach mal die SIP-Registrierungen direkt auszulesen mit "showshringbuf sip" oder meinetwegen auch aus den Support-Daten zu extrahieren (wenn die bei der 06.06 schon enthalten waren, gucke ich jetzt nicht extra nach)?

Wenn die Antwort ein "ja" ist, weiß ich ehrlich gesagt auch nicht, warum man sich darum bemühen sollte, hier Hilfe zu leisten.

Aus der Tatsache, daß die Änderung mit dem FBEditor nicht funktioniert hat (wenn man der Schilderung des Ablaufs folgt), wird kühn die Schlußfolgerung gezogen, die FRITZ!Box würde sich weigern, so eine Einstellung zu akzeptieren ... das ist aber schlicht falsch, wie ich bereits in #4 geschrieben habe, nachdem ich es extra noch getestet hatte (wenn auch mit einer moderneren Version, weil ich es für vertretbar halte, wenn jemand mit dem Problem es tatsächlich selbst probiert, ob ihn ein Vorschlag zum Ziel führt oder nicht).

Über das GUI wird es (bei der 06.06) vermutlich wirklich nicht einzutragen sein ... jedenfalls nicht so, daß die Werte im jeweils richtigen Kontext in einer SIP-REGISTER-Message landen und da die FRITZ!Box sich in erster Linie an "Consumer" in D richtet und die meisten SIP-Provider hier auch in einer FRITZ!Box verwendbar sind (auch ohne manuelles Editieren), halte ich die Feststellung, daß sich seit x Generationen nichts geändert hat bei der Anmeldung für SIP-Accounts, für etwas selbstsüchtig.

Du hast ein spezielles Problem mit einem thailändischen Provider ... dafür hat sich offenbar seit x Generationen nichts geändert. Warum sollte aber ein Kunde in D eine ausführlichere (und damit automatisch auch kompliziertere) Eingabemaske brauchen, wenn sich 19 von 20 der hier üblichen Accounts auch mit dieser per GUI einstellen lassen?

Derart zu verallgemeinern ist einfach über das Ziel hinausgeschossen ... zumal ich die eigenen Bemühungen zur Lösung irgendwie überlesen habe, außer einem Versuch mit dem FBEditor und Variationen im GUI steht da bisher nichts - nicht einmal eine systematische Suche in dem Fehlerprotokollen, aber spätestens da könnte man sehen, wie sich die Variationen der Einstellungen im GUI auf die erzeugte SIP-Nachricht auswirken.
 
Du hast mit Deiner Antwort im Prinzip Recht und ich werde das auch per telnet noch versuchen. Habe nur leider bedingt durch Beruf und Kinder immer nur mal ein paar Minuten Abends Zeit mich mit der Technik auseinanderzusetzen.
Ich berichte dann hier die weiteren Tests wenn ich am Wochenende hoffentlich etwas mehr Zeit hatte...
 
So, jetzt hatte ich endlich mal eine halbe Stunde Zeit:

die voip.cfg hat jetzt folgenden Eintrag:

Code:
       ua6 {
                enabled = yes;
                username = "+662402xxxx";
                authname = "[email protected]";
                passwd = "xxxxx";
                registrar = "202.129.61.102";
                ttl = 30m;
                sipping_enabled = no;
                sipping_interval = 280s;
                name = "00662402xxxx";
                providername = "";

Hier der Ausschnitt aus dem sip log

Code:
2016-07-03 17:31:52.619 - OUT: from=192.168.178.1%33:5060 to=202.129.61.102 port=5060:
REGISTER sip:202.129.61.102 SIP/2.0
Via: SIP/2.0/UDP 93.130.250.249:5060;rport;branch=z9hG4bK3E8A199FA0CC50E4
From: <sip:[email protected]>;tag=2928587983
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 3 REGISTER
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7270 v3 74.06.06 (Sep 24 2015)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0



2016-07-03 17:31:52.882 - IN: from=192.168.178.1%33:5060 to=202.129.61.102 port=5060:
SIP/2.0 482 Loop Detected
Via: SIP/2.0/UDP 93.130.250.249:5060;received=202.129.61.97;branch=z9hG4bK3E8A199FA0CC50E4;rport=5060
From: <sip:[email protected]>;tag=2928587983
To: <sip:[email protected]>;tag=2123631745
Call-ID: [email protected]
CSeq: 3 REGISTER
Content-Length: 0

muss ich da eventuell noch irgendwo einstellen das der auth name auch verwendet wird?
 
Der kommt gar nicht erst bis zum "401 Unauthorized", auf das der Client dann mit einem erneuten authentifizierten Versuch reagiert.

Hier wird bereits vorher mit "482 Loop Detected" die weitere Verarbeitung abgelehnt. Dieser Fehlercode ist eigentlich dafür vorgesehen, falls ein Paket irgendwo vor sich hinkreiselt und eine Station auf dem Weg feststellt, daß genau dieses Paket bereits bei ihr vorbeigekommen ist.

Mich irritieren etwas die gezeigten Adressen in den Zeilen vor dem eigentlichen Paketinhalt ... entweder da stimmt bei der alten Version etwas mit der Protokollierung nicht oder ich habe keine Ahnung, wer da mit wem redet. Wenn das REGISTER-Paket von der FRITZ!Box gesendet wurde (OUT: from=fritzbox to=provider), warum steht dann bei der Antwort auch "from=fritzbox to=provider", wenn das Paket doch "IN" ist. Die Unterscheidung wird hier wohl nur mit einem Paketmitschnitt auf der Routing-Schnittstelle und der 1. Internetverbindung gelingen ... dort sieht man den TCP-Paketen ja an, woher sie kommen und wohin sie gehen - da kann der voipd mit der Protokollierung keinen Zweifel streuen.

Dieses Ergebnis solltest Du jedenfalls auch mit leerem "authname" eigentlich erzielen ... denn der ist hier noch gar nicht im Spiel.

Wie sieht das denn aus, wenn Du vom Asterisk aus die Registrierung machen läßt? Das dürfte auch kein anderes Ergebnis bringen ... der Loop tritt ja nicht in der FRITZ!Box auf, sondern irgendwo beim Provider.

Was in diesem Zusammenhang auffällt, ist die abweichende IP-Adresse auf Providerseite im Via-Header ... die FRITZ!Box sendet (aus ihrer Sicht) an die IP 202.129.61.102, auf dem Server kommt der Request aber von der 202.129.61.97 - mag sein, daß da eine Lastverteilung o.ä. stattfindet - der Eintrag im Via-Header sollte erst irgendwo unterwegs um den "received"-Teil ergänzt werden (RFC 3581, Abschnitt 4).

Damit würde ich auch das "loop detected" eindeutig irgendwo beim Provider sehen ... wenn es mit Asterisk nicht auftritt, wäre der Vergleich der gesendeten Inhalte ein denkbarer Weg (auch wenn man das beim FRITZ!OS eher nicht beeinflussen kann, muß es ja einen entscheidenden Unterschied geben, wenn das kein temporärer Fehler beim Provider war/ist).

Bis zum "authname" kommt es jedenfalls erst gar nicht ... da stimmt schon vorher etwas nicht. Der gesendeten REGISTER-Nachricht würde ich jetzt nicht ansehen, was mit ihr nicht stimmt ... man könnte jetzt blind mit den Credentials jonglieren und alle möglichen Varianten ausprobieren. Wenn Du aber mit dem Asterisk eine funktionierende Registrierung hinbekommst, ist es doch schlauer, wenn man die REGISTER-Messages vergleicht und den Unterschied herausarbeitet. Ob man dann etwas dafür oder dagegen tun kann, steht vielleicht auf einem anderen Blatt - aber ohne Kenntnis der Ursache wird auch das nichts werden.
 
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.