Registrieren von Aussen - was ist zu beachten?

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
L

lipperreiher

Neuer User
Mitglied seit
25 Jan 2005
Beiträge
75
Punkte für Reaktionen
0
Punkte
0
Hallo,

so nach und nach ersetzt der asterisk auf meiner FBF (7050) meinen vServer ;-)

Ein Thema habe ich aber noch auf dem Herzen.

Was gibt es alles zu beachten, wann man sich von außen an der FBF registrieren will, um dann z.Bsp Interngespräche führen zu können?

FBF-aussen -> via SIP -> FBF-bei-mir

folgende Ports habe ich bereits weitergeleitet an eine interne IP meiner FBF:

"tcp 0.0.0.0:5061 192.168.179.1:5061 0 # tcpsip5061",
"udp 0.0.0.0:5061 192.168.179.1:5061 0 # udpsip5061",

Das Registrieren der FBF-aussen an der FBF-bei-mir funktioniert jedenfalls schon mal.
Ein Gesprächsaufbau kam auch zustande, aber ich habe mein Gegenüber nicht gehört und er mich auch nicht.

Ich meine mal gelesen zu haben, daß irgendwelche RTP-Ports weitergeleitet werden müssen, finde den Beitrag aber nicht mehr.

Was muß ich also noch machen , um mir in Zukunft die 4,- Euro/Monat für den vServer sparen zu können?

Gruß

lipperreiher
 
einfach die ports genauso weiterleiten ´...sie werden beim * in der rtp.conf angegeben

rtpstart=9078
rtpend=9097
Zum Vergrößern anklicken....

Code: 
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:5061 0.0.0.0:5061",
                            "tcp 0.0.0.0:5061 0.0.0.0:5061",
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078",
                            "udp 0.0.0.0:9078+32 0.0.0.0:9078";
 
Sorry, aber da kapier ich nicht genau, in welchen Sektionen der ar7.cfg ich die Ports anpassen muss.
Es gibt ja mehrere ....

Die Sektion "voip_forwardrules" finde ich z.Bsp überhaupt nicht. Liegt vielleicht daran, daß ich nicht die neueste Firmware drauf habe und noch mit dem 2.4er Kernel arbeite?

In meiner ar7.cfg gibt es zwei Sektionen namens "forwardrules" dort habe ich jeweils die folgende Zeile eingefügt:

Code: 
"udp 0.0.0.0:9078+32 0.0.0.0:9078"

Was hat das mit dieser Syntax "+32" auf sich?
Kann meine Version damit überhaupt umgehen, oder muß ich dort pro weiterzuleitenden Port eine Zeile einfügen?

Meine Änderungen haben jedenfalls nichts gebracht. Die Situation ist nachwievor so, dass weder der Anrufende noch der Angerufene etwas hört. Die Verbindung kommt aber zustande, zumindest wenn ich die Gegenstelle anrufe.

Wenn meine Gegenstelle versucht, ein Gespräch aufzubauen, scheitert dies gänzlich.
Auf der Fritzbox wird dann angezeigt:

Code: 
Fehlercode: 488 - Not acceptable here

Bin dankbar für jede Hilfe ...

Gruß

lipperreiher
 
Was hat das mit dieser Syntax "+32" auf sich?
Zum Vergrößern anklicken....
Bedeutet, dass 32 Ports beginnend mit 9078 geforwarded werden.
Meine Änderungen haben jedenfalls nichts gebracht. Die Situation ist nachwievor so, dass weder der Anrufende noch der Angerufene etwas hört. Die Verbindung kommt aber zustande, zumindest wenn ich die Gegenstelle anrufe.
Zum Vergrößern anklicken....
Hast Du die FBF nach der Änderung rebootet, damit die ar7.cfg neu eingelesen wird ?
Fehlercode: 488 - Not acceptable here
Zum Vergrößern anklicken....
Bedeutet "Client Error — the request contains bad syntax or cannot be fulfilled at this server" ( mehr zu SIP-Fehlercodes hier )
 
>Bedeutet, dass 32 Ports beginnend mit 9078 geforwarded werden.
wenn wenn die firmware aktuell genug ist, dass sie diese Syntax akzeptiert; sonst müssen die ports alle einzeln angegeben werden.
(nmap vom vserver aus auf die externe ip der fritzbox sollte
offene ports anzeigen können)

