.titleBar { margin-bottom: 5px!important; }

Einstellungen 2 SIP Clients mit ident. IP, ein VoIP Account

Dieses Thema im Forum "Grundsätzliches" wurde erstellt von tscoreninja, 27 Juni 2005.

  1. tscoreninja

    tscoreninja Mitglied

    Registriert seit:
    22 Feb. 2005
    Beiträge:
    425
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Liebe Forenmitglieder,

    brauche Hilfe von den Foren/SIP Gurus, bin hier am Debuggen eines Problems, und habe vermutlich die Ursache identifiziert, weiss aber nicht, wer schuld ist, VoIP Provider, Gerätehersteller oder gar mein Router.

    Sachverhalt: ein Account von dus.net, zwei Endgeräte am Sipura SPA-2000. Laut dus.net Support unterstützt, wenn man zweimal den selben SIP Port verwendet. Raus gehts problemlos. Bei eingehenden Gesprächen klingelt aber immer nur ein Gerät. Verwende ich zwei verschiedene Ports ( 5060/61) mit einem sipgate Account, läuten beide bei ankommenden Gesprächen. Wird aber von dus.net aber wohl nicht unterstützt (dazu muss der Provider an beide Ports jeweils einen INVITE schicken, was dus.net nicht tut, im syslog festzustellen). Stelle ich auch bei sipgate identische Ports ein, funzt es auch bei sipgate nicht (hier natürlich nur ein INVITE im syslog zu sehen). Also meine Fragen:

    -sollten an einem SIP-Client mit zwei Accounts beide klingeln, ist es also ein Fehler seitens Sipura? Da dus.net sagt, Leute würden dies so erfolgreich betreiben, und ich konkret einen Bericht von jemandem mit der Fritzbox habe, wo es funktioniert, frage ich mich, ob dies als Bug desSipura Adapters zu betrachten ist.

    oder

    -verlangt dus.net etwas vom Client, was nicht standardkonform ist, und gibt es einen guten Grund, dass zwei Clients mit identischer IP Adresse nicht mit identischem Port betrieben werden sollten

    oder

    -kann es mein Router sein, der dies irgendwie verbockt? Mir fällt aber kein guter Grund dafür ein... anyway, Gerät mit Proxy und STUN konfiguriert

    Wenn es Fragen zur Konfig gibt, nur zu. Hab ggfs syslog Dateien, wenn es weiter helfen sollte, und Danke im Voraus für Hilfe,
    TSCoreNinja
     
  2. Gast

    Gast Guest

    Hallo,
    ich habe meine Erfahrungen auch schon mit mehreren Sipurageräten gemacht,dabei sogar speziell hinter einer Fritz Box Fon,die normalerweise den 5060 für sich beansprucht und es somit schwierig ist,dahinter ein weiteres SIP-Gerät zum Laufen zu bringen.
    Selbst bei unterschiedlichen Anbieteraccounts müssen fast immer unterschiedliche Ports eingetragen werden,in diesem Fall nicht unbedingt,da sich die Geräte automatisch einen anderen Port von der FBF beziehen.
    In Deinem Fall geht es ja wohl um ein und den selben Account,der auf zwei Telefone signalisieren soll !?
    Hierbei ist es sowohl vom genutzten Endgerät,als auch vom Router abhängig,welcher Port einzustellen ist.
    Bei der FBF geht es mit ein und demselben Port,wenn die Box als Router fungiert,ich weiß leider nicht,wie Dein Router das handhabt.
    In meinem SPA 841 z.B.habe ich alle 4 Accounts auf 5060,egal ob gleiche oder unterschiedliche Accounts!
    Also schließe ich daraus,daß vieles auch vom Router abhängig ist.
    Soviel zu meinen Ausführungen.
    Gruß von Tom
     
  3. tscoreninja

    tscoreninja Mitglied

    Registriert seit:
    22 Feb. 2005
    Beiträge:
    425
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @Opilein, vielen Dank für die Antwort.
    Ja, genau.
    Am Router liegt es IMHO nicht. Zu meinem Verständnis vom Problem:
    SIP unterscheidet zwei Adressen, die AOR oder Address of Record, und die Contact URI. Die Adress of Record ist z.B. $USER_ID@voip.dus.net fuer einen dus.net Account. Beim Registrieren beim Provider hinterlegt ein SIP Clients seine Contact URI, an die eine Anfrage auf der AOR weitergeleitet wird (ist eine solche hinterlegt, erscheinen hier die lustigen kleinen Icons in der Signatur, dass der Teilnehmer erreichbar ist). Gebe ich meine Accountdaten beim Sipura ein und benutze NAT, ist die Contact URI zunächst z.B. $USER_ID@192.168.1.5:5060 (man bemerke hier die interne IP).
    STUN und der Router sorgt dafuer, dass diese von ausserhalb als
    $USER_ID@$WAN_IP:5060 angesprochen wird/werden kann.

    Zu meinem Problem:
    1. registrieren sich nun zwei (logische) SIP Clients von gleicher IP und mit gleichem Port, besteht lediglich eine Contact URI beim Provider, und zwar $USER_ID@$WAN_IP:5060 Kommt nun ein Anruf mit SIP INVITE Nachricht herein, muss der Router diesen ggfs. zum richtigen/allen Gerät weiterleiten. Hier nicht das Problem, gibt nur eine IP, und da kommt der INVITE laut syslog trace an. Aber damit bei einem Gerät mit einer IP/zwei logischen Accounts dann auch beide Leiungen klingeln, muss der Client hier auch erkennen, dass beide Accounts identische Contact URIs haben, und den Anruf auf beide Lines weitergeben ("Call Forking"). Tut anscheinend die Fritzbox Fon, nur der Sipura leider nicht. Ob das Verhalten des Sipuras laut SIP Standard sinnvoll, erlaubt, oder ein Bug ist, können vermutlich nur SIP Gurus entscheiden. Der Cisco/Linksys/Sipura Support hat jedenfalls meine Schilderung des Problems nicht verstanden, und bei mir einen entsetzten Lachkrampf über diese geballte Kompetenz ausgelöst: Damit auch andere daran teilhaben können, hier die fragliche Passage aus der Support Antwort:
    2. registrieren sich nun zwei (logische) SIP Clients von gleicher IP und mit unterschiedlichem Port, finden sich zwei Contact URIs beim Provider. Sipgate schickt dann auch zwei SIP INVITES an beide Contact URIs, dus.net nur einen INVITE an das letzt-registrierte Gerät. Ob eines dieser Verhalten vom SIP Standard vorgeschrieben ist, weiss ich nicht. Jedenfalls hab ich schon Feed-Back vom dus.net Support, dass die Technik eine Änderung des Verhaltens prüfen wird (an dieser Stelle einen herzlichen Dank für den überaus hilfreichen dus.net Support, ein wesentlicher Grund, warum ich meine Wahl des VoIP Providers auch anderen empfehlen kann).
     
  4. Gast

    Gast Guest

    Na gut,so tief bin ich nicht in die Materie eingedrungen,ich wollte auch nur feststellen,daß bei mir zwei Telefone klingeln,die ein und denselben Account inne haben und auf Port 5060 lauschen.
    Allerdings bei mir die Besonderheit,daß der Sipura hinter der FBF sitzt.
    Gruß von Tom
     
  5. JSchling

    JSchling Gesperrt

    Registriert seit:
    21 Sep. 2004
    Beiträge:
    1,543
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Hi,
    also zumindest kann ich dein Problem nachvollziehen und bestaetigen, ist ein DUSnet Problem. Wenn ich mich auf 2 verschiedenen Ports anmelde, dann klingelt es nur bei dem Geraet, welches als letztes angemeldet wurde.
    Nun kenne ich das Sipura-Ding nicht, aber die Fritzbox nimmt alle Accounts ueber den Port 5060. Wenn nun ein zweiter Client, ob Software oder Hardware ist egal, benutzt werden soll, dann muss das ja zwangslaeufig ueber einen anderen Port gehen, denn einen Port kann ich nur einem lokalen Client zuweisen. Wie kurz erwaehnt, wenigstens die Fritzbox macht alle VoIP-Accounst ueber den gleichen UDP-Port 5060, unter Windows, also mit Software, muss unabhaengig von VoIP jedem Programm ein einzelner Port zugewiesen werden, den noch kein anderes aktives Programm verwendet.
    Dein Problem muss eigentlich DUSnet loesen, halte ich auch fuer einen groben Fehler bei denen und muesste nicht sein. Als Workaround kannst du aber Sipsnip verwenden, denn bei denen klappt das mit verschiedenen Clients ueber verschiedene Ports anzumelden und bei allen klingelt es (wie bei den meisten Anbietern, z.B. auch GMX) und da Sipsnip so einen StayConnected Service hat, koenntest du ueber den den DUSnet Account anmelden. Die Gespraeche gehen dann von DUSnet zu Sipsnip und von dort unabhaengig vom Port zu allen aktiven VoIP-Clients. Das Rauswaehlen ueber StayConnected laesst sich auch konfigurieren, es ist prinzipiell machbar ueber Sipsnip den DUSnet-Account zu verwenden, ohne das es bei Sipsnip was kostet - von mir aber noch nicht getestet.
    Aber eigentlich sollte DUSnet das Problem beseitigen, ist very schmal von denen.
    Ansonsten musst du das etwas genauer erklaeren, was du da hast und wie versuchst. Wie gesagt, ich kenne das Sipurading nicht, aber ich kann mir kaum vorstellen, dass du den Account 2mal in dem Teil konfigurieren musst und das auch noch mit unterschiedlichen Ports, damit es an zwei Fon-Ports des Sipurateils klingelt, bzw das unglaubliche waere wirklich, wenn du dafuer 2 unterschiedliche Ports benutzen musst. Die Fritzbox als ein Geraet an einem Port auf einer lokalen IP macht das ja auch.
     
  6. tscoreninja

    tscoreninja Mitglied

    Registriert seit:
    22 Feb. 2005
    Beiträge:
    425
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Also IMHO Opinion sind sowohl das Verhalten des Sipura als auch das von dus.net problematisch, bzw nicht optimal. Aber der dus.net Support hat meine Infos in die Technik weitergeleitet, die wollen schauen, ob die das ändern können.

    Zum Sipura: der besteht aus quasi zwei unabhängigen Accounts. Sind diese verschieden (z.B. wegen des Ports), ist es an dem Location URI zu erkennen, zu welchem Telefon der Anruf gehört, und kann durch Vergleich mit den hinterlegten Accountdaten das richtige angesprochen werden. Sind diese gleich, muss der Test auch noch für den zweiten gemacht werden, auch wenn der erste schon übereinstimmt... Macht der Sipura aber offensichtlich nicht, im Gegensatz zur Fritzbox. Nur leider kann ich das dem inkompetenten Support nicht mitteilen...

    Für mich ist das Problem technisch geklärt, ein Workaround ist übrigens auch ein SIP Proxy oder Asterisk auf meinem Router, was eh eins meiner Ziele ist... ;-) Damit ich was zum Basteln habe... Siehe forum.chupa.nl und das unslung build System bzw openwrt.org


    TSCoreNinja
     
  7. kudrix

    kudrix Neuer User

    Registriert seit:
    22 Aug. 2005
    Beiträge:
    4
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo, habe ein ähnliches Setup: Zwei Telefone an Line 1 und Line 2, registriert mit gleichen Accountdaten von GMX, jeweils unterschiedliche Ports (5063 und 5061). Bei mir klingeln bei eingehenden Anrufen beide Telefone. Habe das gerade erst so konfiguriert, scheint aber einwandfrei zu funktionieren.