SIP-Registrar nutzen über Dyndns oder VPN Fernzugang

[muenchner]

Das solltest du aber begründen wieso der port sowieso nicht geht .... das wäre mir neu

weil der Port sowieso nicht geht ist der port auch in der Ar7.cfg für tcp und udp freigeschaltet oder?

voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060", 
                    "tcp 0.0.0.0:5060 0.0.0.0:5060", 
                    "udp 0.0.0.0:7078+32 0.0.0.0:7078";

 

[pfeffer]

Genau lesen hilft

* bei der Registrierung besteht das Problem weiterhin (habe jetzt hierzu ein Ticket bei AVM geöffnet), nicht jedoch bei host= für den peer

Ich habe nochmal nachgedacht: Jetzt vermute ich, dass Dein Asterisk hinter einem NAT sitzt, richtig? Da hilft evtl. STUN + Portweiterleitung für den Asterisk, aber es besteht die Gefahr, dass STIN die nat=yes-Wirkung wieder kaputt macht... Evtl. musst Du asterisk seine externe IP irgendwie explizit sagen.

Gruß,
Pfeffer.

 

[cmmehl]

pfeffer - das hat mit dem NAT fuer asterisk nichts zu tun. Mein asterisk residiert auf einem vserver und hat dasselbe problem.

Ich glaube, ein ticket bei AVM zu eroeffnen war die richtige entscheidung - letztlich haben die was verbockt, so wie es ausschaut. Ich frage mich nur, weshalb. Irgendwo glaube ich mal gelesen zu haben, dass eine integration von OpenSER in die Fritzbox erwogen werde - das wuerde ja vermutlich derart probleme loesen. Und vielleicht existieren die aktuellen probleme eben weil das noch nicht fertig ist. Aber selbst wenn's stimmt bedeutet das sicherlich noch einige wartezeit.

Edit: OpenSER heisst jetzt openSIPS

 

[pfeffer]

1.

pfeffer - das hat mit dem NAT fuer asterisk nichts zu tun. Mein asterisk residiert auf einem vserver und hat dasselbe problem.