spblinux
 
Hallo,

dynamic schrieb:
Hast Du die FBF nach der Änderung rebootet, damit die ar7.cfg neu eingelesen wird ?
Zum Vergrößern anklicken....

ja, reboot hab ich gemacht, mehrmals.

spblinux schrieb:
wenn die firmware aktuell genug ist, dass sie diese Syntax akzeptiert; sonst müssen die ports alle einzeln angegeben werden.
Zum Vergrößern anklicken....

Dann sollte ich vielleicht nochmal probieren, alle Ports einzeln anzugeben, obwohl meine Box die Syntax offensichtlich beherrscht. Denn wenn ich über das Webinterface eine Regel mit mehreren hintereinanderliegenden Ports einstelle, sehe ich danach in der ar7.cfg genau diese angesprochene Syntax.

Was ich aber grundsätzlich noch nicht geschnallt habe, ist folgendes.
Normalerweise ist eine Portforwardingregel doch nach folgendem Konzept aufgebaut:

Code: 
tcp 0.0.0.0:22 192.168.179.1:22

Das würde ich wie folgt übersetzen:
Code: 
Alle TCP-Anfragen auf den Port 22 werden weitergeleitet an die LAN-IP-Adresse 192.168.179.1, und zwar ebenfalls an Port 22!!

Wie könnte man dann die folgende Regel übersetzen?

Code: 
"udp 0.0.0.0:7078 0.0.0.0:7078"

Das wäre ja eigentlich eine Weiterleitung auf sich selber, oder wie ist das zu verstehen?

Gruß

lipperreiher
 
Wie könnte man dann die folgende Regel übersetzen?
Code: 
"udp 0.0.0.0:7078 0.0.0.0:7078"
Zum Vergrößern anklicken....
Alle Interfaces dürfen UDP-Pakete von Port:7078 entgegennehmen und an alle im lokalen ( private ) LAN befindlichen IPs auf Port 7078 durchreichen.
 
Hallo,

also, ich habe jetzt alles weitergeleitet, was man so weiterleiten kann, leider ohne Erfolg.
Ich muß allerdings dazu sagen, daß ich relativ begrenzte Möglichkeiten zum Testen habe.
Der Client, von dem ich versuche, Gespräche aufzubauen, ist eine FritzBox Fon, Firmware: 06.04.33 (vielleicht geht es damit ja auch nicht).

Anbei mal ein Auszug aus meiner ar7.cfg, vielleicht findet ihr dort Fehler:

zurerst alle udp-ports:

Code: 
grep "udp 0.0.0.0" /var/flash/ar7.cfg
                                       "udp 0.0.0.0:0 0.0.0.0:0 1 out",
                                       "udp 0.0.0.0:5060 0.0.0.0:5060",
                                       "udp 0.0.0.0:5061 0.0.0.0:5061",
                                       "udp 0.0.0.0:7078 0.0.0.0:7078",
                                       "udp 0.0.0.0:7079 0.0.0.0:7079",
                                       "udp 0.0.0.0:7080 0.0.0.0:7080",
                                       "udp 0.0.0.0:7081 0.0.0.0:7081",
                                       "udp 0.0.0.0:7082 0.0.0.0:7082",
                                       "udp 0.0.0.0:7083 0.0.0.0:7083",
                                       "udp 0.0.0.0:7084 0.0.0.0:7084",
                                       "udp 0.0.0.0:7085 0.0.0.0:7085",
                                       "udp 0.0.0.0:4569 0.0.0.0:4569",
                                       "udp 0.0.0.0:9078+32 0.0.0.0:9078",
                                       "udp 0.0.0.0:4569 192.168.179.1:4569 0 # udpiax2",
                                       "udp 0.0.0.0:5061 192.168.179.1:5061 0 # udpsip5061",
                                       "udp 0.0.0.0:0 0.0.0.0:0 1 out",
                                       "udp 0.0.0.0:5060 0.0.0.0:5060",
                                       "udp 0.0.0.0:5061 0.0.0.0:5061",
                                       "udp 0.0.0.0:4569 0.0.0.0:4569",
                                       "udp 0.0.0.0:7078 0.0.0.0:7078",
                                       "udp 0.0.0.0:7079 0.0.0.0:7079",
                                       "udp 0.0.0.0:7080 0.0.0.0:7080",
                                       "udp 0.0.0.0:7081 0.0.0.0:7081",
                                       "udp 0.0.0.0:7082 0.0.0.0:7082",
                                       "udp 0.0.0.0:7083 0.0.0.0:7083",
                                       "udp 0.0.0.0:7084 0.0.0.0:7084",
                                       "udp 0.0.0.0:7085 0.0.0.0:7085",
                                       "udp 0.0.0.0:9078+32 0.0.0.0:9078";

jetzt noch alle tcp-Ports

Code: 
 grep "tcp 0.0.0.0" /var/flash/ar7.cfg
forwardrules = "tcp 0.0.0.0:0 0.0.0.0:0 1 out",
                                       "tcp 0.0.0.0:8089 0.0.0.0:8089",
                                       "tcp 0.0.0.0:5061 0.0.0.0:5061",
                                       "tcp 0.0.0.0:22 192.168.179.1:22 0 # ssh local",
                                       "tcp 0.0.0.0:4569 192.168.179.1:4569 0 # tcpiax2",
                                       "tcp 0.0.0.0:5061 192.168.179.1:5061 0 # tcpsip5061",
                        forwardrules = "tcp 0.0.0.0:0 0.0.0.0:0 1 out",

Was gibt es denn noch für Testmöglichkeiten?
Kann ich per xlite quasi über den router raus und wieder rein (auf www.mein-name.no-ip.com:5061) oder muß ich dafür wirklich von außen kommen?

Gruß

lipperreiher
 
Kann ich per xlite quasi über den router raus und wieder rein (auf www.mein-name.no-ip.com:5061) oder muß ich dafür wirklich von außen kommen?
Zum Vergrößern anklicken....
Sollte eigentlich kein Problem sein.
Hast Du denn mal versucht das xLite intern zum laufen zu bringen, so dass alles funktioniert und im 2. Schritt die Variante über das externe Interface ?
 
dynamic schrieb:
Sollte eigentlich kein Problem sein.
Hast Du denn mal versucht das xLite intern zum laufen zu bringen, so dass alles funktioniert und im 2. Schritt die Variante über das externe Interface ?
Zum Vergrößern anklicken....

Ja, intern funktioniert das. Extern werde ich so schnell wie möglich testen!

Ist das denn möglich, das die "einfache" Fritz!Box Fon dafür nicht taugt??

Gruß

lipperreiher
 
Hallo,
ich habe ähnliches Problem. Vielleicht weiss einer von euch eine Lösung.

Fritzbox mit Asterisk -> SIP Telefon C450 IP
Habe auf Port 5060 umgestellt.
Funktioniert tadellos solange in der Extensions.conf die bindadress=192.168.178.252 eingestellt ist.Mit dieser config. komm ich aber nicht von aussen mit fring rein. Ändere ich die bindadress auf 0.0.0.0 komm ich von aussen ohne probleme rein.

Der Nachteil: Mein C450 IP verliert dann nach ca. 15 min die Verbindung. Es lässt sich dann auch nicht mehr anpingen. Habe auf der Fritzbox den DCHP aus und alles statisch vergeben.

Woran kann das Liegen?

ps. An der Fritzbox hängen noch zwei ISDN Telefone, die an Asterisk registriert sind. Diese behalten die Verbindung.

Danke im Voraus
 
Eigentlich sollte Dein C450IPauch mit bindaddr=0.0.0.0 funktionieren, denn durch diese Angabe wird dem Asterisk lediglich mitgeteilt, dass dieser auf allen Interfaces horchen soll.
Ich vermute daher, dass eher in der Konfiguration Deines Telefons etwas nicht so recht passt.

Abgesehen davon sollte Dein Asterisk auch bei bindaddr=192.168.178.252 ( dieser Parameter gehört jedoch in die sip.conf und nicht extensions.conf ) via Internet erreichbar sein, solange Du Port 5060 und die RTP-Ports entsprechend auf diese IP forwardest.

Ferner solltest Du einige weitere Parameter in der sip.conf beachten ... siehe dazu hier.
 