welches denn eigentlich?
bei rausgehenden Telefonaten funktioniert alles durch die Einstellungen fromdomain=fritz.box, host=xxx.dyndns.org und nat=yes, aber wo gibt es noch Probleme? bei eingehenden Anrufen? Ich würde denken, dass - wenn der asterisk an einer öffentlichen IP sitzt (und auch keine Firewall im Server selbst stört und die öffentliche IP nicht geNATet (ja sowas gibt's) und nicht hinter einer (z.B. Firmen-) Firewall sitzt), dann sollte es so in beide Richtungen (anrufen und angerufen werden) funktionieren und auch in beiden Richtungen Audio geben.

2.
Leider habe ich noch keinen Soft-Client für Windows Xp gefunden, der sowas kann wie "nat=yes". Probiert habe ich mit PhonerLite und mit Kapanga. Hat jemand noch ne Idee für einen am besten kostenlose Soft-Client, der das evtl. können könnte?

Gruß,
Pfeffer.

BTW: dass man nat=yes setzen muss, ist ein Bug (oder Absicht) von AVM. Ich habe deswegen auch ein Ticket bei denen aufgemacht.

 

[cmmehl]

1.
welches denn eigentlich?

Moin,

die registrierung am asterisk mit ich.dyndns.com, also:

register => 620:[email protected]

welche hingegen mit der aktuellen und korrekten IP-address funktioniert.

Und daraus folgend: keine eingehenden anrufe bei nutzung von ich.dyndns.com (wenigstens nicht ohne verrenkungen). Ausgehend hab ich nicht weiter probiert.

 

[pfeffer]

Du meinst: Die Registruerung des Asterisk an der FritzBox?
Bitte probiere es mal mit den gerade von mir wiederholten Einstellungen. Damit müsste es gehen.
Oder verstehe ich da was nicht? - kann man mit dem asterisk über die Fritz!box mit meinen EInstellungsempfehlungen raustelefonieren, ohne dass sich der asterisk vorher an der Fritz!Box angemeldet hat?

Gruß,
Pfeffer.

 

[Ottone]

1. @pfeffer, Thema NAT: Du kannst davon ausgehen, dass ich weiss wie man einen Asterisk hinter NAT betreibt. Aber nein, der hier hat eine statische öffentliche IP.

Meinst Du im Contact-Header der Request-Register-Nachricht?

2. Nein, da steht natürlich eigener Benutzername und eigene IP, nicht die der Fritz!Box.
Im request steht der dyndns hostname in "REGISTER", im "From" sowie im "To", und mindestens eine der drei Zeilen gefällt der Fritz!Box nicht: Sie antwortet mit "404 Not Found".

3. "nat=yes" schaltet nicht-RFC-konformes Verhalten ein und ist in Asterisk notwendig, da per WAN im INVITE von Fritz zu Asterisk der "Contact" header die LAN IP enthält (und im From header auch noch der LAN hostname zu finden ist). Mit "nat=no" folgt Asterisk stur RFC 3581, was aber hier nicht ausreichend ist.

[B]INVITE von Fritz SIP proxy zu SIP UA Asterisk im WAN[/B]
Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9gG2bK3E48E0E72650F7A3
From: <sip:[email protected]>;tag=92C413B6D21B6C23
Contact: <sip:[email protected]>

Callflow: SIP Telefon "asteriskuser" --> Asterisk --> Fritz als UA --> Fritz als proxy --> Asterisk als UA 623

4. Generell: Mir wäre es lieb diese Diskussion etwas strukturierter anzugehen. Sehr nützlich wäre es, wenn Du, pfeffer, Dir selber einen Asterisk aufsetzen könntest (als vserver, unter VMWare, auf einem alten Rechner in Deinem LAN, oder im AMAZON cloud), dann würden wir hier weniger aneinander vorbei reden. ;-)
Andrerseits: Die hier diskutierten Fehler bzw. Einschränkungen der .70 firmware sind klar erkannt und bedürfen eigentlich nicht wirklich einer weiteren Diskussion.

P.S.: Wunsch @AVM: Für die SIP Endgeräte 62x bitte auch die zwei Varianten des g.726 Codecs einstellbar machen.

 

[PsychoMantis]

[OT]Oder bestell dir einen Vserver kostenlos bei EuServ (betatest). Für Tests mit Asterisk würd der reichen. [/OT]

Irgendwie müsste man dem Asterisk sagen können, dass der die öffentliche IP in den Sip-Header rein tun soll, aber dyndns dennoch geht.

 

[stinkstiefel]

From: ergibt sich doch aus register => fromuser@fromdomain:secret@host ich bin nach wie vor der Meinung das es von extern falsch ist für fromdomain fritz.box zu verwenden, aber auf mich hört ja keiner.

 

[gerdshi]

Hi!

Doch, es ist richtig, wenn fritz.box auf der öffentliche IP-Adresse der Box aufgelöst wird/werden kann (egal wie man es löst).
Wenn du aber jetzt denkst "from" bedeutet "von" daher ist es falsch daz ziel einzutragen - nein, du liegst falsch.

In fromdomain MUSS der Registrar drin stehen entweder mit seiner IP-Adresse oder Hostname.
Zieh dir den Betateilchen Asterisk-Kurs rein bzw. lies die Doku zum
Asterisk....

Falls ich dich jetzt nicht falsch verstanden habe.

Gruss

 

[Ottone]

From: ergibt sich doch aus register => fromuser@fromdomain:secret@host

1. Dieses Format ist mir neu, ich wüsste nicht dass Asterisk ein REGISTER so mit @fromdomain unterstützt (man belehre mich eines besseren).

2. Ohne "fromdomain=" klappte es mit dem md5 hash des SIP Passworts (bzw. mit dem "nonce") nicht, and es gibt keine Konfigurationsoption in der 7270 um das anzupassen. Versuchst Du vielleicht zu sagen, dass die Box nach aussen hin auf eine andere Domäne als nach innen hin lauschen sollte?

Generell: Hier geht es ja um alle möglichen SIP UAs am SIP proxy, nicht nur um Asterisk, bitte nicht vergessen. Auch wenn für Asterisk ein workaround gefunden ist, so besteht das Problem weiterhin für eine Vielzahl anderer SIP clients. AVM ist also gefragt.

 

[stinkstiefel]

@gerdshi Wenn SIP-Proxy und SIP-Registrar eine Einheit bilden ist das wohl auch richtig. Seid Ihr sicher das Ihr bei der Fritz!Box auf eine solche Einheit trefft?

 

[jonnywi]

Sip-Registrar Lokal mit Phonerlite Verbinden Problem

Hallo ihr Freaks,
so ich hab mal die 12 Seiten durchgelesen und es wurden viele neue Anregungen geweckt, vorallem das Thema Asterix

Meine Umgebung:
Ich habe jetzt den neuen Sip-Registrar LOKAL mit Softphone (Phonerlite und X-lite) verbunden. Alles funzt, kann die VOIP und PSTN (Call by Call für handynummern) Leitung nutzen.
Meine analogen Nebenstellen kann ich auch über Softphone via **3, **1 anrufen.

Mein Problem:
wenn ich Phonerlite offen habe und ein Gespräch annehme, bekomme ich es nicht weitervermittelt auf mein Analoges Siemens Dect Fon 1 (**1)
in der Anleitung von Phoner lite steht, dass es 2 modis von vermitteln gibt:

* transfer with consultation call
    * blind transfer
Transfer with consultation call:
There is an incoming call and you go off hook. You want to transfer the call to someone else. So you create a new call to someone. The first call will be set on hold automatically. To initiate the transfer, just drag the active call over the held and drop it.

Blind transfer:
There is an incoming call and you go off hook. You put a new destination into the number field, but don't connect to it! You use drag&drop of the existing call to the edit field.

Bei X-lite wollte ich es auch probieren, aber die Xfer Transfer Funktion ist nur in der EyeBeam (Pro) verfügbar

Vielleicht kann mir jemand helfen?

Kleiner auszug von der PhonerLite Log bei der aktion
**1 eingeben und das Telefonat auf das eingegebene **1 ziehen

12:13:37,906: Facility Confirm: 11 00 01 00 80 81 07 00 01 00 00 00 00 00 01 00 00 
12:13:37,906: Facility Confirm (DTMF)
12:13:46,484: Generate DTMF: *
12:13:46,484: Facility Request: 18 00 01 00 80 80 33 01 01 01 01 00 01 00 09 03 00 64 00 3C 00 01 2A 00 
12:13:46,484: Facility (DTMF Send) Request (*)
12:13:46,546: Facility Confirm: 11 00 01 00 80 81 33 01 01 00 00 00 00 00 01 00 00 
12:13:46,546: Facility Confirm (DTMF)
12:13:58,484: Facility Request: 1D 00 01 00 80 80 CC 02 01 01 01 00 03 00 0E 0D 00 0A 01 00 06 01 00 80 2A 2A 31 00 00 
12:13:58,484: Facility Request (Supplementary Services: Call Deflection)
12:13:58,515: Facility Confirm: 16 00 01 00 80 81 CC 02 01 01 01 00 00 00 03 00 05 0D 00 02 00 00 
12:13:58,515: Facility Confirm (Supplementary Services): CD -> success
12:13:58,515: Facility Indication: 12 00 01 00 80 82 F5 02 01 01 01 00 03 00 03 0D 00 00 
12:13:58,515: Facility Indication (Supplementary Services): CD (Call Deflection) failed (000C)
12:13:58,515: Facility Response: 12 00 01 00 80 83 F5 02 01 01 01 00 03 00 03 0D 00 00 
12:13:58,515: Facility Response
-------------------------------------------
12:13:58,484: T: 192.168.166.254:5060 (UDP)
REFER sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.166.11:5060;branch=z9hG4bK009f0f354015de118551005056c00008;rport
From: <sip:[email protected]:5060>;tag=80ec28264015de118551005056c00008
To: <sip:[email protected]>;tag=D2A99AD548C8A6EB
Call-ID: [email protected]
CSeq: 18 REFER
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
User-Agent: SIPPER for PhonerLite
Refer-To: <sip:**[email protected]>
Content-Length: 0


-------------------------------------------
12:13:58,484: R: 192.168.166.254:5060 (UDP)
SIP/2.0 429 Provide Referrer Identity
Via: SIP/2.0/UDP 192.168.166.11:5060;branch=z9hG4bK009f0f354015de118551005056c00008;rport=5060
From: <sip:[email protected]:5060>;tag=80ec28264015de118551005056c00008
To: <sip:[email protected]>;tag=D2A99AD548C8A6EB
Call-ID: [email protected]
CSeq: 18 REFER
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.04.70 (Feb 18 2009)
Content-Length: 0

 

[Ottone]

Der SIP Proxy der Box kann noch nicht vermitteln.

 

[jonnywi]

Der SIP Proxy der Box kann noch nicht vermitteln.

Okay, danke für die schnelle und knappe Antwort!
Woher weisst du das? Ich finde dazu keine Informationen
Kommt das noch?? wenn ja, in abesehbarer Zeit??? möchte net auf jeder Box noch zussätzlich Asterix laufen lassen...
Ich habe mir schon die Finger wund gegoogelt und meine Augen sind schon ganz rot vor lauter Beiträge im Forum zu durchforsten :lamer:

Mit Asterix zusätzlich auf der Box würds also funzen, oder?

 

[pfeffer]

Das Verhalten der FritzBox kann also durch entsprechende Einstellungen am Asterisk als Client ausgeglichen werden.
Was wir jetzt brauchen, sind andere SIP-Clients, die die Probleme umgehen können.

Bei Nokia-Handys könnte evtl. die Einstellung "Loose Routing erlauben" ähnlichen Erfolg bringen wie "nat=yes" bei Asterisk. Leider weiß ich nicht genau, was "Loose Routing erlauben" macht, aber vom Namen her gibt es eine Chance. In Frage kommt auch "prefer early media".

Generell gilt: als Proxy die dyndns-Adresse angeben und als "Registrar" (manchmal auch "Domain", "Realm" oder eben bei Asterisk "fromdomain" genannt) immer "fritz.box", auch wenn man von extern zugreifen will.

Wenn auf Client-Seite noch NAT dazwischen ist, dann sind Portweiterleitungen in dem Router, der auf Client-Seite das NAT macht und STUN wahrscheinlich zusätzlich noch notwendig.

Bei Tests durch NATs bitte immer bedenken: wenn es einmal funktioniert hat, heißt das noch lange nicht, dass es beim nächsten Anruf auch noch funktioniert (jedenfalls solange keine Portweiterleitungen eingerichtet sind). Denn häufig werden - evtl. auch erst nach einiger Zeit - beim nächsten Anruf beim NAT andere Ports benutzt, so dass es plötzlich nicht mehr geht.

Gruß,
Pfeffer.

PS: getestet habe ich bisher: PhonerLite: das scheint mir keine Einstellung zur Umgehung eines NAT-Problems aus Serverseite (analog zu "nat=yes" im Asterisk) zu haben.
Wenn jemand Ideen hat, welcher kostenlose SIP-Client das evtl. können könnte -> Vorschläge sind willkommen.

 

[fredlcore]

Bei meinem E51 habe ich Loose Routing auch aktiviert (ohne zu wissen, was das ist). Letztlich aber gleiches Ergebnis: Ich kann hören, werde aber nicht gehört, auch dann nicht, wenn ich nicht hinter einem Router mit NAT sitze. Bei Phoner Lite wird mir bei öffentlicher IP angezeigt, dass sowohl ein- als auch ausgehender Codec gesetzt sind, hinter einem Router nur eingehender Codec. Aber ich wiederhole mich glaube ich ...

 

[Ottone]

"Loose routing" (The SIP Express Router > Differences between Strict Routing and Loose Routing) und "early media" führen nicht zum Ziel, da geht es um völlig andere Dinge.

EDIT: Nicht funktionierender link für loose routing entfernt

 

[cmmehl]

Das Verhalten der FritzBox kann also durch entsprechende Einstellungen am Asterisk als Client ausgeglichen werden

Hab ich da was verpasst? Sprichst du von asterisk allgemein (also auch remote) oder einem auf der FB? Woher hast du diese info - welche einstellungen genau?

Gruss
Chris

 

[pfeffer]

nun ja. Ich erwarte nicht, dass die Clients eine Einstellung haben "fritz!Box Fon-Bug umgehen".
Aber ok, Loose-Routing scheint sich nur auf das Routing von SIP, nicht jedoch auf das Routing von RTP zu beziehen. Leider ergibt Dein Link bei mir irgendwie nix (Seite öffnet sich, aber keine Info zu loose-Routing, wenn ich sie mit dem IE öffne: Session unavaibable).

Early Media ist zur Übertragung der Klingeltöne vom angerufenen zum Anrufer. Wenn wir Glück haben, dann könnte das dazu führen, dass der Client seine Audio-Daten dorthin schickt, wo die Ruf-Signalisierungstöne herkamen. Es wird von der Implementierung abhängen, ist halt nur eine Idee.

Irgendwelche Einstellungen, die heißen "send audio to where it comes from" wären am besten (das ist das, was offensichtlich nat=yes bei asterisk bewirkt). Also, generell muss man nach NAT-Einstellungen im Client suchen, die nicht STUN sind.

Gruß,
Pfeffer.