danke dynamic.

ich meinte natürlich die sip.conf und nicht extensions.conf

Werds mal testen mit den einstellungen aus deinem link.

Jedoch ist mir das mit dem C450IP schleierhaft. Es verliert ja die ganze netzwerkverbindung und nicht nur die sip registrierung. Wie gesagt, ich kann es nach ca. 15 min vom Rechner nicht mehr anpingen. Erst nachdem ich den Stecker ziehe gehts wieder. Das passiert aber nur mit bindadr=0.0.0.0
 
Zuletzt bearbeitet:
Hier mal meine sip.conf
Vielleicht fällt Dir was auf

Code: 
[general]
bindport=5060
bindaddr=192.168.178.252
;bindaddr=0.0.0.0
localnet=192.168.178.0/255.255.255.0
context=default
externhost=meineip.dyndns.ord
externrefresh=10
nat=yes
canreinvite=no
srvlookup=yes
dtmfmode=info
language=de
disallow=all ; sperrt alle codecs
allow=ulaw
allow=alaw ;der default-codec des ISDN-Channels
allow=gsm
videosupport=yes ; enable Asterisk video support



;FRING 
[204]
type=friend
username=204
secret=meinpasswort
host=dynamic
domain=meineip.dyndns.org
context=204
callerid=HANDY <204>
nat=yes
dtmfmode=RFC2833
qualify=no
disallow=all
allow=all 

;C450 IP
[205]
type=friend
username=205
secret=meinpasswort
host=dynamic
domain=192.168.178.252
context=205
dtmfmode=rfc2833
callerid=C450IP <205>
qualify=yes
nat=no
canreinvite=no
disallow=all ; sperrt alle codecs
allow=ulaw
allow=alaw ;der default-codec des ISDN-Channels
;allow=gsm
disallow=gsm ;weil im C450 nicht verf.gba[51]OD

Habs grad damit getesten...Fring registriert sich nicht.
 
Setze mal "qualify=no" ... nachdem wie Du es beschreibst, sieht es danach aus, dass Asterisk den Eindruck gewinnt, dass das Gerät nicht mehr verfügbar ist.

Wenn "qualify=yes" gesetzt ist, kontaktiert SIP den jeweilige SIP-Peer in regelmäßigen Zeitabständen und erwartet innerhalb von 2s ( default ) eine Antwort. Kommt diese Antwort nicht innerhalb dieses Zeitfensters, dann wird das Gerät als "offline" angesehen und fortan als nicht mehr verfügbar markiert.

Hier kannst Du mehr dazu lesen.
 
Moin,

ich schon wieder ....

bei mir hat sich die Situation ein wenig geändert:

Anstelle der 7050 (mit 2.4er Kernel) besitze ich jetzt eine 7170, auf der mein Asterisk in der Version 1.4.16.2 bereits wunderbar läuft (inklusive app_conference).

Was das Registrieren von Außen angeht, hat sich allerdings nicht allzuviel geändert.
Das eigentliche Registrieren am Asterisk klappt nachwievor, ich kann auch Verbindungen aufbauen (z.Bsp zur internen Telefonkonferenz), kann aber nichts hören.

Wenn ich angerufen werde (von außen mit Handy), geht alles: ich höre den Anrufer, er hört mich.

Meine rtp.conf sieht wie folgt aus:

Code: 
;
; RTP Configuration
;
[general]
;
; RTP start and RTP end configure start and end addresses
;
; Defaults are rtpstart=5000 and rtpend=31000
; fritzbox voipd uses 7078-7097 (see ar7.cfg)
rtpstart=9078
rtpend=9097
;
; Whether to enable or disable UDP checksums on RTP traffic
;
;rtpchecksums=no
;
; The amount of time a DTMF digit with no 'end' marker should be
; allowed to continue (in 'samples', 1/8000 of a second)
;
;dtmftimeout=3000

Folgende Regeln habe ich in der ar7.cfg eingestellt:

Code: 
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:5061 0.0.0.0:5061",
                            "tcp 0.0.0.0:5061 0.0.0.0:5061",
                            "udp 0.0.0.0:9078+32 0.0.0.0:9078",
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";

forwardrules = "tcp 0.0.0.0:443 0.0.0.0:443 0",
                                       "tcp 0.0.0.0:5500 192.168.0.21:5500 0 # VNC-Hilfe",
                                       "tcp 0.0.0.0:22 192.168.0.10:22 0 # SSH",
                                       "tcp 0.0.0.0:8022 192.168.0.114:22 0 # ssh-vdr",
                                       "tcp 0.0.0.0:8023 192.168.0.112:22 0 # ssh-vdr2",
                                       "udp 0.0.0.0:9078+32 192.168.0.10:9078 0 # rtp";

Noch irgendwelche Ideen, was ich ausprobieren kann?

Gruß

lipperreiher
 
ich versuche mal ein paar Gedanken von mir zusammen zu tragen:

1.) bindport=5060
Hast du den voipd der Fritzbox auf einen anderen port geändert?

2.) bindaddr=192.168.178.252
setz das doch mal auf die 0.0.0.0

3.) voip_forwardrules + forwardrules
ich würde die ports nicht bei beidem eintragen. Versuch mal alle des Asterisks unter den voip_forwardrules.

4.)
Du hast alle Freigaben auf das Netz: 192.168.0.xxx gemacht. Dein localnet=192.168.178.0/255.255.255.0 hast du aber in der sip.conf.
Was stimmt den nun?

vg
waldoo
 
Hallo waldoo,

die Konfiguration, die du zitierst, ist nicht die meine sondern die von SR166.

Ich habe weitestgehend die Default-Einstellungen (Port: 5061 u.s.w.)



waldoo schrieb:
ich versuche mal ein paar Gedanken von mir zusammen zu tragen:

1.) bindport=5060
Hast du den voipd der Fritzbox auf einen anderen port geändert?

2.) bindaddr=192.168.178.252
setz das doch mal auf die 0.0.0.0

3.) voip_forwardrules + forwardrules
ich würde die ports nicht bei beidem eintragen. Versuch mal alle des Asterisks unter den voip_forwardrules.

4.)
Du hast alle Freigaben auf das Netz: 192.168.0.xxx gemacht. Dein localnet=192.168.178.0/255.255.255.0 hast du aber in der sip.conf.
Was stimmt den nun?

vg
waldoo
Zum Vergrößern anklicken....


Ich arbeite lokal in dem Netz 192.168.0.0/24

Ich komme gerade nicht per SSH auf meine Box, werde aber meine sip.conf noch mal nachliefern, sobald dies geht.

Gruß

lipperreiher
 
So,

jetzt noch mal meine aktuellen Konfigs:

sip.conf

Code: 
bindport=5061                           ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0                        ; IP address to bind to (0.0.0.0 binds to all)
externhost=mydomain.no-ip.com       ; Adresse, die von aussen ansprechbar ist
srvlookup=yes                           ; Enable DNS SRV lookups on outbound calls
language=de

hier der entspr. Auszug für den Account, mit dem ich mich registriere:

Code: 
[774]
context=sip774
callerid="SIP 774" <774>
host=dynamic
domain=0.0.0.0
nat=yes                       ; X-Lite is behind a NAT router
type=friend
user=774
secret=secret
;mailbox=774
;canreinvite=no                ; Typically set to NO if behind NAT
;qualify=yes
;insecure=very
;regexten=1234                 ; When they register, create extension 1234
;username=xlite1
disallow=all
allow=gsm                     ; GSM consumes far less bandwidth than ulaw
allow=ulaw
allow=alaw

Meine Versuche starte ich übrigens mit xlite.
Wie gesagt:
- registrieren funktioniert
- Anruf von außen funktioniert auch

Wenn ich nach der erfolgreichen Registierung z.Bsp. versuche, mich in die Telefonkonferenz einzuwählen, kommt der Verbindungsaufbau auch zustande, wie ich in der cli nachvollziehen kann, aber ich habe keinen Ton ;-(

Gruß

lipperreiher
 
@lipperreiher
Schau mal hier
Ausserdem setze canreinvite=no

Gruß
dynamic
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 520 (Mitglieder: 5, Gäste: 515)

Neueste Beiträge

Statistik des Forums

Themen
246,217
Beiträge
2,248,326
Mitglieder
373,790
Neuestes Mitglied
aukseller
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück